On Thu, 2011-10-27 at 17:43 +0200, Martin Gräßlin wrote:
> On Thursday 27 October 2011 14:47:53 Rui Tiago Cação Matos wrote:
> > Hi, thanks for questions.
> >
> > On 27 October 2011 11:32, Giles Atkinson <giles.atkin...@eu.citrix.com>
> wrote:
> > > Please give a more detailed explanation of the reason for this. I do not
> > > see anything significant in the picture [1].
> > We'd like to style gtk+ applications differently depending on the
> > window being presented by the WM as focused or not. You can see on the
> > mockup that the unfocused window has different colors on its widgets,
> > not only on the window decorations.
> >
> > But clients can do whatever they want with this information of course.
> You mean something like this: http://simplest-image-hosting.net/png-0-plasma-
> desktopi13520
>
> If yes, I do not understand why you need a new flag to do what is already
> possible.
The reason we are looking for this feature is because we don't believe
that it's already possible to do with 100% accuracy.
Some places where I'm aware of where the X focus window (the window that
is getting keystrokes) is different from the window that has an active
window decoration:
* In Mutter, we have the concept of "attached dialogs" - where an
attached dialog doesn't get independent decoration but is instead
attached to the titlebar of the parent window. In this case, the
parent window is still logically "active", even though it isn't
actually the X focus window.
* Metacity allows the user to alt-tab to and "focus" a window that is
marked by the application as being "No Input" according to section
4.1.7 of the ICCCM. This is necessary to make the desktop fully
keyboard accessible, because the user has to alt-Tab to the window
first in order to access it's window menu with alt-Space.
In this case, the titlebar is displayed in the active state, and the
window contents should match this.
* During keyboard grabs - which could be:
- Showing an application menu
- Showing the window menu
- In metacity/mutter, anyways, when the window is being moved or
resized with the keyboard, to enable the arrow keys to work.
The keyboard grab issue can possibly be handled by the client by looking
for NotifyGrab/NotifyUngrab/NotifyWhileGrabbed, but the other situations
seem harder.
- Owen
_______________________________________________
wm-spec-list mailing list
wm-spec-list@gnome.org
http://mail.gnome.org/mailman/listinfo/wm-spec-list
