You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same DeslanStudio side-by-side that produced #593: after text, the second first-impression gap is widget chrome — the port's controls read as flat gray rectangles next to the Qt prototype's.
What already exists upstream (verified on main before filing)
gfx_rrect (filled rounded rectangle, scanline quarter-circle corner fill in C) exists and is registered; lib/ui buttons, menus, and tabs already draw through it with _theme.radius_sm.
So the flat look is no longer a missing-primitive problem. What remains:
Remaining gaps
lib/ui: button has no per-widget color overrides — transport-style color-coded buttons impossible #566 (priority): per-widget button colors._render_button reads _theme.btn_bg/btn_text unconditionally, so semantic coloring (record-red, play-green, destructive-red) is impossible; DeslanStudio dropped its transport colors over this (PORTING.md F-DS-12). Honor optional bg/text_color dict fields with theme fallback — toggle_button (color_on/color_off) and label already have the per-widget pattern.
Hover feedback is effectively button-only.checkbox and toggle receive hover from dispatch but their render functions ignore it. A theme hover-shade overlay (translucent white/black gfx_rrect over the widget, alpha-blended) gives uniform hover/pressed feedback that also works on custom-colored widgets — a plain color swap to btn_hover would erase a custom bg.
Finding
Same DeslanStudio side-by-side that produced #593: after text, the second first-impression gap is widget chrome — the port's controls read as flat gray rectangles next to the Qt prototype's.
What already exists upstream (verified on main before filing)
gfx_rrect(filled rounded rectangle, scanline quarter-circle corner fill in C) exists and is registered; lib/ui buttons, menus, and tabs already draw through it with_theme.radius_sm.ui_dispatchmousemove setswidget.hover(the lib/ui: canvas on_mouse never receives mousemove — no drag interactions possible on a custom-painted widget #567 input trio shipped in v0.30.0), and_render_buttonusesbtn_hover/btn_pressed.So the flat look is no longer a missing-primitive problem. What remains:
Remaining gaps
_render_buttonreads_theme.btn_bg/btn_textunconditionally, so semantic coloring (record-red, play-green, destructive-red) is impossible; DeslanStudio dropped its transport colors over this (PORTING.md F-DS-12). Honor optionalbg/text_colordict fields with theme fallback —toggle_button(color_on/color_off) andlabelalready have the per-widget pattern.checkboxandtogglereceivehoverfrom dispatch but their render functions ignore it. A theme hover-shade overlay (translucent white/blackgfx_rrectover the widget, alpha-blended) gives uniform hover/pressed feedback that also works on custom-colored widgets — a plain color swap tobtn_hoverwould erase a custombg.gfx_rrectandgfx_clipare registered but missing from docs/BUILTINS.md — an undiscoverable primitive reads as absent (the CI gate: every builtin and public stdlib function must be documented (regex_* currently appear nowhere) #393 failure class; downstream keeps believing there is no rounded-rect).Minimal first slice: (1) plus the hover/pressed shade for buttons; the rest lands incrementally.