bug#1405: detached GTK+ tool bar

bug#1405: detached GTK+ tool bar

[Jan Djärv]

Chong Yidong skrev:
> Excerpted from bug#1405:
> 
>> ...
>> Perhaps this is a GTK+ bug, but I'm not aware of another GTK+ app
>> aside from Emacs that uses a detachable tool bar to test for it.
> 
> When Emacs got detachable tool bars, it was the standard for GTK
> applications to provide a detachable tool bar.  Nowadays, no other GTK
> application provides a detachable tool bar as far as I can tell.  (Maybe
> this feature was considered useless?)  So maybe we should turn this off.
> 
> Jan, what do you think?

We can always make it un-detachable by default and have some frame parameter 
to turn it on.  But since there are uses for a detachable tool bar as Stephen 
points out, I'd rather not remove it until we really need to (i.e. when Gtk+ 
removes the API for it).

But as for the focus bug described here, focus setting is in the 
responsibility of the window manager.  If for instance you have click to 
focus, the behaviour described here is expected.

I'd rather see if the focus can be kept to the frame.  We can perhaps put some 
hints to the window manager.  I'll look in to it.  Can the OP please tell us 
what window manager he is using and what kind of focus model he has (click to 
focus, focus follows mouse)?

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Chong Yidong skrev:
>> Excerpted from bug#1405:
>>
>>> ...
>>> Perhaps this is a GTK+ bug, but I'm not aware of another GTK+ app
>>> aside from Emacs that uses a detachable tool bar to test for it.
>>
>> When Emacs got detachable tool bars, it was the standard for GTK
>> applications to provide a detachable tool bar.  Nowadays, no other GTK
>> application provides a detachable tool bar as far as I can tell.  (Maybe
>> this feature was considered useless?)  So maybe we should turn this off.
>>
>> Jan, what do you think?
>
> We can always make it un-detachable by default and have some frame parameter
> to turn it on.  But since there are uses for a detachable tool bar as Stephen
> points out, I'd rather not remove it until we really need to (i.e. when Gtk+
> removes the API for it).

Does this mean you don't expect to come up with a fix for the "shrinking
frame" bug?  (Unfortunately, I don't know enough to do more than ask...)

> But as for the focus bug described here, focus setting is in the
> responsibility of the window manager.  If for instance you have click to
> focus, the behaviour described here is expected.
>
> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
> hints to the window manager.  I'll look in to it.  Can the OP please tell us
> what window manager he is using and what kind of focus model he has (click to
> focus, focus follows mouse)?

I'm using KDE/kwin and click to focus.  But I also see the same behavior
(i.e. focus not returning to the window/frame the tool bar was detached
from) with a focus follows mouse policy.

Steve Berman

bug#1405: detached GTK+ tool bar

[Jan D.]

Stephen Berman skrev:
> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Chong Yidong skrev:
>>> Excerpted from bug#1405:
>>>
>>>> ...
>>>> Perhaps this is a GTK+ bug, but I'm not aware of another GTK+ app
>>>> aside from Emacs that uses a detachable tool bar to test for it.
>>> When Emacs got detachable tool bars, it was the standard for GTK
>>> applications to provide a detachable tool bar.  Nowadays, no other GTK
>>> application provides a detachable tool bar as far as I can tell.  (Maybe
>>> this feature was considered useless?)  So maybe we should turn this off.
>>>
>>> Jan, what do you think?
>> We can always make it un-detachable by default and have some frame parameter
>> to turn it on.  But since there are uses for a detachable tool bar as Stephen
>> points out, I'd rather not remove it until we really need to (i.e. when Gtk+
>> removes the API for it).
> 
> Does this mean you don't expect to come up with a fix for the "shrinking
> frame" bug?  (Unfortunately, I don't know enough to do more than ask...)


It is first on my list of bugs to fix.  Unfortunately it is a race 
condition and I haven't found a foolproof solution yet.  I have let this 
issue rest for a while, I need to find a new approach I think.

> 
>> But as for the focus bug described here, focus setting is in the
>> responsibility of the window manager.  If for instance you have click to
>> focus, the behaviour described here is expected.
>>
>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>> what window manager he is using and what kind of focus model he has (click to
>> focus, focus follows mouse)?
> 
> I'm using KDE/kwin and click to focus.  But I also see the same behavior
> (i.e. focus not returning to the window/frame the tool bar was detached
> from) with a focus follows mouse policy.
> 

Thanks for the information.

	Jan D.

bug#1405: detached GTK+ tool bar

[Chong Yidong]

"Jan D." <jan.h.d@swipnet.se> writes:

