dominic/Tactility
1
0
Fork 0
mirror of https://github.com/ByteWelder/Tactility.git synced 2026-08-17 23:55:04 +00:00
Code Issues Packages Projects Releases Wiki Activity
Tactility/.claude/rules/lvgl.md
Ken Van Hoeylandt d6b1d15e56
Various improvements (#614) 
- Auto-select widgets in Launcher and apps with toolbars on devices without touch.
- Improved USB HID input reliability, cleanup
- Updated PSRAM settings to improve boot stability on supported devices.
- Prevented duplicate Wi-Fi event subscriptions during screen rebuilds.
- Updated docs
- Fixes in WifiManage and WifiConnect
- Reduced main task stack size
- Moved USB HID stack size to PSRAM when available
- app_manager_find_manifest() now returns a copy instead of a pointer
2026-08-13 20:30:47 +02:00

1.7 KiB
Raw Blame History

Architecture: LVGL

User interfaces should scale well for everything between very large (e.g. 1280x720) and small (e.g. 135x240) displays. Vertical and horizontal layouts are supported.

Two kernel modules cover LVGL:

  • lvgl-module (Modules/lvgl-module/, <lvgl/*.h>) owns LVGL's lifecycle: init/deinit, the LVGL task loop, and lvgl_lock()/lvgl_try_lock()/lvgl_unlock() mutex-based locking that any task must hold before touching LVGL objects. It bridges Tactility's device model to LVGL indevs (lvgl/devices/*.h: display, pointer, keyboard, trackball), and provides shared fonts (lvgl/fonts.h: Montserrat text sizes, Material Symbols icon sets for statusbar/launcher/shared use) and a few shared widgets (lvgl/widgets/*.h: toolbar, spinner, sliderbox).
  • lvgl-window-manager-module (Modules/lvgl-window-manager-module/, <lvgl_window_manager/*.h>) manages a single stacked window per app instance on top of lvgl-module. window_manager_start()/window_manager_stop() create/tear down the root widget (plus optional chrome from a configured WindowManagerScreenInitFn); window_manager_create()/window_manager_remove() push/pop an app's window and (re)populate it via a WindowCreateWidgetsFn. Only the topmost window ever has live widgets - burying and resurfacing a window deletes and rebuilds its widget tree rather than hiding/showing it. That rebuild-on-remove path can run create_widgets on a different app's thread (whichever app's window_manager_remove() call caused this window to resurface), so create_widgets must only rebuild already-committed state, never decide what happens next - state transitions belong in the app's own main() event loop, driven by real APP_EVENT_RESULTs.