Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Option to Show Default Key Bindings in the Footer #5818

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DaXor-0 opened this issue May 28, 2025 · 5 comments
Closed

Option to Show Default Key Bindings in the Footer #5818

DaXor-0 opened this issue May 28, 2025 · 5 comments

Comments

@DaXor-0
Copy link

DaXor-0 commented May 28, 2025

Feature Request: Include Default Key Bindings in the Footer

Currently, the Footer widget only displays key bindings that are explicitly declared in App.BINDINGS or bound manually via self.bind(). However, many keys such as Tab, 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.:

    Footer(show_default_bindings=True)
  • Or an App-level flag:

    class MyApp(App):
        SHOW_DEFAULT_BINDINGS = True
  • 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

  • Improved discoverability of built-in interactions.
  • Cleaner developer experience.
  • Consistency across apps that use common Textual idioms.
Copy link

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

@willmcgugan
Copy link
Collaborator

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.

@DaXor-0
Copy link
Author

DaXor-0 commented May 28, 2025

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.

@willmcgugan
Copy link
Collaborator

If that’s what you want, then you can go ahead and copy the bindings you wish to see, but set show=True.

Copy link

Don't forget to star the repository!

Follow @textualizeio for Textual updates.

@Textualize Textualize locked and limited conversation to collaborators May 31, 2025
@willmcgugan willmcgugan converted this issue into discussion #5824 May 31, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants