Feature Overview
The UI should render correctly across the full range of supported screen resolutions (320×480, 720×720, 720×1280, 1024×600) without any screen-specific special-casing, particularly for the 1024×600 landscape panel where portrait-oriented layouts can overflow or waste space.
Current Implementation
The UI uses hard-coded pixel constants for sizes, positions, and spacing throughout the page and widget code. These values were chosen for the primary 720×720 target and do not scale correctly on the 320×480 display (overflow/clipping) or on the 1024×600 landscape panel (oversized elements, wasted vertical space).
Proof of Concept Implementation (3rdIteration Repo)
main/ui/theme.c takes a fully proportional approach: at startup, theme_init() reads lv_disp_get_hor_res() / lv_disp_get_ver_res() and derives all size constants from scr_w (e.g. button width = scr_w * 5/24, padding = scr_w / 24, minimum touch target = scr_w / 8). Font size is switched at a breakpoint of scr_w >= 600 (Montserrat 24/36 on large displays, 16/24 on the 320-wide panel). The theme.h accessor functions (theme_button_width(), theme_default_padding(), etc.) form the public contract so individual pages never need pixel constants. The existing CI screenshot tour validates all resolutions on every build.
Design Decisions / Trade-offs to Consider
- Portrait vs. landscape layouts: The 1024×600 CrowPanel is the only landscape display. At 1024 px wide, scr_w-derived heights produce very short buttons. A secondary layout mode (or a scr_h-derived cap on button height) may be needed.
- QR code sizing: QR codes must be large enough to be scannable but should not overflow the screen. The viewer/encoder should derive QR size from min(scr_w, scr_h) rather than scr_w alone.
- Font breakpoints: A single breakpoint at 600 px covers most cases but may need a third tier for the 1024×600 panel where 36-pt fonts produce very tall menu items relative to the 600-px screen height.
- Scroll vs. fixed layout: On the 320×480 display some menus may need to scroll; on larger displays the same content fits without scrolling. LVGL's LV_OBJ_FLAG_SCROLLABLE provides this, but the trade-off is visual consistency.
Next Steps
If there are specific changes/tweaks or considerations then they can be discussed here. I can bring a PR once there has been some space for this discussion. (Unless someone else is already working on it or it gets NACK'd)
Feature Overview
The UI should render correctly across the full range of supported screen resolutions (320×480, 720×720, 720×1280, 1024×600) without any screen-specific special-casing, particularly for the 1024×600 landscape panel where portrait-oriented layouts can overflow or waste space.
Current Implementation
The UI uses hard-coded pixel constants for sizes, positions, and spacing throughout the page and widget code. These values were chosen for the primary 720×720 target and do not scale correctly on the 320×480 display (overflow/clipping) or on the 1024×600 landscape panel (oversized elements, wasted vertical space).
Proof of Concept Implementation (3rdIteration Repo)
main/ui/theme.c takes a fully proportional approach: at startup, theme_init() reads lv_disp_get_hor_res() / lv_disp_get_ver_res() and derives all size constants from scr_w (e.g. button width = scr_w * 5/24, padding = scr_w / 24, minimum touch target = scr_w / 8). Font size is switched at a breakpoint of scr_w >= 600 (Montserrat 24/36 on large displays, 16/24 on the 320-wide panel). The theme.h accessor functions (theme_button_width(), theme_default_padding(), etc.) form the public contract so individual pages never need pixel constants. The existing CI screenshot tour validates all resolutions on every build.
Design Decisions / Trade-offs to Consider
Next Steps
If there are specific changes/tweaks or considerations then they can be discussed here. I can bring a PR once there has been some space for this discussion. (Unless someone else is already working on it or it gets NACK'd)