>> Does this mean you don't expect to come up with a fix for the
>> "shrinking frame" bug?  (Unfortunately, I don't know enough to do
>> more than ask...)
>
> It is first on my list of bugs to fix.  Unfortunately it is a race
> condition and I haven't found a foolproof solution yet.  I have let
> this issue rest for a while, I need to find a new approach I think.

Is this the window size hints race condition we discussed a while back?

bug#1405: detached GTK+ tool bar

[Jan Djärv]

Chong Yidong skrev:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>>> Does this mean you don't expect to come up with a fix for the
>>> "shrinking frame" bug?  (Unfortunately, I don't know enough to do
>>> more than ask...)
>> It is first on my list of bugs to fix.  Unfortunately it is a race
>> condition and I haven't found a foolproof solution yet.  I have let
>> this issue rest for a while, I need to find a new approach I think.
> 
> Is this the window size hints race condition we discussed a while back?
> 

Yes, but a variant of it that does not only occur at startup.

	Jan D.

bug#1405: detached GTK+ tool bar

[Jan Djärv]

Stephen Berman skrev:
> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>> what window manager he is using and what kind of focus model he has (click to
>> focus, focus follows mouse)?
> 
> I'm using KDE/kwin and click to focus.  But I also see the same behavior
> (i.e. focus not returning to the window/frame the tool bar was detached
> from) with a focus follows mouse policy.
> 

I've made a change, can you test it?

Thanks,

	Jan D.

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:

> Stephen Berman skrev:
>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>
>>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>>> what window manager he is using and what kind of focus model he has (click to
>>> focus, focus follows mouse)?
>> 
>> I'm using KDE/kwin and click to focus.  But I also see the same behavior
>> (i.e. focus not returning to the window/frame the tool bar was detached
>> from) with a focus follows mouse policy.
>> 
>
> I've made a change, can you test it?
>
> Thanks,
>
> 	Jan D.

I just did, and confirm that focus now switches back to the frame after
clicking a button on the detached tool bar.  Thanks!  

There is another situation where I would like to have the focus switch
from the detached tool bar back to the frame, namely, when I expand the
tool bar but instead of clicking on one of its buttons I just retract it again by
clicking the down arrow a second time.  Prior to your patch the frame
did not regain focus in this case, and with your patch this has not
changed.  Is it possible to get this?  

Actually, there are two cases here and I could imagine (and find
acceptable) different focus behavior in each case.  The one case (a) is
the one I just described; to be more precise: the tool bar stays
expanded after clicking the down arrow and quickly releasing the click,
and to retract it you have to click the down arrow a second time.  The
other case (b) is where you click to expand the tool bar but hold the
click a bit longer; then when you release the click, the tool bar
automatically retracts again.  At least in case (a) I would like focus
to shift back to the frame, after the second click to retract the tool
bar.  For case (b) it would be ok with me if focus remains on the
buttonized tool bar after it automatically retracts.  If it is possible
to get focus to switch back in (a) but difficult to give (a) and (b)
different focus behaviors, then I would prefer focus switching in both
cases.  But if focus switching is not possible or hard to implement in
(a), still the current behavior after your patch is much better than
before.  So thanks again for that.

Steve Berman

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Thu, 18 Dec 2008 21:46:27 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>> Stephen Berman skrev:
>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>
>>>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>>>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>>>> what window manager he is using and what kind of focus model he has (click to
>>>> focus, focus follows mouse)?
>>> 
>>> I'm using KDE/kwin and click to focus.  But I also see the same behavior
>>> (i.e. focus not returning to the window/frame the tool bar was detached
>>> from) with a focus follows mouse policy.
>>> 
>>
>> I've made a change, can you test it?
>>
>> Thanks,
>>
>> 	Jan D.
>
> I just did, and confirm that focus now switches back to the frame after
> clicking a button on the detached tool bar.  Thanks!  

I just learned about the variable x-gtk-whole-detached-tool-bar; when
this is non-nil and the tool bar is detached, focus fails to switch back
to the frame after clicking a button on the detached tool bar.  So your
fix does not work with x-gtk-whole-detached-tool-bar non-nil.

In GNU Emacs 23.0.60.29 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
2009-01-11 on escher 

