[Pharo-project] Keyboard navigation and Settings browser

Gary Chambers 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.

Regards, Gary

----- 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, 
>> 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-tp4258311p4258311.html
>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

More information about the Pharo-dev mailing list