* Properly handle G0/G1 with no X, Y, Z coordinates in relative mode
instead of duplicating coordinates - should fix#1675
* Only take move commands with X, Y, Z coordinates into account for
model size calculation - this makes our internal GCODE analysis behave
like the GCODE viewer's analysis and produce the same model size. The
downside is that extrusions on the origin are no longer taken into account
for checking if a model is within bounds of the print bed, but that should
hopefully not produce any issues in the real world.
--basedir, --config, --verbose, --safe may now come before or after
subcommands and should still be evaluated.
For the server commands (legacy, "server" and "daemon"), the same
should now hold true for the related parameters --host, --port, --debug,
--logging, --iknowwhatimdoing and also --pid (for daemon command).
While having the parameters belong to the individual commands and only
there (which is click's basic approach) is way more cleaner, too many people
were running into issues with that strict approach after all.
I just hope the somewhat hackish approach with context injection needed to
get the less strict version to work won't backfire badly in the long run.
See also #1633 and #1657
--version is a flag, not an actual parameter (wouldn't really make sense
too). I'm not sure why that isn't the default behaviour of the built-in
version_option decorator tbh.
See #1647
Two problems solved:
* Make sure to only process temperature data once we
have printer profile information on hand to evaluate
the heater data. If we don't have that yet, create a client
side backlog and process that once we have the necessary
data on hand.
* Do not use uninitialized history cutoff values - if our cutoff
value hasn't yet synced (no settings response arrived yet),
just don't perform the cutoff.
That api endpoint really is a tough nut. ETag calculation now also
takes full settings dump from settings plugins into account, because
those might be providing custom keys through custom on_settings_load
implementations, for which we will not notice any changes if we are
only looking at the effective config.
Of course, the more we put into that ETag calculation, the slower it will
be and the less sense it will make. Somewhat annoying :/
Not testing if oldRoot was actually set and contained the
key in question could cause issues if a completely new data
structure was sent to the backend that was not mirrored by
the default settings. Things like e.g. complex configuration
items in a by default empty object.
sarge's "wait_events" is unreliable. If an asynchronous
job is started but stops immediately and raises a sarge
Exception (inside the async thread), the associated
command's event will never be set event though the
process finished. So we'd wait indefinitely here.
We circumvent this by first waiting until the commands
are parsed and processed (p.commands contains
elements), then until said commands are started and then
making sure the command's process is actually set. Only
then do we actually have a background process running
that we'll be able to monitor further down, otherwise
the command immediately failed.
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).
If the SettingsUpdated event for whatever reason got slightly delayed and arrived AFTER
the save request was already processed, in rare situations it could happen that the
"Settings Changed" popup was triggered even though the settings had already been
successfully saved.
Modified such that we now keep track of if we already saw the SettingsUpdated event
associated with our save request and if not we ignore the next one.
To ensure that we don't get out of sync due to that when a settings update request is
sent, but no settings are actually change, we also now always trigger the SettingsUpdated
event, even in such cases. Clients can use the hashs in the payload to test if something
actually changed - if necessary.
We used to track our webcam stream URL by the global variable
CONFIG_WEBCAMURL. That's still a left over from the architecture
about four years ago and completely obsolete these days.
Additionally it causes issues now that anything rendered into
the page (as this variable value is through initscript.jinja2)
will not be changed unless the page cache is refreshed.
Taking the stream URL from the settings view model instead
solves that problem and is way cleaner anyhow.
If there are custom system menu entries for restart, reboot and/or
shutdown, they are deleted. If the corresponding server command is
not yet configured, the command from the system menu entry is
transfered.
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.
If enabled (which it is by default), OctoPrint will now send
an M115 to the printer on initial connection in order to try
to figure out what kind of firmware it is. For FIRMWARE_NAME
values containing "repetier" (case insensitive), all Repetier-
specific flags will be set on the comm layer. For FIRMWARE_NAME
values containing "reprapfirmware", all RepRapFirmware-
specific flags will be set on the comm layer.
For now no other handling will be performed.
Timing issue, "OctoPrint.job.start()" would be called at a time
when the file had not yet been selected on the server. Hence
a different approach, calculating printerAfterLoading parameter
based on existing information at the time of clicking the
load button and using the print parameter on the select
file API again, as previously.
That bounding box may have larger dimensions than the print volume
(but not smaller ones). That allows to define safe areas for which no
"exceeds print volume" messages need to be triggered.
Solves #1551
Otherwise the cache of /api/settings would not be properly invalidated
on a change in either the user login state or the set of active plugins.
See also #1576
The way it was before, the function would also return itself. This isn't really a problem here, but if someone takes this function as a guide (like me) they can run into problems when iterating over the returned array, as it contains an element representing "values()" itself.
Another approach would be make use of the inspect package and replace name="values" with inspect.ismethod(name)
When setting the tracked target temperature from a sent temperature
command, the changes in tracked temperature were not propagated
from the comm layer to registered callbacks.
But since the standard printer also didn't make a copy of the mutable
dict of tool temperatures, those were in fact updated even without
propagation in the printer implementation when the values in the
comm layer got updated, whereas the bed temperature - an immutable
tupel - was not.
Two wrongs sometimes do in fact make a right. In this case that led
to target temperature changes on the tools immediately reflecting
in printer.get_current_temperatures after the command was sent,
but changes to the bed target taking until the next M105 response
to propagate.
Decoupling the data structures and adding propagation commands
to the comm layer solves this issue.
Fixes#1543
-r only allows a limited set of target framerates according to the mpeg2
standard, but -framerate allows to specify how long each frame should
be shown, giving us full control over "virtual" fps without causing errors
when the user selects a non-standard frame rate
Long lines (longer than rx buffer) could not be processed at all, leading
to a serial timeout exception thrown by the virtual printer. Adjusted
to allow for partial processing like on maintenance
That way a JS error in an external plugin won't nuke the whole UI, which IMHO
is worth the additional requests needed to load the split up files.
See #1544 for an example of such a situation.
The bug only manifests if a user had installed 1.2.16 earlier and never once hit "Save" in the
settings before attempting to update to 1.2.17. With 1.2.16 the updater script and settings for
OctoPrint's own update mechanism were changed to prefer "checkout_folder" instead of
"update_folder". In earlier versions however "update_folder" was still used. Saving settings
even once (even without any changes!) will migrate the data. But if that's not done a
KeyError will be raised when trying to retrieve "update_folder" from the check config, with
"checkout_folder" as its fallback.
Rather stupid error really.
* 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
Filter toggling didn't remove the specific filter but always the last item
in the filter list. No, I don't know either why I didn't notice this earlier m(
If a content type header was present on a multipart form data part it would turn
the rewritten body into a unicode instead of a byte array, causing a later conversion
to a byte stream to not capture.
Fixed both the fact that the rewritten body would turn into unicode by making
sure the content type header was provided as byte array and fixed the byte stream
conversion to also trigger on unicode instances.
Solves #1531
To answer https://github.com/foosel/OctoPrint/issues/1048 I changed L357 to "output += gettext("Last Print Time") + ": " + formatDuration(data["prints"]["last"]["printTime"]);" as proposed by @ntoff
Only keep the cache keys, but that way we know when
we were going to cache something and then didn't
due to environmental factors, e.g. headers on request
or response.
Necessary to be able to track if the preliminary caching
has been done during startup to properly reflect that
on cached.gif
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
Was marking the config as dirty just when printerParameters entry existed,
which always exists - various sub entries of that are what needs to be checked
instead.
Example:
* both "session" and "session_P5000" cookies available: "session" value from "session_P5000"
* only "session" cookie available: "session" value from "session"
* only "session_P5000" cookie available: "session" value from "session_P5000"
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.
Solves an issue with clients encoding filenames in multipart
headers in ISO-8859-1, causing an HTTP 500 response code.
This change makes ISO-8859-1 encoded headers work, sends
a 400 Bad Request instead of 500 Internal Server Error if the
request multipart headers cannot be decoded as either UTF-8
or ISO-8859-1, defines UTF-8 content type for multipart text
fields in rebuilt body and also adds support for RFC 5987 for the
multipart file upload "filename" header component.
* make sure server_port headers are properly set in reverse proxied scenarios
* overwrite request and response classes to
* always apply reverse proxy environment changes (so far missing for tornado
context)
* strip cookie name suffixes from cookie names on requests and
* be sure to set cookie name suffixes for cookie names on responses
* include script root in path used for cookies
* some minor refactoring in octoprint.server setup routines
* removed ReverseProxied class (didn't work for tornado context)
* add unit tests for the whole reverse proxy, request and response customization
(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)
Removed unnecessary (and broken) call to event.preventDefault,
moved styles to less/css and also made sure to disable the buttons
not currently usable.
Most caching is left to the client, by utilizing ETag and Last-Modified headers.
Where it was easily achievable, an additional server side miniature cache of intermediary
results was introduced (e.g. for the files). The regular cached decorator was not used
since it targets caching full responses, and the responses in question already contained
client request specific data. Caching "one step earlier" allows better usage of the cache here.
Also introduced a dependency on the scandir module, to get a bit of a performance boost
on os.walk and os.listdir (which have been replaced with scandir.walk and scandir.listdir
respectively). See https://github.com/benhoyt/scandir#background on why that made
sense.