Steve Berman

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Sat, 17 Jan 2009 21:24:50 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 18 Dec 2008 21:46:27 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>
>>> Stephen Berman skrev:
>>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>>
>>>>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>>>>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>>>>> what window manager he is using and what kind of focus model he has (click to
>>>>> focus, focus follows mouse)?
>>>> 
>>>> I'm using KDE/kwin and click to focus.  But I also see the same behavior
>>>> (i.e. focus not returning to the window/frame the tool bar was detached
>>>> from) with a focus follows mouse policy.
>>>> 
>>>
>>> I've made a change, can you test it?
>>>
>>> Thanks,
>>>
>>> 	Jan D.
>>
>> I just did, and confirm that focus now switches back to the frame after
>> clicking a button on the detached tool bar.  Thanks!  
>
> I just learned about the variable x-gtk-whole-detached-tool-bar; when
> this is non-nil and the tool bar is detached, focus fails to switch back
> to the frame after clicking a button on the detached tool bar.  So your
> fix does not work with x-gtk-whole-detached-tool-bar non-nil.
>
> In GNU Emacs 23.0.60.29 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
> 2009-01-11 on escher 
>
> Steve Berman

The patch below (against the current CVS trunk) makes focus return to
the frame regardless of the value of x-gtk-whole-detached-tool-bar
(i.e., it works both with the proxy (arrow) and the whole detached tool
bar).  Jan D. or somebody else who's familiar with GTK+ should check to
make sure it does not cause any problems elsewhere.

Steve Berman


