Replies: 5 comments
-
We found the following entry in the FAQ which you may find helpful: Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review. This is an automated reply, generated by FAQtory |
Beta Was this translation helpful? Give feedback.
-
There are a lot of default bindings. If the footer showed them all, there wouldn't be much or any room left for custom bindings. If you select "Show keys and help panel" via the command palette, it will show you all the keys in a more readable format. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the quick response! Totally understand that showing all default bindings in the footer by default would clutter it — that's definitely not what I'm asking for. What I’d love is the option to selectively include default bindings in the footer (without manually rewriting them). For example, being able to opt-in specific default bindings like "tab" or "shift+tab" with just a label — similar to how custom bindings are defined — but without needing to override or rebind their existing behavior. |
Beta Was this translation helpful? Give feedback.
-
If that’s what you want, then you can go ahead and copy the bindings you wish to see, but set show=True. |
Beta Was this translation helpful? Give feedback.
-
Don't forget to star the repository! Follow @textualizeio for Textual updates. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Feature Request: Include Default Key Bindings in the Footer
Currently, the
Footer
widget only displays key bindings that are explicitly declared inApp.BINDINGS
or bound manually viaself.bind()
. However, many keys such asTab
,Shift+Tab
, arrow keys, etc., have default functionality (e.g., focus movement) that users may not be aware of unless documented separately.Proposal
Introduce a configurable option or parameter to
Footer
(or a global app setting) that allows the display of default/built-in key bindings alongside user-defined bindings.Possible Implementations:
A keyword argument in
Footer
, e.g.:Or an App-level flag:
Default bindings could be labeled with a tag like
[default]
, shown in a different color, or styled subtly to distinguish them from app-specific bindings.Use Case
When building user-facing TUIs, developers want to reduce onboarding friction. Showing helpful default keys like
Tab
for navigation directly in the footer would improve usability without requiring explicit redefinition.Benefits
Beta Was this translation helpful? Give feedback.
All reactions