Keyboard navigation and Settings browser

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Keyboard navigation and Settings browser

Sean P. DeNigris
Administrator
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Keyboard navigation and Settings browser

Alain Plantec-3
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Keyboard navigation and Settings browser

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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.
>>
>
>