[Top][All Lists]

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

Re: bug#1405: detached GTK+ tool bar

From: Stephen Berman
Subject: Re: bug#1405: detached GTK+ tool bar
Date: Mon, 24 Nov 2008 01:10:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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

reply via email to

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