Re: Re: Add _NET_WM_STATE_FOCUSED to _NET_WM_STATE

[Owen Taylor <otaylor redhat com>]

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 Atkinson 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