Hi, there.

If you enable the following preferences.

[x] mouseOverForKeyboardFocus
[x] Windows' Contents Are Always Active

You might be suprised that, for example, CMD+I opens an inspector but the
keyboard focus is still in the current tool, maybe a workspace. Even if you
disable "mouseOverForKeyboardFocus", the workspace will keep its keyboard
focus. If you also disable "Window's Contents Are Always Active", at least
the new window looks focused, although no widget insided grabbed the focus.
Actually, no widget will have the keyboard focus then.

So, I added focus grabbing for lists and text morphs. I used it for our list
chooser:
http://forum.world.st/The-Trunk-Morphic-mt-1157-mcz-tp4898664.html
http://forum.world.st/The-Trunk-ToolBuilder-Morphic-mt-165-mcz-tp4898662.html

It is quite simple. Models can say "self changed: #inputRequested with:
#someSelector" and the correct widget will grab the keyboard. Easy for the
list chooser because you want to type in a filter and hit return to choose.
(Try it out in the code browser category list via CMD+F to find a class.)

But what about other tools?

System Browser
Inspector
Object Explorer
...

Any idea which widgets should grab the keyboard focus if opened? The first
list? The code widget? We can make different choices for each tool.

Suggestions are welcome. This discussion affects general keyboard
interaction in Squeak.

Passionate mouse users will not notice any problem, though. ;o)

Best,
Marcel



--
View this message in context: http://forum.world.st/How-when-should-tools-grab-the-keyboard-tp4898814.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.