That's where all other protocol specific settings are currently located.
Will be migrated at a later date into the printer profile instead (that
makes way more sense).
If a new config setting is set, the virtual printer will now
resend the same resend request twice to allow testing the
comm layer behaviour in OctoPrint for being able to cope with
these possible repetitions like they can happen with Repetier.
Repetier might resend the same resend request to make sure it arrives.
This commit makes OctoPrint not react to such a repeated request and
instead ignore up to a configurable amount of repeated requests for
the same (current) line.
This will only style them in a special way and influence sorting. Plugins still need
to ensure that a step is not skipped through the use of the onWizardTabChange callback
in the view model.
T-only lines were not properly parsed. Should now be fixed to
be associated to currently selected extruder. Also added unit
tests for the temperature parsing.
While at it also extracted regexes and added unit tests for command
parsing (gcode & parameters)
Even if the webcam URLs and the FFMPEG path is not yet configured. Otherwise
setting those URLs and the path will require a restart of OctoPrint to enable properly -
that's overkill.
Also introduced wizard finish backend method and remove old
firstrun dialog remnants.
TODO: bound check won't work this way, needs to be redone
differently. Goal is to only call onWizardFinish for wizards which
are actually involved...
No need to have templates here, we do it directly from the helper methods.
That also leaves us more options regarding callbacks, classes etc.
Helper methods now take an options dictionary (but still can fallback to the
old signature) containing messages, titles, callbacks etc instead of using
positional arguments for that. Switched code over to utilize that new
calling approach.
The user will now be offered a dialog with two choices if a server side update
of the settings is detected while the user has the settings dialog opened and made
local changes: Either reload all changes, effectively overwriting any local changes,
or only set those settings changed on the server that are not also changed locally.
If after a reconnect the server side configuration has changed, we want to reload.
Using the SettingsUpdated event the clients can track the current config hash during
runtime so that no unnecessary reloads during runtime should be demanded.
