Menu
▾
▴
tktable-tile-dev
|
From: Bryan O. <oa...@ba...> - 2006-05-23 02:44:33
|
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 }
Is this an intentional deviation from the standard widget behavior? The
normal tk widgets don't get focus when you click on them.
|
|
From: Jeff H. <je...@ac...> - 2006-05-24 00:23:40
|
Bryan Oakley 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 }
>
> Is this an intentional deviation from the standard widget behavior? The
> normal tk widgets don't get focus when you click on them.
But normal Windows widgets do (and likely true for other native widget sets).
Themed widgets should first follow platform style, and only 2nd (in lieu of
clear platform style) follow traditional Tk style.
Jeff
|
|
From: Bryan O. <oa...@ba...> - 2006-05-24 01:04:38
|
Jeff Hobbs wrote:
> Bryan Oakley 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 }
>>
>>Is this an intentional deviation from the standard widget behavior? The
>>normal tk widgets don't get focus when you click on them.
>
>
> But normal Windows widgets do (and likely true for other native widget sets).
> Themed widgets should first follow platform style, and only 2nd (in lieu of
> clear platform style) follow traditional Tk style.
I guess I'll take your word for it. Wordpad on my machine, for example,
doesn't set the focus to a button. I click on the clipboard button on
the toolbar and the focus is still in the main part of the UI.
On the Mac, run textedit and click on an alignment button on the toolbar
and the focus stays in the main part of the UI. Likewise with mail.app,
type in a name and click on the "Save as Draft" button on the toolbar
and focus seems to stay where it was.
<shrug>
One mans bug is another mans feature. Its easy enough to work around.
|
|
From: Jeff H. <je...@ac...> - 2006-05-24 03:41:19
|
Bryan Oakley wrote:
> Jeff Hobbs wrote:
>> Bryan Oakley 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 }
>>>
>>> Is this an intentional deviation from the standard widget behavior?
>>> The normal tk widgets don't get focus when you click on them.
>>
>>
>> But normal Windows widgets do (and likely true for other native widget
>> sets).
>> Themed widgets should first follow platform style, and only 2nd (in
>> lieu of
>> clear platform style) follow traditional Tk style.
>
> I guess I'll take your word for it. Wordpad on my machine, for example,
> doesn't set the focus to a button. I click on the clipboard button on
> the toolbar and the focus is still in the main part of the UI.
>
> On the Mac, run textedit and click on an alignment button on the toolbar
> and the focus stays in the main part of the UI. Likewise with mail.app,
> type in a name and click on the "Save as Draft" button on the toolbar
> and focus seems to stay where it was.
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?).
Jeff
|
|
From: Brian G. <bgr...@mo...> - 2006-05-24 04:06:48
|
Jeff Hobbs wrote:
> Bryan Oakley wrote:
>> Jeff Hobbs wrote:
>>> Bryan Oakley 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 }
>>>>
>>>> Is this an intentional deviation from the standard widget behavior?
>>>> The normal tk widgets don't get focus when you click on them.
>>>
>>>
>>> But normal Windows widgets do (and likely true for other native
>>> widget sets).
>>> Themed widgets should first follow platform style, and only 2nd (in
>>> lieu of
>>> clear platform style) follow traditional Tk style.
>>
>> I guess I'll take your word for it. Wordpad on my machine, for
>> example, doesn't set the focus to a button. I click on the clipboard
>> button on the toolbar and the focus is still in the main part of the UI.
>>
>> On the Mac, run textedit and click on an alignment button on the
>> toolbar and the focus stays in the main part of the UI. Likewise with
>> mail.app, type in a name and click on the "Save as Draft" button on
>> the toolbar and focus seems to stay where it was.
>
> 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?
-Brian
|
|
From: Jeff H. <je...@ac...> - 2006-05-24 04:15:10
|
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.
Jeff
|
|
From: Brian G. <bgr...@mo...> - 2006-05-24 05:08:49
|
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
|
|
From: Bryan O. <oa...@ba...> - 2006-05-24 11:56:10
|
Brian Griffin wrote:
> Jeff Hobbs wrote:
>>
>> 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.
I'll agree with Jeff. No, Brian. No, Jeff!
I think there's no universal truth for when clicking on a button moves
focus there, though I think way more often than not we do _not_ want
focus to go to a button when it is clicked.
Dialogs are a likely exception, though I'm not sure I can think of any
other exceptions.
The other point is, it's much easier for a programmer to add
click-to-focus than it is to remove it. To add it I just do "bind
.whatever <1> {focus %W}". If focus is set automatically by the class
bindings I either have to replace the class bindings (something I'm
generally loathe to do), or do something gross like "bind .whatever
<ButtonPress-1> {rememberFocus}; bind .whatever <ButtonRelease-1>
{restoreFocus}"
I vote for removing the default click-to-focus of buttons and letting
the programmer easily choose when they want a button to have focus.
|
|
From: Donal K. F. <don...@ma...> - 2006-05-24 08:37:50
|
Brian Griffin wrote: > 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. Having read the discussion so far, it sounds to me like whether a button (or related widget) takes focus on being clicked is really a feature of the style. Dialog box buttons probably should because it makes keyboard navigation much easier, toolbar buttons probably shouldn't since they'd steal the focus from the main widget of the window and there ought to be at least two alternate mechanisms for invoking them anyway (menus and keyboard shortcuts). Donal. |
|
From: Joe E. <jen...@fl...> - 2006-05-24 12:41:38
|
[ Just catching up with the discussion ... ]
Bryan Oakley 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 }
>
> Is this an intentional deviation from the standard widget behavior? The
> normal tk widgets don't get focus when you click on them.
Yes, that's intentional; and thanks for bringing this up --
I checked the other major toolkits to see which ones use click-to-focus:
Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click for
radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do not.
Tile buttons set focus-on-click by default, though this can be
disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
and tile::wantsFocus in library/utils.tcl).
--Joe English
jen...@fl...
|
|
From: Bryan O. <oa...@ba...> - 2006-05-24 13:49:43
|
Joe English wrote:
> [ Just catching up with the discussion ... ]
>
> Bryan Oakley 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 }
>>
>>Is this an intentional deviation from the standard widget behavior? The
>>normal tk widgets don't get focus when you click on them.
>
>
> Yes, that's intentional; and thanks for bringing this up --
>
> I checked the other major toolkits to see which ones use click-to-focus:
> Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click for
> radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do not.
>
> Tile buttons set focus-on-click by default, though this can be
> disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
> and tile::wantsFocus in library/utils.tcl).
Setting -takefocus to zero is definitely not the right solution. We
don't want to completely remove the ability to traverse the widgets with
the keyboard, which is what -takefocus 0 does. I just don't want a click
on a radiobutton, checkbutton or tool button on my toolbar to steal
focus away from the main data entry area of my application.
As it stands today, the only way to get the behavior I want is to
completely override the class bindings. This is not a particularly good
solution either.
What we need is a separate option that specifies whether a click will
give focus. Yet, we already have a mechanism to do that -- bind
.whatever <1> {focus %W}.
|
|
From: Brian G. <bgr...@mo...> - 2006-05-24 15:40:32
|
Bryan Oakley wrote:
> Joe English wrote:
>> [ Just catching up with the discussion ... ]
>>
>> Bryan Oakley 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 }
>>>
>>> Is this an intentional deviation from the standard widget behavior?
>>> The normal tk widgets don't get focus when you click on them.
>>
>>
>> Yes, that's intentional; and thanks for bringing this up --
>>
>> I checked the other major toolkits to see which ones use click-to-focus:
>> Gtk, Windows, Motif, Mozilla, and OpenOffice all set focus-on-click
>> for radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac do
>> not.
>> Tile buttons set focus-on-click by default, though this can be
>> disabled by setting '-takefocus 0' on the widget (see tile::clickToFocus
>> and tile::wantsFocus in library/utils.tcl).
>
> Setting -takefocus to zero is definitely not the right solution. We
> don't want to completely remove the ability to traverse the widgets
> with the keyboard, which is what -takefocus 0 does. I just don't want
> a click on a radiobutton, checkbutton or tool button on my toolbar to
> steal focus away from the main data entry area of my application.
Huh? You don't want keyboard traversal for a radio button in a toolbar
on the main window, and that's what -takefocus 0 gives you. So what's
the problem?
-Brian
|
|
From: Bryan O. <oa...@ba...> - 2006-05-24 15:55:23
|
Brian Griffin wrote: > Huh? You don't want keyboard traversal for a radio button in a toolbar > on the main window, and that's what -takefocus 0 gives you. So what's > the problem? I *do* want keyboard traversal on a toolbar. I just don't want a click to set the focus to the toolbar. Thus, I can't use "-takefocus 0" because that removes the ability to use keyboard traversal. |
|
From: Brian G. <bgr...@mo...> - 2006-05-24 16:02:27
|
Bryan Oakley wrote: > Brian Griffin wrote: >> Huh? You don't want keyboard traversal for a radio button in a >> toolbar on the main window, and that's what -takefocus 0 gives you. >> So what's the problem? > > I *do* want keyboard traversal on a toolbar. I just don't want a click > to set the focus to the toolbar. Thus, I can't use "-takefocus 0" > because that removes the ability to use keyboard traversal. But why? That, to me, is non-standard. -Brian |
|
From: Brian G. <bgr...@mo...> - 2006-05-24 16:04:34
|
Brian Griffin wrote: > Bryan Oakley wrote: >> Brian Griffin wrote: >>> Huh? You don't want keyboard traversal for a radio button in a >>> toolbar on the main window, and that's what -takefocus 0 gives you. >>> So what's the problem? >> >> I *do* want keyboard traversal on a toolbar. I just don't want a >> click to set the focus to the toolbar. Thus, I can't use "-takefocus >> 0" because that removes the ability to use keyboard traversal. > > But why? That, to me, is non-standard. To me, there's no difference between <Key-Tab> and <Button-1> as far as setting focus. -Brian |
|
From: Bryan O. <oa...@ba...> - 2006-05-24 16:37:10
|
Brian Griffin wrote: > Brian Griffin wrote: > >> Bryan Oakley wrote: >> >>> Brian Griffin wrote: >>> >>>> Huh? You don't want keyboard traversal for a radio button in a >>>> toolbar on the main window, and that's what -takefocus 0 gives you. >>>> So what's the problem? >>> >>> >>> I *do* want keyboard traversal on a toolbar. I just don't want a >>> click to set the focus to the toolbar. Thus, I can't use "-takefocus >>> 0" because that removes the ability to use keyboard traversal. >> >> >> But why? That, to me, is non-standard. > > > To me, there's no difference between <Key-Tab> and <Button-1> as far as > setting focus. Ha! That's a great question. I hate it when people make me think, especially during the work day! I guess my only response is "because I've always done it that way". I've (almost) always tried to make my apps such that it's possible to traverse to and through the toolbar. Come to think of it, that's not strictly necessary since toolbar buttons should correspond to menu items, and menu items are keyboard-traversable. You raise a good point. <surfin'...> Hmmm. I think this quote from MSDN validates click-to-focus for buttons (not that I put a whole lot of stock in documented Microsoft policies since they violate them at will...): "Display the input focus when the mouse button is pressed and the cursor is over a control" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14c.asp) Interesting. I guess I stand corrected. Maybe click-to-focus on by default, and "-takefocus 0" for toolbar controls is the Right Thing To Do. |
|
From: Jeff H. <je...@ac...> - 2006-05-24 16:31:43
|
Joe English wrote:
> Bryan Oakley 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 }
> >
> > Is this an intentional deviation from the standard widget behavior?
> > The
> > normal tk widgets don't get focus when you click on them.
>
> Yes, that's intentional; and thanks for bringing this up --
>
> I checked the other major toolkits to see which ones use
> click-to-focus: Gtk, Windows, Motif, Mozilla, and OpenOffice
> all set focus-on-click for
> radio-, check-, and push-buttons; whereas Tk, Qt, and the Mac
> do not.
The Windows one is a little different, in that you don't see the focus ring
until you actually attempt to use keyboard traversal, although it does appear
to set focus to that widget.
> Tile buttons set focus-on-click by default, though this can
> be disabled by setting '-takefocus 0' on the widget (see
> tile::clickToFocus and tile::wantsFocus in library/utils.tcl).
Shouldn't this be controllable without removing takefocus on the widget
totally?
Jeff
|
