Hi Marcel, I like this idea about a application-driven keyboard focus,
and it would be great to add some hot-key to cycle the keyboard focus
around the widgets, as Windows and other OS's do.  Hmm, there's
somewhat of a semantic tangle -- because mouseOverForKeyboardFocus
means the focus is always under the mouse pointer...  I know for
pop-up dialogs, it works by opening it directly under where the mouse
pointer is.  I suppose the ListChooser could do the same, but what
about other windows?  I mean, isn't the reason one spawns an Inspector
or Browser window usually to interact with it?  It would seem so!

So, what widget?  I think top-left is a good default.

But if there is no ability to switch focus with the keyboard, then it
may not be worth it at all because one would have to use the mouse to
set the focus 90% of the time..

But which keys?  Tab and back-Tab are obvious candidates except, we
need Tab in code editors and back-Tab doesn't work in Linux.....

On Thu, Jun 2, 2016 at 8:55 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> 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.
>