GNU bug report logs - #1405
23.0.60; detached GTK+ tool bar does not return focus to its window

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1405 in the body.
You can then email your comments to 1405 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; detached GTK+ tool bar does not return focus to its window
Date: Fri, 21 Nov 2008 22:13:15 +0100

1. emacs -Q

2. Detach the tool bar (GTK+ build only), and notice that the window
(and consequently the frame) it was detached from remains in focus.

3. Click on the buttonized tool bar, thereby expanding it, and notice
that its window/frame is now no longer in focus.

4. Click on the down arrow button again, thereby contracting the tool
bar, and notice that its window/frame continues to lack focus.
Likewise, when the detached tool bar is expanded and you click on one of
the icons to execute its associated command, the window/frame remains
without focus.  This is particularly annoying when the command requests
feedback from the minibuffer, since it is necessary to restore focus to
the frame in order to give the required feedback.  

The expected and desirable behavior is for focus to remain on the
window/frame the tool bar was detached from, or at least for focus to
return to the window/frame immediately after doing either of the click
events in step 4.  (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.)


In GNU Emacs 23.0.60.16 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-11-20 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Message #10 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Jan Djärv  <jan.h.d <at> swipnet.se>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, emacs-devel <at> gnu.org,
        1405 <at> debbugs.gnu.org
Subject: Re: detached GTK+ tool bar
Date: Sat, 22 Nov 2008 16:38:32 -0500

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?

Message #15 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 1405 <at> debbugs.gnu.org,
        Jan Djärv
 <jan.h.d <at> swipnet.se>, emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Sun, 23 Nov 2008 00:08:16 +0100

On Sat, 22 Nov 2008 16:38:32 -0500 Chong Yidong <cyd <at> 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

Message #20 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, emacs-devel <at> gnu.org,
        1405 <at> debbugs.gnu.org
Subject: Re: detached GTK+ tool bar
Date: Sun, 23 Nov 2008 12:01:09 +0100

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)?

Message #25 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, emacs-devel <at> gnu.org,
        1405 <at> debbugs.gnu.org
Subject: Re: detached GTK+ tool bar
Date: Sun, 23 Nov 2008 12:02:09 +0100

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

Message #30 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 1405 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 24 Nov 2008 01:10:20 +0100

On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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

Message #35 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 1405 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 24 Nov 2008 09:03:29 +0100

Stephen Berman skrev:
> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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.

Message #40 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 1405 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 24 Nov 2008 10:58:10 -0500

"Jan D." <jan.h.d <at> 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?

Message #45 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 1405 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 24 Nov 2008 22:41:14 +0100

Chong Yidong skrev:
> "Jan D." <jan.h.d <at> 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.

Message #50 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 1405 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Thu, 18 Dec 2008 19:50:22 +0100

Stephen Berman skrev:
> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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.

Message #55 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 1405 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Thu, 18 Dec 2008 21:46:27 +0100

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

> Stephen Berman skrev:
>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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

Message #60 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 1405 <at> debbugs.gnu.org,
        emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Fri, 19 Dec 2008 08:38:12 +0100

Stephen Berman skrev:
> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> 
>> Stephen Berman skrev:
>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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.

Message #67 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 1405 <at> debbugs.gnu.org
Cc: Jan Djärv <jan.h.d <at> swipnet.se>,
        Chong Yidong
 <cyd <at> stupidchicken.com>, emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Sat, 17 Jan 2009 21:24:50 +0100

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

> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>> Stephen Berman skrev:
>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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

Message #72 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: 1405 <at> debbugs.gnu.org
Cc: Chong Yidong <cyd <at> stupidchicken.com>,
        Jan Djärv
 <jan.h.d <at> swipnet.se>, emacs-devel <at> gnu.org
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Sun, 01 Mar 2009 18:43:13 +0100

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

> On Thu, 18 Dec 2008 21:46:27 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>
>>> Stephen Berman skrev:
>>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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 <at> 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 ----

Message #77 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: "1405 <at> debbugs.gnu.org" <1405 <at> debbugs.gnu.org>,
        Chong Yidong <cyd <at> stupidchicken.com>,
        "emacs-devel <at> gnu.org" <emacs-devel <at> gnu.org>
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 2 Mar 2009 08:01:24 +0100

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 <at> gmx.net>:

> On Sat, 17 Jan 2009 21:24:50 +0100 Stephen Berman <stephen.berman <at> gmx.net 
> > wrote:
>
>> On Thu, 18 Dec 2008 21:46:27 +0100 Stephen Berman <stephen.berman <at> gmx.net 
>> > wrote:
>>
>>> On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <jan.h.d <at> swipnet.se 
>>> > wrote:
>>>
>>>> Stephen Berman skrev:
>>>>> On Sun, 23 Nov 2008 12:01:09 +0100 Jan Djärv <jan.h.d <at> 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 <at> 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 ----
>

Message #82 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: 1405 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
        "emacs-devel\@gnu.org" <emacs-devel <at> gnu.org>
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 02 Mar 2009 09:30:38 +0100

On Mon, 2 Mar 2009 08:01:24 +0100 "Jan D." <jan.h.d <at> 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 <at> 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

Message #87 received at 1405 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 1405 <at> debbugs.gnu.org,
        "emacs-devel <at> gnu.org" <emacs-devel <at> gnu.org>
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Sat, 14 Mar 2009 16:12:53 +0100

Stephen Berman skrev:
> On Mon, 2 Mar 2009 08:01:24 +0100 "Jan D." <jan.h.d <at> 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 <at> 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.

Message #90 received at 1405-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: 1405-done <at> debbugs.gnu.org
Subject: Done
Date: Sat, 14 Mar 2009 18:08:09 +0100

Done

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.