ModalScreen behavior on an arbitrary widget

[drootang]

I'd like to have a Dialog that prompts the user for Cancel/Confirm. It's important that other hotkeys be disabled while this Dialog is presented.

I'm aware of ModalScreen and it generally satisfies that requirement, but it has two downsides:

1. Must be driven from App which means lots of messaging overhead to keep track of which widget initiated this request
2. Harder to make it visually associated with another Widget in the DOM (i.e., it is designed to be presented full screen)

I have a ListView and want to allow hotkeys to perform actions on individual ListItems. I am mounting a custom Dialog widget after the ListItem that contains a Cancel and Confirm button. While this is displayed, though, I don't want the up/down arrows to move the highlight up/down in the ListView, for example.

My Diaglog is focused, so I can capture up/down keybindings, but it doesn't feel reusable enough for me to explicitly mask a list of keybindings I know exist. I really want to capture/eat/disable all other non-priority bindings that are not used for my Dialog. I feel like I'm missing something, but don't see a good way to do this.

Can anyone point me in the right direction?

[davep]

Do you think you could provide an MRE of the problems you're talking about here? I ask because I don't really recognise any of them as issues I run into when using ModalScreen on top of another screen. For example, here's an MRE I've just mode that shows that nothing in the child screen needs to be driven by the app, no messaging overhead is involved at all, the modal screen isn't full screen and you can see the context behind, and keystrokes in the child aren't affecting the parent in any way:

from textual import on
from textual.app import App, ComposeResult
from textual.containers import Vertical
from textual.screen import ModalScreen
from textual.widgets import ListView, ListItem, Label, Button

class ModalDialog(ModalScreen[None]):

    CSS = """
    ModalDialog {
        align: center middle;
        Vertical {
            border: panel cornflowerblue;
            width: 70%;
            height: 70%;
            Button {
                width: 1fr;
            }
        }
    }
    """

    def compose(self) -> ComposeResult:
        with Vertical():
            yield ListView(*[ListItem(Label(f"This is list item in a modal screen {n}")) for n in range(100)])
            yield Button("Close")

    @on(Button.Pressed)
    def close(self) -> None:
        self.dismiss()

class ModalScreenFocusApp(App[None]):

    def compose(self) -> ComposeResult:
        yield ListView(*[ListItem(Label(f"This is list item {n}")) for n in range(100)])

    @on(ListView.Selected)
    def show_modal(self) -> None:
        self.push_screen(ModalDialog())

if __name__ == "__main__":
    ModalScreenFocusApp().run()

If you could show a similar-sized example of the problems you're seeing, it might make it easier for people to help.

[drootang]

Thanks for your response @davep
I understand the example you shared, but its not quite what I'm looking for.

The main thing I'd like to do is visually attach my new "modal" (i'm not actually using a ModalScreen) to an existing UI item so its clear to the user that that's what the modal is operating on. Here is an (ugly) example:

from textual import on
from textual.app import App, ComposeResult
from textual.widgets import ListView, ListItem, Label, Static, Button

class ListItemPrompt(Static):
    BINDINGS = [
        ('x', 'cancel', 'Cancel'),
        ('c', 'confirm', 'Confirm'),
    ]

    def on_mount(self):
        self.query('Button').first().focus()

    def compose(self):
        yield Button('Cancel')
        yield Button('Confirm')

    def action_cancel(self):
        self.remove()

    def action_confirm(self):
        self.remove()


class PromptApp(App[None]):

    def compose(self) -> ComposeResult:
        yield ListView(*[ListItem(Label(f"This is list item {n}")) for n in range(100)])

    def on_list_view_selected(self, message) -> None:
        message.item.mount(ListItemPrompt())

if __name__ == "__main__":
    PromptApp().run()

The issue with this example is that while the ListItemPrompt is displayed, the user can still us the up/down keys to navigate the ListView. I could add BINDINGS to capture up/down and trigger some null action, but what if this is all nested in other Widgets or there are other hotkeys?

This example is still incomplete because there is no way currently to act on the cancel or confirm button press. I would handle this by generating a custom Message subclass that bubbles the result of the ListItemPrompt. I found that if the ListItemPrompt calls remove() on itself to dismiss after posting such a message, the message never makes it. So the message handler has to handle removing the ListItemPrompt, which means I need to track a DOM element containing the ListItemPrompt. That's not the end of the world (although feels cumbersome, maybe I'm missing something).

[davep]

I think I'm failing to understand your use of "modal" here, as it seems counter to its common use when talking about UI design; that is: I'd expect a "modal" of some form to be something that takes over all focus from the current "screen". As I'm looking at your clarification, it looks me like the question is "how can I have a focusable widget inside a ListView and have it not follow the normal rules of input-handling".

The thing is: ListView is designed so that the content doesn't get focus. I'm not sure what the wider use for this is; but I don't think it's ListView you want to be using for it.

[drootang]

Yes, my use of the world modal may be a bit loose here. I used it to mean that it is the only widget that will respond to any user input. This isn't really a ListView-specific question. It could have been any widget that I attached the ListItemPrompt to.

I don't think I'd agree that this is not following normal rules of input-handling. There is clear precedent for cases where some widget is presented and does not bubble input events (ModalScreen, for example, although this may be the only one). That is a philosophical debate. If the design/programming guidelines say don't do what I'm trying to do, that's fine, of course. My next question is, how do I do it anyway?

You got me thinking, though. If the premise is that the rules of input handling require that my widget must allow other hotkeys to affect other DOM elements, then the correct behavior is probably to simply dismiss the ListItemPrompt if a user does something that moves focus away from the ListItem the prompt is operating on. So if they use up/down to scroll to another item, that is akin to canceling the prompt. This makes sense to me as a general behavior to any sort of confirmation dialog that is presented associated with an existing widget.

Thanks for the discussion

[davep]

There is clear precedent for cases where some widget is presented and does not bubble input events (ModalScreen, for example, although this may be the only one).

Just for clarity: it wouldn't really make sense to view a Screen (and so a ModalScreen) as a widget here; and technically the input events will still "bubble"; but the chain is always widget->...->screen->app (where "..." is the zero or more widgets that are containers for the widget with focus).