2009-03-01  Stephen Berman  <stephen.berman@gmx.net>

	* gtkutil.c (xg_tool_bar_callback): Return focus to the frame
	after we have clicked on a detached tool bar button (bug#1405).
	This replaces the reverted change below.
	(xg_tool_bar_proxy_callback): Revert previous change (bug#1405).
	

*** emacs/src/gtkutil.c.~1.146.~	2009-03-01 17:06:07.000000000 +0100
--- emacs/src/gtkutil.c	2009-03-01 17:41:39.000000000 +0100
***************
*** 3461,3466 ****
--- 3461,3470 ----
       this is written.  */
    event.modifiers = x_x_to_emacs_modifiers (FRAME_X_DISPLAY_INFO (f), mod);
    kbd_buffer_store_event (&event);
+ 
+   /* Return focus to the frame after we have clicked on a detached
+      tool bar button. */
+   Fx_focus_frame (frame);
  }
  
  /* Callback function invoked when a tool bar item is pressed in a detached
***************
*** 3480,3490 ****
    xg_tool_bar_callback (wbutton, client_data);
    FRAME_PTR f = (FRAME_PTR) g_object_get_data (G_OBJECT (wbutton),
                                                 XG_FRAME_DATA);
-   /* Put focus back to the frame after we have clicked on a detached
-      tool bar button. */
-   Lisp_Object frame;
-   XSETFRAME (frame, f);
-   Fx_focus_frame (frame);
  }
  
  /* This callback is called when a tool item should create a proxy item,
--- 3484,3489 ----

bug#1405: detached GTK+ tool bar

[Jan D.]

How does this work when the button is a menu, i.e. help?

I will be travelling for 2 weeks. I can't test it until then.

      Jan D.

1 mar 2009 kl. 18.43 skrev Stephen Berman <stephen.berman@gmx.net>:

> On Sat, 17 Jan 2009 21:24:50 +0100 Stephen Berman <stephen.berman@gmx.net 
> > wrote:
>
>> On Thu, 18 Dec 2008 21:46:27 +0100 Stephen Berman <stephen.berman@gmx.net 
>> > wrote:
>>
>>> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d@swipnet.se 
>>> > wrote:
>>>
>>>> Stephen Berman skrev:
>>>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipne 
>>>>> t.se> wrote:
>>>>>>
>>>>>> I'd rather see if the focus can be kept to the frame.  We can  
>>>>>> perhaps put some
>>>>>> hints to the window manager.  I'll look in to it.  Can the OP  
>>>>>> please tell us
>>>>>> what window manager he is using and what kind of focus model he  
>>>>>> has (click to
>>>>>> focus, focus follows mouse)?
>>>>>
>>>>> I'm using KDE/kwin and click to focus.  But I also see the same  
>>>>> behavior
>>>>> (i.e. focus not returning to the window/frame the tool bar was  
>>>>> detached
>>>>> from) with a focus follows mouse policy.
>>>>>
>>>>
>>>> I've made a change, can you test it?
>>>>
>>>> Thanks,
>>>>
>>>>    Jan D.
>>>
>>> I just did, and confirm that focus now switches back to the frame  
>>> after
>>> clicking a button on the detached tool bar.  Thanks!
>>
>> I just learned about the variable x-gtk-whole-detached-tool-bar; when
>> this is non-nil and the tool bar is detached, focus fails to switch  
>> back
>> to the frame after clicking a button on the detached tool bar.  So  
>> your
>> fix does not work with x-gtk-whole-detached-tool-bar non-nil.
>>
>> In GNU Emacs 23.0.60.29 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of
>> 2009-01-11 on escher
>>
>> Steve Berman
>
> The patch below (against the current CVS trunk) makes focus return to
> the frame regardless of the value of x-gtk-whole-detached-tool-bar
> (i.e., it works both with the proxy (arrow) and the whole detached  
> tool
> bar).  Jan D. or somebody else who's familiar with GTK+ should check  
> to
> make sure it does not cause any problems elsewhere.
>
> Steve Berman
>
>
> 2009-03-01  Stephen Berman  <stephen.berman@gmx.net>
>
>    * gtkutil.c (xg_tool_bar_callback): Return focus to the frame
>    after we have clicked on a detached tool bar button (bug#1405).
>    This replaces the reverted change below.
>    (xg_tool_bar_proxy_callback): Revert previous change (bug#1405).
>
>
> *** emacs/src/gtkutil.c.~1.146.~    2009-03-01 17:06:07.000000000  
> +0100
> --- emacs/src/gtkutil.c    2009-03-01 17:41:39.000000000 +0100
> ***************
> *** 3461,3466 ****
> --- 3461,3470 ----
>       this is written.  */
>    event.modifiers = x_x_to_emacs_modifiers (FRAME_X_DISPLAY_INFO  
> (f), mod);
>    kbd_buffer_store_event (&event);
> +
> +   /* Return focus to the frame after we have clicked on a detached
> +      tool bar button. */
> +   Fx_focus_frame (frame);
>  }
>
>  /* Callback function invoked when a tool bar item is pressed in a  
> detached
> ***************
> *** 3480,3490 ****
>    xg_tool_bar_callback (wbutton, client_data);
>    FRAME_PTR f = (FRAME_PTR) g_object_get_data (G_OBJECT (wbutton),
>                                                 XG_FRAME_DATA);
> -   /* Put focus back to the frame after we have clicked on a detached
> -      tool bar button. */
> -   Lisp_Object frame;
> -   XSETFRAME (frame, f);
> -   Fx_focus_frame (frame);
>  }
>
>  /* This callback is called when a tool item should create a proxy  
> item,
> --- 3484,3489 ----
>

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Mon, 2 Mar 2009 08:01:24 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:

> How does this work when the button is a menu, i.e. help?
>
> I will be travelling for 2 weeks. I can't test it until then.
>
>      Jan D.
>
> 1 mar 2009 kl. 18.43 skrev Stephen Berman <stephen.berman@gmx.net>:
>
[...]
>> The patch below (against the current CVS trunk) makes focus return to
>> the frame regardless of the value of x-gtk-whole-detached-tool-bar
>> (i.e., it works both with the proxy (arrow) and the whole detached tool
>> bar).  Jan D. or somebody else who's familiar with GTK+ should check to
>> make sure it does not cause any problems elsewhere.

AFAICT it DTRT; i.e., when I'm in a mode in which clicking the Help
button opens a menu when the tool bar is attached to the frame, the same
thing happens with the detached tool bar, with both the arrow and the
whole tool bar versions.  This is both with and without my patch; the
only difference is that with my patch, after clicking a Help menu item
focus returns to the frame with both types of detached tool bar, while
without my patch, focus returns only with the arrow tool bar.  IOW, also
in this case the patch appears to be OK.

Steve Berman

bug#1405: detached GTK+ tool bar

[Jan Djärv]

Stephen Berman skrev:
> On Mon, 2 Mar 2009 08:01:24 +0100 "Jan D." <jan.h.d@swipnet.se> wrote:
> 
>> How does this work when the button is a menu, i.e. help?
>>
>> I will be travelling for 2 weeks. I can't test it until then.
>>
>>      Jan D.
>>
>> 1 mar 2009 kl. 18.43 skrev Stephen Berman <stephen.berman@gmx.net>:
>>
> [...]
>>> The patch below (against the current CVS trunk) makes focus return to
>>> the frame regardless of the value of x-gtk-whole-detached-tool-bar
>>> (i.e., it works both with the proxy (arrow) and the whole detached tool
>>> bar).  Jan D. or somebody else who's familiar with GTK+ should check to
>>> make sure it does not cause any problems elsewhere.
> 
> AFAICT it DTRT; i.e., when I'm in a mode in which clicking the Help
> button opens a menu when the tool bar is attached to the frame, the same
> thing happens with the detached tool bar, with both the arrow and the
> whole tool bar versions.  This is both with and without my patch; the
> only difference is that with my patch, after clicking a Help menu item
> focus returns to the frame with both types of detached tool bar, while
> without my patch, focus returns only with the arrow tool bar.  IOW, also
> in this case the patch appears to be OK.
> 

It seems to do the trick, checked in.

	Jan D.

bug#1405: detached GTK+ tool bar

[Jan D.]

Stephen Berman skrev:
> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> Stephen Berman skrev:
>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>> I'd rather see if the focus can be kept to the frame.  We can perhaps put some
>>>> hints to the window manager.  I'll look in to it.  Can the OP please tell us
>>>> what window manager he is using and what kind of focus model he has (click to
>>>> focus, focus follows mouse)?
>>> I'm using KDE/kwin and click to focus.  But I also see the same behavior
>>> (i.e. focus not returning to the window/frame the tool bar was detached
>>> from) with a focus follows mouse policy.
>>>
>> I've made a change, can you test it?
>>
>> Thanks,
>>
>> 	Jan D.
> 
> I just did, and confirm that focus now switches back to the frame after
> clicking a button on the detached tool bar.  Thanks!  
> 
> There is another situation where I would like to have the focus switch
> from the detached tool bar back to the frame, namely, when I expand the
> tool bar but instead of clicking on one of its buttons I just retract it again by
> clicking the down arrow a second time.  Prior to your patch the frame
> did not regain focus in this case, and with your patch this has not
> changed.  Is it possible to get this?  
> 

I don't know offhand.  Switching focus isn't the hard part.  It is 
finding out when to do it.  That depends on what feedback Gtk+ gives, if 
this is all done internally we are out of luck.  I'll investigate.


> Actually, there are two cases here and I could imagine (and find
> acceptable) different focus behavior in each case.  The one case (a) is
> the one I just described; to be more precise: the tool bar stays
> expanded after clicking the down arrow and quickly releasing the click,
> and to retract it you have to click the down arrow a second time.  The
> other case (b) is where you click to expand the tool bar but hold the
> click a bit longer; then when you release the click, the tool bar
> automatically retracts again.  At least in case (a) I would like focus
> to shift back to the frame, after the second click to retract the tool
> bar.  For case (b) it would be ok with me if focus remains on the
> buttonized tool bar after it automatically retracts.  If it is possible
> to get focus to switch back in (a) but difficult to give (a) and (b)
> different focus behaviors, then I would prefer focus switching in both
> cases.  But if focus switching is not possible or hard to implement in
> (a), still the current behavior after your patch is much better than
> before.  So thanks again for that.
> 

I will see if it is possible to find out which case has happened.

	Jan D.

bug#1405: detached GTK+ tool bar

[Jan Djärv]

Oops, Stephen is the OP, didn't see that. :-)

bug#1405: detached GTK+ tool bar

[Chong Yidong]

Excerpted from bug#1405:

> ...
> Perhaps this is a GTK+ bug, but I'm not aware of another GTK+ app
> aside from Emacs that uses a detachable tool bar to test for it.

When Emacs got detachable tool bars, it was the standard for GTK
applications to provide a detachable tool bar.  Nowadays, no other GTK
application provides a detachable tool bar as far as I can tell.  (Maybe
this feature was considered useless?)  So maybe we should turn this off.

Jan, what do you think?

bug#1405: detached GTK+ tool bar

[Stephen Berman]

On Sat, 22 Nov 2008 16:38:32 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

> Excerpted from bug#1405:
>
>> ...
>> Perhaps this is a GTK+ bug, but I'm not aware of another GTK+ app
>> aside from Emacs that uses a detachable tool bar to test for it.
>
> When Emacs got detachable tool bars, it was the standard for GTK
> applications to provide a detachable tool bar.  Nowadays, no other GTK
> application provides a detachable tool bar as far as I can tell.  (Maybe
> this feature was considered useless?)  So maybe we should turn this off.
>
> Jan, what do you think?

There is a practical argument in favor of keeping the detachable tool
bar, namely, the "shrinking frame" bug I reported to emacs-devel a year
ago (see http://thread.gmane.org/gmane.emacs.devel/83390).  This bug
still exists, and when it happens -- very often, in my usage -- it is
quite annoying.  But with the tool bar detached, it does not happen.  So
with a detachable tool bar, I don't suffer a shrinking frame and I get
to use the tool bar; without a detachable tool bar, I'd have to choose
one or the other (or change (some aspect(s) of) my desktop).  (Of
course, if the shrinking frame bug is fixed, it would eliminate this
argument for a detachable tool bar.  A remaining argument, but one less
important to me, is that a detachable tool bar saves screen real
estate.)

Steve Berman