You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Windows hotkey mechanism allows you to move the focus by pressing ALT and a key marked with an underscore on the label of/associated with a widget. I'm trying to simulate something similar in my app. E.g., by pressing p, the Input widget gets the focus:
Implementing this using the bindings API and App.action_focus() is pretty straightforward until I tried to apply this trick to compound widgets. Consider the following oversimplified example:
The problem here is that, when setting the focus, if the target widget is not focusable but has focusable child widgets, the result is a no-op. Textual does not try to traverse the DOM tree and find the first focusable child widget.
I worked around this issue by defining a customized set_focus action (it does not recurively traverse the DOM tree, though):
a. Should we traverse the DOM tree of the widget to find the first focusable child widget (including itself)?
b. When no such widget is found, should we just ignore it (today's behavior) or throw an exception?
What exactly do Widget.can_focus and Widget.can_focus_children mean? How are they related to App.focusable?
Did some experiments, considering the following layout:
The ChildWidget is skipped when the user keeps pressing Tab. But the ChildWidget can still be focusable and receive the focus if the user clicks it or through App.set_focus().
Are can_focus and can_focus_children only related to moving the focus using Tab (plus Screen.focus_next and Screen.focus_previous)?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The Windows hotkey mechanism allows you to move the focus by pressing
ALT
and a key marked with an underscore on the label of/associated with a widget. I'm trying to simulate something similar in my app. E.g., by pressingp
, theInput
widget gets the focus:Implementing this using the bindings API and
App.action_focus()
is pretty straightforward until I tried to apply this trick to compound widgets. Consider the following oversimplified example:Note, by default:
The problem here is that, when setting the focus, if the target widget is not focusable but has focusable child widgets, the result is a no-op. Textual does not try to traverse the DOM tree and find the first focusable child widget.
I worked around this issue by defining a customized
set_focus
action (it does not recurively traverse the DOM tree, though):But I wonder:
When setting the focus to a widget
a. Should we traverse the DOM tree of the widget to find the first focusable child widget (including itself)?
b. When no such widget is found, should we just ignore it (today's behavior) or throw an exception?
What exactly do
Widget.can_focus
andWidget.can_focus_children
mean? How are they related toApp.focusable
?Did some experiments, considering the following layout:
The
ChildWidget
is skipped when the user keeps pressingTab
. But theChildWidget
can still befocusable
and receive the focus if the user clicks it or throughApp.set_focus()
.Are
can_focus
andcan_focus_children
only related to moving the focus usingTab
(plusScreen.focus_next
andScreen.focus_previous
)?Beta Was this translation helpful? Give feedback.
All reactions