We now have a global OctoPrintClient, which is the class from which
all clients are derived, and a global OctoPrint, which is a single
instance already setup and ready to use in case we only need one.
It would be cleaner to have clients create that singular instance
themselves, but we need to maintain backward compatibility for now
with how we established the client to work with the 1.3.0 release.
New clients can be create with
client = new OctoPrintClient({ /* options */ });
Alternatively the options can be left out and set at a later point:
client = new OctoPrintClient();
/* ... */
client.options = { /* options */ };
Individual client components register themselves with OctoPrintClient
via OctoPrintClient.registerComponent(name, component) from the
component JS files. Just like before their instances are then
available in the individual client instances under "<client>.<name>",
e.g. "OctoPrint.files".
Plugin components register themselves with OctoPrintClient via
OctoPrintClient.registerPluginComponent(name, component) from the
component JS files. Just like before their instances are then
available in the individual client instances under "<client>.plugins
.<name>", e.g. "OctoPrint.plugins.softwareupdate".
This should make it possible to create dashboard pages utilizing the
JS client that monitor the status of multiple OctoPrint instances,
without workarounds such as having to swap out the options globally
before each request.
See #1681 for the corresponding discussion.
* show special error if timelapse can't be rendered due to no frames having
been captured
* inform user during print about repeated capture errors
* do not start post roll recording if after a print no frames were captured at all
* also interpret non-ok-ish return codes from snapshot url as capture error
* documentation for CaptureFailed event
They are still useful for other clients than the core application. Renamed them to fit the
general naming on the API however:
* pathForElement is now called pathForEntry
* elementByPath is now called entryForPath
Also added API docs regarding header encoding, incl support for RFC 5987
for filename fields in Content-Disposition headers in multipart/form-data
parts, incl. an example of an upload request with a utf-8 encoded filename.
(Let's be realistic here)
Introduced new "additionalNames" property on viewmodel declaration
to allow for registering alternative lookup names for a view model.
The freshly renamed FileViewModel now resolves as both "filesViewModel"
and "gcodeFilesViewModel", making the renaming backwards compatible
Documented all that stuff (and some more)
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.
