[Pharo-project] Keyboard navigation and Settings browser
gazzaguru2 at btinternet.com
Wed Jan 4 05:31:13 EST 2012
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.
----- Original Message -----
From: "Alain Plantec" <alain.plantec at yahoo.com>
To: <Pharo-project at 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,
>> 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
>> 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
>> 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
> I agree
>> * EditableDropListMorphs should pass keyboard focus to their
>> Right now it takes two tabs to activate. The first one just highlights
>> EditableDropListMorph, but does not let you type into it
>> What do you think?
>> p.s. this exploration started because I thought it'd be more useful if
>> Settings browser opened with the search field active
>> View this message in context:
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
More information about the Pharo-dev