emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#1405: detached GTK+ tool bar


From: Jan D.
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Fri, 19 Dec 2008 08:38:12 +0100
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)

Stephen Berman skrev:
On Thu, 18 Dec 2008 19:50:22 +0100 Jan Djärv <address@hidden> wrote:

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]