Scripts app improvements

[CRImier]

The "scripts" app could use some improvements:

• [ ] Command history
• [x] Replacing Printer(ffs()) calls with a TextReader, so that it's possible to properly read the output (thanks to @monsieurh )
• [ ] Optional: making the "Run random commands" option more discoverable in some way (ideas? )
• [x] Improved reading things like dmesg logs, where it's not clear which line has start of the new line and which is the continuation (thanks to @monsieurh )

For even better usability, Scripts app could really use some kind of terminal emulator (todo: research if luma.core.virtual.terminal could be used).

[BeauSlim]

I've played with luma's terminal a bit. It is more of a terminal-mockup than a virtual terminal. It could definitely be a good start to a log lister, though.

There are a few options for real terminal emulation that I've found. One is to use tmux or screen and do text-mode screen dumps and then just render those to the OLED as if they were text. A similar solution is a Python library called vt102.

Scraping tmux or screen is a very reliable, if inelegant, method. vt102 will probably make it easier to interact with the terminal from the python side of things assuming the terminal emulation is okay.

EDIT: I guess pyte is a more recent fork of the vt102 library. I'll play with it and see what I can come up with. It looks useful for all kinds of things.

The fbtft frame buffer driver is another solution. I haven't tried it because my OLEDs are i2c and the driver is SPI only, but I hear it works really well. Set a tiny font and you have a real console with all the features.

[CRImier]

Pyte library - noted, thank you! If you come up with something, let us know, we can help improve upon it =)

fbtft is, indeed, a known-to-work solution, it's just that using it together with ZPUI is not straightforward. I wonder if it'd be easy to add a Linux framebuffer backend to luma.core... BTW, I also wonder if fbtft could get an I2C backend - it already has separate SPI and parallel interface backends, so it might be more or less straightforward to add one more.

[BeauSlim]

Well, pyte made a quick demo really easy. Hmm, my screen cap is blurry on GitHub for some reason. No matter:

See https://gist.github.com/BeauSlim/c1db4e912347bb94eaad1f79e325109c

There actually is a separate i2c driver for some OLED displays. There is a thread in the Raspberry Pi forums about it, with everyone saying "this doesn't work". I tried, even sorting out device tree issues, but no joy. If I remember correctly, it won't work if your display has no "reset" pin, which includes mine. It's not a big deal.

[CRImier]

It looks great! Will be considering it, then =) Blurry? Don't see any blur, it looks the same as other screenshots I've made through PIL. I'm guessing it's browser zooming problems, they can't handle our pixelart =)

AFAIK you shouldn't need to think about device tree until the moment you want the display to run at boot, so modprobe-ing fbtft modules should still give the same result. Also, the RESET pin, if it's not supplied by the OLED breakout, shouldn't be required - displays that don't have RESET typically have autoreset of some sorts, like I have on some of my OLEDs that don't have RESET... Now that I think of it, I haven't actually checked if RST-less OLEDs work with framebuffer! Will check sometime soon and report back.