preferences doesn't allow to tab to next field #28

Closed
opened 2026-07-26 08:00:18 +00:00 by hugo · 1 comment
Owner

fields are not linked via tab and shift-tab to jump between fields in preferences

fields are not linked via tab and shift-tab to jump between fields in preferences
hugo added the bug label 2026-07-26 08:00:18 +00:00
Author
Owner

Done in a0c3a72, 6717249, c5e812f and 1dcadeb.

Iced has no tab-order property: text_input deliberately returns Status::Ignored for tab so the application moves the focus itself. Tab and shift-tab now map to focus_next/focus_previous, and the order is the widget tree order, which is already the visual order of the fields.

Three things came out of that:

  • Focus is global to the widget tree, not to a window (iced applies focus operations to every window in one pass), so the chat composer behind an open dialog took a turn in the dialog's field order. Behind a modal it now renders as an unfocusable look-alike, which also covers the rename and project-name dialogs.
  • Moving the focus does not scroll, so tabbing past the fold typed into a field nobody could see. A two-pass widget operation now locates the focused row and scrolls the preferences area by the smallest amount that brings it into view, with a 12px margin. Layout keeps scrollable content in unscrolled coordinates, so the current offset has to come off the row's position first — the arithmetic is unit tested, including the scrolled case.
  • Escape never reached the panel once a field had focus: a focused text_input consumes escape to drop its own focus and marks the event captured, and on_key_press only sees uncaptured events. Escape is now listened for regardless of capture, so it cancels the preferences panel again.
Done in a0c3a72, 6717249, c5e812f and 1dcadeb. Iced has no tab-order property: text_input deliberately returns Status::Ignored for tab so the application moves the focus itself. Tab and shift-tab now map to focus_next/focus_previous, and the order is the widget tree order, which is already the visual order of the fields. Three things came out of that: - Focus is global to the widget tree, not to a window (iced applies focus operations to every window in one pass), so the chat composer behind an open dialog took a turn in the dialog's field order. Behind a modal it now renders as an unfocusable look-alike, which also covers the rename and project-name dialogs. - Moving the focus does not scroll, so tabbing past the fold typed into a field nobody could see. A two-pass widget operation now locates the focused row and scrolls the preferences area by the smallest amount that brings it into view, with a 12px margin. Layout keeps scrollable content in unscrolled coordinates, so the current offset has to come off the row's position first — the arithmetic is unit tested, including the scrolled case. - Escape never reached the panel once a field had focus: a focused text_input consumes escape to drop its own focus and marks the event captured, and on_key_press only sees uncaptured events. Escape is now listened for regardless of capture, so it cancels the preferences panel again.
hugo closed this issue 2026-07-26 08:28:33 +00:00
Sign in to join this conversation.