Add default Esc binding to unfocus Input?

[TomJGooding]

Any time I've wanted an Input widget in my Textual app, I've had to subclass it to add an Esc binding to allow unfocusing it from the keyboard.

This feels like it should be the default behaviour to me, but maybe I'm overlooking something - so posting here to see if anyone else would find this useful?

[davep]

What would unfocus mean on a screen of five inputs, a couple of checkboxes, a radio set or two plus a collection of buttons? What would be special about Input here, and what would unfocus mean exactly?

[TomJGooding]

I like my Textual apps to be keyboard-first and normally have some 'shortcut' bindings to quickly focus parts of the app (quick example below). I suppose what's special about the Input is that obviously while focused, it captures all the keys!

But fair point about what exactly it would mean to 'unfocus'...

from textual.app import App, ComposeResult
from textual.containers import Center
from textual.widgets import Button, Checkbox, Footer, Input, RadioButton


class ExampleApp(App):
    BINDINGS = [
        ("i", "focus_input", "Input"),
        ("c", "focus_checkbox", "Checkbox"),
        ("r", "focus_radio", "Radio"),
        ("b", "focus_button", "Button"),
    ]
    CSS = """
    Screen {
        align: center middle;
    }

    Input {
        width: 30;
    }

    Checkbox {
        height: 3;
        content-align: center middle;
    }

    RadioButton {
        height: 3;
        content-align: center middle;
    }
    """

    def compose(self) -> ComposeResult:
        yield Center(Input(placeholder="Enter some text..."))
        yield Center(Checkbox("Check me!"))
        yield Center(RadioButton("Choose me!"))
        yield Center(Button("Press me!"))
        yield Footer()

    def action_focus_input(self) -> None:
        self.query_one(Input).focus()

    def action_focus_checkbox(self) -> None:
        self.query_one(Checkbox).focus()

    def action_focus_radio(self) -> None:
        self.query_one(RadioButton).focus()

    def action_focus_button(self) -> None:
        self.query_one(Button).focus()

[TomJGooding]

I appreciate you can quickly 'escape' the Input using Tab, but Esc just feels natural. Maybe I'm thinking about this too much like the vim experience!

Like I say, just floating the idea for discussion and obviously I need to think more about what 'unfocus' would mean exactly.

[davep]

Maybe I'm thinking about this too much like the vim experience!

It does feel to me like, perhaps, for your apps, it does make sense to have your own Input subclass that works "just so".

[rodrigogiraoserrao]

Just to throw some more gas in the fire, I also consistently press Esc to unfocus my Input widgets 😆
Not sure where I got that tic from, though.

[willmcgugan]

Strangely it doesn't seem to be the default on HTML Inputs. If you hit escape, nothing happens. But many other less atomic widgets will respond to escape.

[liancheng]

@TomJGooding, I'm following a similar philosophy. +1 for having ESC for unfocusing.

BTW, the App class has a built-in action_focus accepting a widget ID, which helps simplify your case. However, setting the focus to nested widgets can be quite tricky. I have a separate question posted here, I think you might be interested.

To build keyboard-first apps, I think we at least lack a couple of things:

1. Proper focus handling for nested widgets as mentioned in the above post.

2. Allow unbinding keys (see discussion thread here).

   A complicated app often has multiple screens, and different screens may need different key bindings. Currently, Textual supports scoped key bindings, which allows you to define a set of bindings within a widget, and activate these key bindings when the widget has the focus. However, it is not enough. Imagine that you have a tabbed app consisting of a TabbedContent and two TabPanes. Each TabPane may have its own set of key bindings, but they won't be activated until the TabPane has the focus. Ideally, key bindings associated with a TabPane should be activated as long as the TabPane is active, even though the focus is somewhere else (e.g., on the TabbedContent widget). To achieve this, you need to bind and unbind keys dynamically.