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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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