Also removed unused ColorSelector and CreateFont to reduce wrappers
size to the minimum.
This commit is preparatory for dropping dependency on processing-core.
Created a class PreferencesData to manage all parameters except the ones for the GUI.
Removed GUI parameters management from ParametersMap.
Created ParametersHelper class to help with GUI parameters management.
Used ParametersHelper in Themes.
Create a class SketchData to store all relevant data for a sketch
(trying to keep GUI stuff out of the way).
Moved preprocessing code from Sketch to Compiler.
Nobody was using it anymore, except for checking against specific
extensions, which is easily done against the filename itself. This
prepares for some simplification of Sketch.load next.
Previously, the useRecursion and srcFolders were filled on library
creation, based on the existence of the src folder. Now, a layout
variable is set, and the useRecursion() and getSrcFolder() methods
change their return value based on the layout in use.
An exported UTI declaration means that the type is available for use by all other parties.
By adding an this declaration for ino files, it allows Quick Look to display file content and
external editors (like Xcode) to automatically syntax highlight .ino files as C++
Before, core.a would be rebuilt on every build, even when none of the
core .o files changed. Now, the timestamps are checked against the
timestamp on core.a first, skipping the build if nothing changed.
Because this uses the current list of .o files, there is a corner case
when a source file is deleted, but no other source file is modified. In
that case, core.a is not rebuilt, even though it should be. However,
this is such a narrow and unrealistic case, that it should pose a real
problem.
This fixes part of #1991
This prevents a half-finished core.a file from lingering around.
Currently, this should not make a difference since core.a is rebuilt
every time, but this prepares for skipping this build step if possible.
Before, the ar command was just ran for all .o files that should end up
in core.a, which should replace any old code in core.a. However, it
seems that in the unlikely event that functions or entire source files
are deleted, they might linger in the core.a file.
