Re: [Tile-dev] setting focus on button clicks: on purpose?

[Brian G. <bgr...@mo...>]

Jeff Hobbs wrote:
> Brian Griffin wrote:
>> Jeff Hobbs wrote:
>>>>>> I noticed that with tile 0.7.2, if I click on a button the focus 
>>>>>> is set to that button. Investigating I see it is due to this:
>>>>>>
>>>>>> % bind TRadiobutton <1>
>>>>>>  %W instate !disabled { tile::clickToFocus %W; %W state pressed }
>
>>> Don't take my word for it, because you are right.  I usually go to 
>>> the Display Properties on XP for reference.  Lacking radiobuttons 
>>> there, I went to Firefox - which is itself using an emulated native 
>>> widget set. Firefox does set focus on radio click, but you are right 
>>> that native XP widgets don't seem to by default.  I can't find this 
>>> behavior on OS X either, even when fiddling with various 
>>> focus/keypad handling preferences.
>>>
>>> I would argue that this feature should be controlled by some master 
>>> switch, off by default (or perhaps only on on unix?).
>
>> I think it's more complicated then that.  In a dialog box, you want 
>> focus to go to buttons so that keyboard traversal is possible 
>> (consider mouse-less operations).  When it comes to toolbars; these 
>> are just a short hand way to access menus, and because of the 
>> plethora of buttons there, including them in keyboard traversal would 
>> just add too much to the window.  Because of the organization of the 
>> menus, it's easier to invoke stuff from them when using the 
>> keyboard.  Things like scrollbars (should) have independent keyboard 
>> controls, so there's no need for them to ever take focus.
>>
>> So the question to ask is: can I control the take-focus of a button 
>> when I need to, based on where and how the button is used?
>
> I think you are arguing a slightly orthogonal point.  Bryan noted that 
> the buttons receive focus when you click on them - not that they can 
> possibly receive focus at all (like via the Tab key).  I'm not 
> advocating removing the ability to receive focus, just that clicking 
> on them doesn't automatically add focus (thus negating the current 
> "clickToFocus" behavior).  This should not alter keyboard traversal 
> behavior.

I'm not so sure they are completely orthogonal.  When using a mix of 
mouse and keyboard, it seems reasonable that the last mouse click sets 
the starting point of the next key stroke, whether it's an invoke or 
Tab-Next key, especially in dialog boxes.

-Brian