Previously, --verbose would be processed after the preferences were
saved, which should usually mean that it should never influence the
saved preferences. However, if for whatever reason Preferences.save()
would be called later, the verbosity preferences would still be messed
up.
Since we now have a Preferences.setDoSave() method, we can make sure
that these verbosity preferences (and any other preferences that are
changed after the build started) are never saved.
Preferences.init would write out the default preferences when no
preference file previously existed. This would cause a default
preferences file to be written even when --no-save-prefs was passed, due
to the ordering of things.
However, since the Base constructor now already calls
Preferences.save(), there is no need for Preferences.init to also do
this. Since Base calls this after parsing the commandline, the
--no-save-prefs option is now also properly respected.
This allows setting preferences for the current run only, without
remembering them for the next run. This is especially useful when
combined with --verify or --upload.
Before, the preferences were saved as a side effect of loading files in
the Editor, but it seems better to explicitely save them as well (this
should prevent problems later on, if the Editor class is no longer used
in --verify or --upload mode).
Since the handling of these options defaults to non-verbose (instead of
the current preference), they make no sense when starting the IDE
normally. Previously, these options would just be ignored in this case,
now an error is shown.
Previously, the --board and --port arguments were stored in a variable
first and only processed later. Now, the arguments are processed right
away.
This does mean that the arguments are processed when the GUI is not yet
initialized, which caused problems with calling onBoardOrPortChange and
friends from selectBoard. However, since the GUI is not initialized,
there is no real reason to call them either - if we just set the
preferences to the right values, the GUI will be initialized correctly
later. For this reason, selectBoard no longer calls the GUI update
methods. Instead, those are called from the GUI code when the board is
changed through the menu instead (e.g., after calling selectBoard).
This commit slightly changes behaviour. Previously, --board and --port
only worked in combination with --verify and --upload, but were ignored
when just starting the IDE. Now, these are processed regardless of the
other options present.
Additionally, this commit causes all changed preferences to be saved.
Previously, only changes with --pref were saved, --board and --port
options were only active for the current run. This was caused because
the saving of the preferences happened as a side effect of loading the
file in the Editor, but only the --pref option was processed at that
time.
Note that the --verbose options are still only active for the current
run and are only valid combined with --verify or --upload (since they
default to non-verbose instead of the current preference).
This method takes care of setting the serial.port preference to the
given value, as well as deriving the serial.port.file preference. This
should prevent duplicate code in the future.
Note that a second copy of this code lives in SerialUploader, but that
doesn't write to the global Preferences but a local prefs map. Since the
global Preferences are currently static, there is no way to share code
between these two copies.
This uses a switch on the action value, which makes it more clear what
code runs when. No actual behaviour is changed, most of the changes in
this commit are indentation changes.
Previously, the code showed an error when the given action was not
upload or verify. This is now reversed: the GUI is shown when the action
is "GUI" (which is the default when no action specified). Since the
action enum only contains these three values, there is no change in
behaviour, but this makes it easier to add new actions later.
Previously, two separate booleans (doUpload and doVerify) were used.
However, since it always makes sense to specify only one of them, it
makes more sense to keep a single action enum variable, which slightly
simplifies the code (especially when more actions are added later).
Additionally, an error is now shown when both --verify and --upload are
specified on the commandline.
