Implement TouchScreen UI

[andrescera]

🎯 Goal

Choose the most maintainable and efficient approach to build a touchscreen interface for a headless Linux system.

• No full desktop environment (X11/Wayland used only as needed)
• Touchscreen input support required
• Access to backend over HTTP/WebSocket or tRPC
• Low memory and CPU overhead
• Auto-launchable on system boot

🎨 Mock-up

---

🔍 Options

---

✅ Option 1: Web-based UI (Svelte + Chromium in Kiosk Mode)

• Build UI in Svelte or other frontend framework
• Serve UI using existing Node.js backend
• Launch Chromium browser in kiosk mode on boot
• Communicate with backend using WebSocket or tRPC over HTTP

Pros:

• Lightweight RAM footprint (~100–150 MB)
• Easy to iterate and debug via browser tools
• Clean separation between UI and logic
• Touchscreen support is native in Chromium
• Full use of modern JS/HTML/CSS ecosystem

Cons:

• Needs Chromium, X11, and some boot config (systemd, xinit, etc.)
• Slight complexity in boot-to-kiosk automation

---

🔧 Option 2: Native Toolkit (GTK, Qt, LVGL, etc.)

• Use GTK (via Python or C) or Qt/QML for UI
• Directly access GPIO or backend via native code
• May run without X11 if using framebuffer or Wayland

Pros:

• No browser overhead; potentially lower memory if minimal UI
• Native access to hardware and display
• Can be faster for extremely simple UIs

Cons:

• Higher development complexity
• Fewer modern UI/UX tools
• Slower prototyping and debugging
• Less flexible/responsive for layout or animations
• Often larger compiled binary sizes than a web app

---

🚧 Option 3: Embedded GUI Libraries (LVGL, Tinker, etc.)

• Use C-based GUI toolkit like LVGL, Tinker, or DirectFB
• Run in framebuffer mode (no X11 required)
• UI tightly coupled with hardware logic

Pros:

• Extremely low memory and fast rendering
• Real-time UI performance
• Ideal for microcontrollers or tiny Linux builds

Cons:

• UI design is tedious (C-based layout, fixed pixels)
• Lacks rich input, animation, network handling
• Limited extensibility for future needs
• Small contributor community (hard to hire or scale)

---

🔄 Decision Factors

Factor	Chromium + Web	GTK/Qt Native	LVGL/Tinker
Dev speed	✅ Fast	⚠️ Moderate	❌ Slow
Touchscreen support	✅ Native	✅ Native	✅ Native
Backend integration	✅ Easy (HTTP/tRPC)	⚠️ Manual APIs	❌ Complex
RAM footprint	⚠️ 80–150MB	✅ ~50–100MB	✅ ~10–30MB
UI flexibility	✅ High	⚠️ Medium	❌ Low
Animations/UX polish	✅ Yes	⚠️ Limited	❌ Very basic
Kiosk mode / fullscreen	✅ Simple	⚠️ Manual setup	✅ Native
Team scalability	✅ Web skills	⚠️ C/C++/Python	❌ C only

---

✅ My Favorite

Unless extremely tight hardware constraints demand otherwise, Option 1: Web-based UI (Svelte + Chromium kiosk) is the preferred approach due to:

• Faster development and iteration
• Easier maintenance and scalability
• Native touchscreen support
• Integration with existing Node.js backend
• Acceptable performance on most embedded Linux systems

---

📎 Next Steps

• Finalize decision
• Define tech stack (Svelte Library)
• Prototype kiosk launcher script (systemd or .xinitrc)