It's great that you do the library, and for the gui we already have at least two extensible platforms (pigdgin/libpurple and weechat) so you may consider adapting to one of those, it also makes it easy to have one chat client for all needs.
Diverging from the topic slightly, I'm very concerned by the state of VNC today. A few years ago it was thriving and there were many open source clients and servers competing, with active communities.
RealVNC took over the lead of active development, and seemed to successfully undermine all the competing projects. But then RealVNC went closed source and nothing ever appeared to fill-in for them after.
UltraVNC seems to be the only healthy VNC community, but it is sadly a Windows-only project, with their own extensions which don't appear in ANY other client (except for ssvnc, which is now dead). This means non-Windows clients don't get the benefits of UltraVNC developments, and may not work at all (e.g. the one-click UltraVNC package won't work with any other vnc viewers).
TightVNC is still limping along, but now as a Windows-only.
TigherVNC is alive, but only just doing the basic maintenance needed, and lagging behind at that. Doesn't look like non-essential but highly useful features will ever get worked on there.
VNC servers are increasingly having show-stopping problems with modern Linux desktop environments. Projects like GNOME keep using more GPU hardware-acceleration where no fallback exists and no workaround is available for vncserver/Xvnc even quite some time after.
It seems a dire state of affairs. We're losing the standard, open source, platform independent and interoperable remote display protocol we all took for granted for the past several decades, and nothing on the horizon looks like any improvement to this state of affairs will be forthcoming. Those projects still active are fracturing off with proprietary changes limiting or even preventing interoperability. Am I missing something?
> Both QT and Gnash run on the framebuffer, there is no X server, so a regular VNC client will not work.
Tip with Qt: you can use QT_QPA_PLATFORM=vnc and the Qt app will be exposed over vnc (if you have the plug-in installed / linked ofc). Pretty useful for testing embedded hardware from your desktop (not for deployment though, as it will be the only way your app will be rendered)
The QT version compiles as a desktop app as well. It uses an HTTP api to the coffee machine. Normally only localhost, but for development I can tunnel that port over ssh, so from my desktop I can use "actual" hardware. Same with Flash/Gnash, ssh tunnel and a local instance (recently made a snap for that: https://raymii.org/s/blog/Ive_packaged_up_Gnash_as_a_Snap_fo...).
But thanks for the tip, I'm going to try that and see how it works. Maybe even get the old machine running the new UI via vnc.
I have to say I find it incredibly fascinating you're actually using Gnash to support a Flash-based UI. Were you previously using the official runtime and switched over to Gnash, or was Gnash always the runtime target? If the former, how'd the transition work out, and were there any hitches / do you have to do things differently now?
Based on a few (possibly old) videos of the Nio I found that show the touchscreen for a couple of moments the system appears to have fairly high input latency (~1.5s), and zero realtime feedback (eg, no "pressed" state indication). Hrm.
FWIW, I've been looking around for quite some time for a general-purpose way to do easy-to-maintain UI design that isn't Gambas Basic ("how to basic?") or Electron ("what is RAM?"), and my current to-have-a-look-at is actually the drag-and-drop layout builder in the Godot game engine, which has a 2D mode, and from what I've seen of it is rather fast and makes reasonable efforts toward performance.
My site does yes, from the Espresso Web Server (https://raymii.org/invalid) - but that is just an nginx trick. That was in place way before I started at this company.
Check the other HTTP headers for more fun.
The coffee machines themselves have a HTTP api but not the HTTP coffeepot protocol. Just something custom.
This is close one of the motivating use cases for VNC if recall correctly: touch screen office phones (over ATM I think). Instead of making the phones smarter and adding/customising buttons, just thin-client them all with resistive touch screens. You'd have a controlling box already on site (PABX or whatever) and the the deployment would be homogeneous per site. Right until entirely softphones replaced them, all the office I worked in still used awful WinCE or whatever local OS even though they spend 99.9% of their time doing nothing or just showing call progress. Strange it didn't catch on (anywhere I noticed I mean!)
We have one of those exact machines at the office. It's okey. The coffee is alright. The number codes are a nice feature. It's annoying that the cup sensor doesn't recognise transparent glasses so you have to hold your finger over the sensor if you want a glass of water. I can't figure out why they wouldn't use a ultrasonic sensor. Oh well. First World problems.
The common water fountain/bottle refill stations I've seen in buildings often are from the same company and they all use this kind of sensor. If I use my reusable bottle that is pretty clear it has no idea it's there and I have to use my finger too. And this device is literally designed for the purpose of refilling bottles with water. If I use the same brand of reusable bottle but one that has colour on it then I have no problem.
Or the (wip) TUI: https://github.com/fossteams/teams-cli/