[Pharo-project] Keyboard navigation and Settings browser
A few observations inspired by using the Settings browser: * Is there a way to exclude a submorph from tabbing? In the settings browser, if you keep tabbing, you eventually focus on the statusView, which is a text editor, and you start inserting tabs into the text instead of continuing to navigate * a disabled text editor should pass keyboard focus on tab instead of doing nothing (the current behavior) * how do you say which is the default widget? just set the keyboard focus manually? This would be hard using the Polymorph workflow as in the examples/Pharocasts/etc. because: - you'd have to store a reference to the morph instance, so you can set the focus after the window has been opened (will not work otherwise). - tools like the Settings browser build the UI in an instance method, so now a morph would have to be stored in the model - yuck Dialog window has #defaultFocusMorph. Maybe this should be added to SystemWindow? * EditableDropListMorphs should pass keyboard focus to their contentMorph. Right now it takes two tabs to activate. The first one just highlights the EditableDropListMorph, but does not let you type into it What do you think? Sean p.s. this exploration started because I thought it'd be more useful if the Settings browser opened with the search field active -- View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p425... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Le 03/01/2012 21:00, Sean P. DeNigris a écrit :
A few observations inspired by using the Settings browser:
* Is there a way to exclude a submorph from tabbing? In the settings browser, if you keep tabbing, you eventually focus on the statusView, which is a text editor, and you start inserting tabs into the text instead of continuing to navigate in 1.4, the keyboard focus is token by the tree, so that you can directly navigate with the keyboard inside the tree. This is explicitely programmed by sending #takeKeyboardFocus to the tree morph but after the window is opened. (see SettingBrowser>>open) It can be easily changed to make the search field take the focus on open if it is the desired behavior. but I don't know if there is a way to declare the focus owner before opening the window.
* a disabled text editor should pass keyboard focus on tab instead of doing nothing (the current behavior)
yes it should
* how do you say which is the default widget? just set the keyboard focus manually? This would be hard using the Polymorph workflow as in the examples/Pharocasts/etc. because: - you'd have to store a reference to the morph instance, so you can set the focus after the window has been opened (will not work otherwise). - tools like the Settings browser build the UI in an instance method, so now a morph would have to be stored in the model - yuck Dialog window has #defaultFocusMorph. Maybe this should be added to SystemWindow?
I agree
* EditableDropListMorphs should pass keyboard focus to their contentMorph. Right now it takes two tabs to activate. The first one just highlights the EditableDropListMorph, but does not let you type into it
yes Cheers Alain
What do you think?
Sean
p.s. this exploration started because I thought it'd be more useful if the Settings browser opened with the search field active
-- View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p425... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
As long as you have a reference to the window at the time... aWindow rememberKeyboardFocus: aMorph Then, upon opening the window, aMorph should have keyboard focus. Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec@yahoo.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, January 03, 2012 9:23 PM Subject: Re: [Pharo-project] Keyboard navigation and Settings browser
Le 03/01/2012 21:00, Sean P. DeNigris a écrit :
A few observations inspired by using the Settings browser:
* Is there a way to exclude a submorph from tabbing? In the settings browser, if you keep tabbing, you eventually focus on the statusView, which is a text editor, and you start inserting tabs into the text instead of continuing to navigate in 1.4, the keyboard focus is token by the tree, so that you can directly navigate with the keyboard inside the tree. This is explicitely programmed by sending #takeKeyboardFocus to the tree morph but after the window is opened. (see SettingBrowser>>open) It can be easily changed to make the search field take the focus on open if it is the desired behavior. but I don't know if there is a way to declare the focus owner before opening the window.
* a disabled text editor should pass keyboard focus on tab instead of doing nothing (the current behavior)
yes it should
* how do you say which is the default widget? just set the keyboard focus manually? This would be hard using the Polymorph workflow as in the examples/Pharocasts/etc. because: - you'd have to store a reference to the morph instance, so you can set the focus after the window has been opened (will not work otherwise). - tools like the Settings browser build the UI in an instance method, so now a morph would have to be stored in the model - yuck Dialog window has #defaultFocusMorph. Maybe this should be added to SystemWindow?
I agree
* EditableDropListMorphs should pass keyboard focus to their contentMorph. Right now it takes two tabs to activate. The first one just highlights the EditableDropListMorph, but does not let you type into it
yes
Cheers Alain
What do you think?
Sean
p.s. this exploration started because I thought it'd be more useful if the Settings browser opened with the search field active
-- View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p425... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (3)
-
Alain Plantec -
Gary Chambers -
Sean P. DeNigris