[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