Octoprint: [brainstorming] OctoPrint Touch

[mmajko]

Hey guys, this particular idea came to my mind...

What if you could just buy cheap touch LCD display from eBay, connect it to the RPi, and the OctoPrint installer (or some post-install script) asks you a simple question: "Do you have display blah-blah connected to your RPi?" - if so, it would download and setup some plugin/extension and gain you ability to control your printer through that touch panel?

The thing is RPi is much more powerful to provide better UI than printer's firmware. That can provide powerful possibilites, it should be more comfortable, it can show useful information, like name of the printer, its IP address and stuff...

The main disadvantage I've thought of, is losing some firmware features that are accessible only through the display on some printers. Or is there a way how to control even this features? Like browsing an SD card inserted into the device?

It could look like this (I've been procrastinating a little bit today, don't take it too seriously, it's just some draft made just for fun)

Can you find any more pros, and more importantly - cons to this idea?

Don't take this too seriously, maybe it's just a silly idea. But I wanted to share it with you, I hope you don't mind.

[JustAnother1]

A M20 command should show the files on the SD card to the host.

Touch screens are usually just a mouse that reports absolute coordinates instead of relative moves. So it basically is a matter of having a different GUI so to speak on the PI, right?

[mmajko]

@JustAnother1 Practically, yes.

It could be just a some sort of "skin" for existing web interface, and RPi can just automatically run web browser in full screen on startup, displaying localhost OctoPrint with skin designed for touch screens.

But I'm worried about performace, I would rather see native app for this.

[JustAnother1]

I see two option. With the new UI API in Version 1.3.0 this might be a job for a plug in.

If the performance becomes an issue then a separate application is needed that uses the API.

I do not know if performance is an issue. My guess would be that what you show in your pictures should not be a problem. I would guess that the web cam might become a problem. But for a local interface you probably don't need the web cam view anyway.

You might want to take a look at the 1.3.0 and check if a plug-in is what you want.

[timothyhollabaugh]

I believe that the best option here would be to have a separate process running on the Pi (or other computer) that talks to Octoprint through a websocket connection and the REST API. I have been working on Octoscreen lately, which does exactly that. I am currently running it on a Raspberry Pi 3 with an official touchscreen display, although it will also run on a Pi 2. I am unsure about anything below a Pi 2. It uses the API available through the octoprint_client package provided with Octoprint, although it would not be difficult to modify to not require this. It uses Kivy for GPU accelerated graphics, and works great so far.

Kivy is great in that it will run on almost any OS, Linux Mac, Windows, and even Android. This means that the GUI would not be limited to just a Pi. I believe it is better than a web browser because that would mean starting up an X session just to run a single web browser fullscreen. I have also found that web browsers on a Pi tend to be a bit CPU and memory heavy can are not fully GPU accelerated.

It was originally an Octoprint plugin (Still available here, but is a little outdated), but the Pi became a bit slow. I found out that the reason was that although I was running the display code in a separate Python thread, the standard Python interpreter cannot run its threads as separate Linux processes, and thus they cannot run on separate cores on the Pi. This would cause the interface to freeze whenever Octoprint did something CPU heavy, such as when uploading a file, starting a print, or cancelling a print.

I have found that running the GUI as a separate process not only gives performance benefits, but also give enormous flexibility that would not be possible though an Octoprint plugin. It allows the GUI to be started, stopped, and restarted completely separate from Octoprint. It also allows it to run on an entirely separate computer, such as a tablet, giving even more flexibility and even mobility.

I have always thought the idea of having a display connected to the printer control board a little silly, in that the printer control board should control the printer, not deal with user input.

I am not quite sure if Octoprint should prompt the user to install a GUI automatically, or rather it should simply point the user in the right direction. Something like "If you have a display, look at these nice GUI apps" and provide a link. I am thinking that Octoprint should not be bloated with too much display stuff many users don't have the hardware for.

[mmajko]

@chickenchuck040 I like your project, this is practically exactly what I wanted to do. But I don't like the GUI design, I find it too generic, sorry. It looks like Android's unstyled gui. How about some collaboration? I would like to participate :)

So we can probably close this issue here, and I should rather beg @chickenchuck040 on the Octoscreen repo, to allow me improve his GUI design. :)

[timothyhollabaugh]

Thanks for the feedback! I agree about the GUI design, I would also prefer it to be more unstyled. It currently uses Kivy's default styling, and I have not gotten around to changing it. Open an issue on the Octoscreen repo if you want to discuss it more.

[foosel]

Just for the record, I love it how that just led to a potentially awesome collaboration and am looking forward to see what comes out of this :)

[brewpirate]

@chickenchuck040 do you want some help with the UX/UI? I have a background in graphics and a python developer in a start-up. Interested in learning Kivy.

[timothyhollabaugh]

@brewpirate Take a look at the new TODO.md