search

beeware / toga

A Python native, OS native GUI toolkit.
https://toga.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
4.37k stars 674 forks source link

could toga.Table.focus() have it's no-op override removed? #2972

Open samtupy opened 1 day ago

samtupy commented 1 day ago

What is the problem or limitation you are having?

Currently, the toga.Table.focus() function is a no-op even though it should be implemented on many of the platforms the widget is available on. This means that if I have an app with the primary control being a large table of data, I cannot focus that table programmatically on app startup so users can instantly navigate it with the keyboard. Instead the users must first tab to the table, which is undesirable. An example of such an undesirability is talked about in pr #2956.

Describe the solution you'd like

In core/src/toga/widgets/table.py, the function:

    def focus(self) -> None:
        """No-op; Table cannot accept input focus."""
        pass

exists, and I'm wondering if it's possible that this function could be removed?

Describe alternatives you've considered

Either I must access table._impl.native directly per platform or focus the user on a different default control. I haven't found any other alternatives.

Additional context

This is an app for a visually impaired audience primarily. When such an app starts, it's best for the user to be focused on one of the app's primary controls, so that such a person's screen reader gives extra context about the interface when the app launches. For example instead of the user pressing enter and the screen reader saying something like "app name." It might instead say something like "app name. voices list alt+v." Which sounds a bit nicer as at least some tiny context is provided without exploration, but more importantly the user can then begin instantly navigating the primary control with the keyboard. For now I must just focus the user on a different button or text input instead.

freakboy3742 commented 10 hours ago

It's been a while since I've looked at this; but my guess is that the "no-op" implementation was added because on at least one platform, the default focus implementation either didn't work, or didn't respond in a way that was detectable. That might be because "focus" on a Table widget could refer to the Table as a whole, or individual rows.

If it's possible to restore focus capability, then we should do so - especially if there's an accessibility implication.