Chris Muller-3 wrote
> 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@

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

Yeah, #mouseOverForKeyboardFocus is tricky since we cannot control the mouse
coordinates programmatically. For keyboard-driven navigation, such a
preference might not be well suited.

Best,
Marcel



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