Help: one global shortcut that shows the current screen's key bindings, and no more hint lines #69

New Issue

2026-10-06T20:16:37Z

twisla commented

2026-10-06 20:16:37 +00:00

A global shortcut that shows the key bindings of where you are, in any App and on any screen, and with it the removal of the hint lines that every screen draws today.

Why: hints are scattered and inconsistent. Some screens spend a line of a 135-pixel-high display on them (Enter: save \: cancel, Tab: sky, s sort o open h hide-hidden w strong l log, Enter: details c: look again), some list only part of their keys, and some have none (the Storage App's c x v r d n i` are only in the docs). One help key everywhere frees that line on every screen and makes the keys discoverable in the same way throughout.

Shape of it:

Each App (and each page, dialog and viewer inside one) declares its bindings for its current scope: a list of key and action. The help overlay shows that list, plus the global ones (Back, Home, the arrows, the Compose Key).
The overlay is drawn by the shell, not by the App, so it looks the same everywhere, scrolls if the list is long, and closes on any key.
With bindings declared as data, the user guide's key tables on the website could be generated from the same source instead of written by hand (see site/tools/gen_dev_docs.py).

Questions for a design round (Qnn):

Which key? It must work during Text Entry, where every printable key types. Fn+something, as Home is Fn+`? ? cannot be it while typing. opt is the Compose Key, Ctrl and Alt are used by the editors and IRC.
Scope: how does a screen with states (a list, then a dialog, then a text field) say which bindings apply now? A virtual method on App that the foreground App answers each time it is asked.
What stays on screen? Remove every hint line, or keep the ones that are state rather than help (REC 12 points, LOG 42, sort:signal)? A first-run hint that the help key exists?
Memory and flash: the strings exist already in the draw code; as tables they should cost nothing more in RAM (concern/memory only if they don't).
Order of work: the shell and the overlay first, then one App at a time, removing its hints as its bindings are declared, so no screen is ever without either.

Done when (to be refined): the help key works on every screen including dialogs and text fields, no screen draws a key hint of its own, and the freed line is used or left empty on purpose.

A **global shortcut that shows the key bindings of where you are**, in any App and on any screen, and with it the removal of the hint lines that every screen draws today. **Why:** hints are scattered and inconsistent. Some screens spend a line of a 135-pixel-high display on them (`Enter: save \`: cancel`, `Tab: sky`, `s sort o open h hide-hidden w strong l log`, `Enter: details c: look again`), some list only part of their keys, and some have none (the Storage App's `c` `x` `v` `r` `d` `n` `i` are only in the docs). One help key everywhere frees that line on every screen and makes the keys discoverable in the same way throughout. **Shape of it:** - Each App (and each page, dialog and viewer inside one) **declares its bindings for its current scope**: a list of key and action. The help overlay shows that list, plus the global ones (Back, Home, the arrows, the Compose Key). - The overlay is drawn by the shell, not by the App, so it looks the same everywhere, scrolls if the list is long, and closes on any key. - With bindings declared as data, the **user guide's key tables on the website could be generated** from the same source instead of written by hand (see `site/tools/gen_dev_docs.py`). **Questions for a design round (Qnn):** - **Which key?** It must work during Text Entry, where every printable key types. `Fn`+something, as Home is `Fn`+`` ` ``? `?` cannot be it while typing. `opt` is the Compose Key, `Ctrl` and `Alt` are used by the editors and IRC. - **Scope:** how does a screen with states (a list, then a dialog, then a text field) say which bindings apply now? A virtual method on `App` that the foreground App answers each time it is asked. - **What stays on screen?** Remove every hint line, or keep the ones that are state rather than help (`REC 12 points`, `LOG 42`, `sort:signal`)? A first-run hint that the help key exists? - **Memory and flash:** the strings exist already in the draw code; as tables they should cost nothing more in RAM (`concern/memory` only if they don't). - **Order of work:** the shell and the overlay first, then one App at a time, removing its hints as its bindings are declared, so no screen is ever without either. **Done when (to be refined):** the help key works on every screen including dialogs and text fields, no screen draws a key hint of its own, and the freed line is used or left empty on purpose.

twisla added this to the U1 Look and feel milestone 2026-10-06 20:16:37 +00:00

twisla added the

labels 2026-10-06 20:16:37 +00:00

Sign in to join this conversation.