So far we only supported \n and \r\n, leading to problems with MM
GCODE files generated by Slic3r Prusa Edition which apparently
produces \r line endings for some reason.
Closes#1996
Clicking terminal output (excluding highlighting) will set focus to terminal command
Change fancy functionality style from muted to warning so that it stands out more
We won't support this after all, it's too much of a headache with
regards to the sending queue. Pausing takes longer, cancelling takes
longer, resends get more complicated and so on.
Command expansion in the queuing phase needs to suffice.
E.g. in case of a disconnected thermistor, or when it is really
really cold. Make sure our parsing doesn't get confuse by this and
thinks that
ok T:150.0/210.0 T0:-55.7/0 T1:150.0/210.0
is actually only T and T1 being reported by the firmware, causing
stuff to be wrongly canonicalized thanks to T/T1 being Smoothie's way
of reporting dual extruder setups.
Fixes#2007
Introduced a custom send queue type that actually contains two queues,
one for resends, one for regular lines. A flag indicates whether
lines should be returned from both or only resends. That way we
ensure that as soon as we have an active resend request we ignore
what was already in the queue and only send the lines we need to resend.
Also: PrependQueue => PrependableQueue
Less tracking of offsets and also more similar to how
firmware does this.
We rewrite our current position on tool change to current position
plus tool offset instead of applying it for every single
position change.
We fetch settings once explicitly after passive login but before
completed startup. Without this patch we fetched them again after
onUserLoggedIn got fired (if it got fired by the passive login)
during startup. That's not necessary because we did the passive login
before our initial settings fetch, so IF that already logged us in,
our settings fetch already was done with us logged in as well and
the onUserLoggedIn later only tells us what we already knew.
We still had some concurrent requests triggered through onStartup that
managed to overtake the passive login (and hence nuke the session
data on the client). This should now really not be possible any longer.
Also created a sequence diagram of the new process and linked it from
a lengthy comment.
