Added name and path various event print job events and
the upload event, deprecated the file property.
Had to move event triggering of the print job events to
the printer implementation, since the file manager
is not available in the comm layer. Added new callbacks
to the PrinterInterface to allow for that to be possible.
RepRapFirmware enumerates the gcode files starting at /gcode, it will
also interpret any relative path as being relative to that folder.
However a full absolute path will actually interpret as from the real
root of the SD card :-(
(cherry-picked from ac68570)
Events SlicingProfile(Added|Modified|Deleted). Initially thought to be necessary
to properly refresh available profiles in slicing dialog, not needed for that after
all but still left in and documented, might be useful for someone.
This fixes a simple typo in the API doc for fetching slicing profiles. The previous example had /profiles appended to it, whereas it should just be /api/slicing to fetch a list of all slicers and profiles.
"Hello" command sent to printer to trigger initial handshake can now be
configured. Commands that _always_ necessitate to be sent with checksum/
line number (e.g. M110 on Marlin) can be configured as such too.
Also fixed an issue causing the "Hello" command to not be actually enqueued
first thing on opening a connection. Seems to not have caused harm in the
wild, but was unintentional.
(cherry picked from commit 5c2ae37)
The client now tries to detect if it's fast enough to process the
state updates usually send every 500ms, and if not notifies the
server to throttle the rate (e.g. to 1/1s, 1/1.5s etc).
Additionally, since the terminal tab of the client turned out to
be quite CPU intense when line number calculation, filtering etc
is enabled, the terminal tab now also falls back into a bit less
fancy mode if it detects its being processed too slow and optionally
even disables logging completely during printing (where a lot
of log messages need to be processed in a minimum amount of
time).
That way the UI should stay responsive even on very low powered
clients (e.g. chromium on a Pi), while printing.
Having the plugin commands on the first level of --help proved to be
a bad idea since it basically kills every chance of lazy loading the (expensive)
plugin context. Using a sub command for anything plugin related allows us
to only fire up the plugin context if a plugin command is expected, saving us
some precious seconds of operation in all other cases.
For conformity reasons the dev sub commands were now restructured
similarly.
