* Extended plugin metadata by new property, only evaluated for bundled
plugins.
* Adjusted plugin manager to evaluate new metadata and add
confirmation dialog with details when attempting to disable such
a plugin.
* Added combined OctoBlog feed, replacing news + spotlight (+
octoprintonair), added corresponding config migration
* Subscribe to all registered feeds by default
* Added config button to announcement reader
* Added note how to edit announcement subscriptions to notifications
* Auto-hide announcements on logout
* Order channels server-side based on new order config setting
Old default behaviour of showing logged in users the update
notification stays default, but can now be disabled via the software
update plugin settings.
Additionally added the ignore button to the notification for users as
well (and made ignore entry in local storage user specific to still
show notification to other logged in users), plus a small hint that
in order to apply updates an admin is needed. Additionally now hiding
the notification on log out.
Closes#1739
Might confuse users to see that marked up like an error when it's
perfectly normal for some kinds of installs simply because the
specific build folders never were created in the first place.
Might have been an external reset of the printer we didn't otherwise
detect, and unless we reset the line numbers we'll now be off and run
into resend requests.
Solves #1676
* leading and trailing null bytes will now be stripped
* while connecting, a "wait" will also trigger switch to connected
state - relevant when connecting without reset and initial "ok" for
M110 gets mangled
* extended virtual printer by new options to test the above:
* mangled "ok" can now be injected via "preparedOks" setting and
prepare_ok DEBUG command
* simulated reset lines on beginning ("start" etc) now only sent
if new setting "simulateReset" is true
Should fix#1770
Don't allow overwriting of "octoprint" config through plugins, don't
allow overwriting of already registered configs unless id to register
matches plugin identifier (in which case the already registered config
was probably a case of a copy-paste-error from another plugin).
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.
Support multi-extruder setups that share a single nozzle and heater,
like the E3D Cyclops, Diamon hotend or probably the upcoming Prusa Mk2
multi-extruder upgrade.
The Control tab will still allow tool switching and extruding for
the configured extruders, the Temperature tab will only display
one hotend temperature though.
Printer profiles have been extended by a new option
extruder.sharedNozzle that defaults to False. Extruder offsets are
not displayed in the profile editor if that setting is checked and
reset to (0,0).
So far the plugin selected the gcode script corresponding to the number of
extruders configured in the printer profile. After a close look into the
implementation in Cura itself, prompted by #1708, it turns out that this is
in fact wrong.
Cura selects the gcode script to use based on the maximum of the number of
extruders needed for printing the models in the scene and the minimum number
of extruders needed for generating support (if support extruder is "both" or "first"
or there is only one extruder, that's 1, if it's "second" and there is more than one
extruder, it's 2).
This commit changes the plugin's implementation to mirror this implementation.
The difference to Cura is that we have the number of extruders needed for the
models in the scene hard coded to 1 since we only support STL right now which
can never contain more than one object. If we ever decide to support merging of
multiple STLs into one single multi-extruder print or other model files like AMF
or OBJ from OctoPrint's slicer support, we need to change this.
Affected print_temperature and filament_diameter placeholders.
E.g. `print_temperature2` was wrongly attempting to fetch `print_temperatures[2]`
instead of `print_temperatures[1]` (0-based-indexing!)
Partially fixes#1708
* Added/changed mappings of profile to engine settings to
match Cura Legacy mapping:
* perimeterBeforeInfill: taken from perimeter_before_infill (new,
fixes#1693)
* skinSpeed: taken from solidarea_speed (new)
* raftAirGapLayer0: sum of raft_airgap and raft_airgap_all
* raftAirGap: taken from raft_airgap_all (new)
* raftFanSpeed: changed to 0
* raftSurfaceThickness: taken from raft_surface_thickness (new)
* raftSurfaceLinewidth & raftSurfaceLineSpacing: taken from
raft_surface_linewidth (new)
* Mach3 Gcode Flavor replaces S parameter with P parameter in
temperature commands within generated GCODE, like in Cura
Legacy
If the slicer returns values for a tool we want it in our analysis
result, even if it's zero. That way the result will be the same as
if we have our own built in gcode analyser take a look at the
file.
(cherry picked from commit 818ae92)
This fixes the issue that there were no informations about filament
usage in metadata after slicing with cura plugin. Trying to call
profile.get_float("filament_diameter") ended in en exception with
message " 'module' object has no attribute 'get_float' ". So i defined
profile before using profile and now it works.
See issue #1685
Also inserted a check to determine if filament usage is > 0 to exclude
tools with no filament usage in metadata.
(cherry picked from commit c9b38bd)
Removed a potential deadlock, added logging for all
raised exceptions, made _to_error more solid and
removed another potential encoding issue when
creating diffs
Having that output stay on stderr and hence in shiny red looks way
too alarming considering that it's only a pip update that is not THAT
critical usually (and we don't want to do it automatically anyhow
considering how often that appears to break stuff).
Can be enabled either through new --safe command line
parameter or through server.startOnceInSafeMode in
config.yaml
When running in safe mode the plugin manager will
only allow to disable or uninstall third party plugins. Enabling
third party plugins or installing new plugins is disabled.
That will hopefully allow for more straightforward recovery
in case of a misbehaving plugin.
