You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Might be a long shot but one thing I can think off is the following:
Install https://plugins.octoprint.org/plugins/actioncommands/
Create a GCode there that calls a script which opens Firefox with the correct URL for TouchUI
Two things I'm not 100% sure about are though:
How are you going to close Firefox again (don't know if ratpoison does show the close button)
How ratpoison handles the whole thing
Just something to try maybe if you have an hour or two to spare :)
You must know that it seems to be a solution ; I didn't play with actioncommands, as I don't understand how to send a command if we can't log in... But I installed xterm and firefox, and successfully opened a firefox window (from SSH) over OctoDash, and wasn't "log loop-ed". And later closed it with CRT-ALT-BACKSPACE.
one solution would the ability to issue a shell command line from the Custom Actions...
For now, I will eperiment further, with a push button hooked to the GPIO, and toggling Firefox (I can only code bare metal C++, and know nothing about Electron, NodeJS, etc.)
But it is of no interest as it's impossible to go back to OctoDash : ratpoison doesn't add a close button (it probably doesn't even know X opened a window). ctrl alt backspace does nothing in kiosk mode.
I will stick with my idea and add some "system()" calls in order to switch between UIs, pushing on (a) real world button(s). A 10 cents button, a resistor, a capacitor, 2 wires and a few hundred lines of C vs tons of plugins and more or less interoperability...
Switching from one UI to another is not a good idea. It has to be managed at a much lower level;
.
The text was updated successfully, but these errors were encountered:
What doesn't work?
the command in the title ! It is in the examples and doen't work !
For well known and discussed reasons.
It should be removed...
What did you already try?
in issue #1166 , you suggested that :
Might be a long shot but one thing I can think off is the following:
Two things I'm not 100% sure about are though:
Just something to try maybe if you have an hour or two to spare :)
You must know that it seems to be a solution ; I didn't play with actioncommands, as I don't understand how to send a command if we can't log in... But I installed xterm and firefox, and successfully opened a firefox window (from SSH) over OctoDash, and wasn't "log loop-ed". And later closed it with CRT-ALT-BACKSPACE.
one solution would the ability to issue a shell command line from the Custom Actions...
For now, I will eperiment further, with a push button hooked to the GPIO, and toggling Firefox (I can only code bare metal C++, and know nothing about Electron, NodeJS, etc.)
In fact, I'd like a companion app, similar to this one I'm developing : see here, you will understand : https://www.youtube.com/watch?v=vd2Wgo4UeBw
A button, that allows the user for switching between Marlin, OctoDash, OctoPrint, TouchUI and whatever UI is installed.
And I'm not sure that launching an environment from inside another one is a good solution. IMHO, a hardware button is probably better.
[EDIT] was able to launch Firefox and get access to TouchUI from OctoDash , with a shell command in OctoPrint
command = touchui -> DISPLAY=:0 firefox --kiosk http://127.0.0.1
(no need for the touchui option if it is set to detect a touch screen)
In config.json :
But it is of no interest as it's impossible to go back to OctoDash : ratpoison doesn't add a close button (it probably doesn't even know X opened a window). ctrl alt backspace does nothing in kiosk mode.
I will stick with my idea and add some "system()" calls in order to switch between UIs, pushing on (a) real world button(s). A 10 cents button, a resistor, a capacitor, 2 wires and a few hundred lines of C vs tons of plugins and more or less interoperability...
Switching from one UI to another is not a good idea. It has to be managed at a much lower level;
.
The text was updated successfully, but these errors were encountered: