RE: Re: Add _NET_WM_STATE_FOCUSED to _NET_WM_STATE

[Giles Atkinson <Giles Atkinson eu citrix com>]

Now that this has been fully explained, it makes a lot of sense - at least to me.  But that information should have been available in the patch, which shares a common fault of almost all software documentation: no description of purpose or semantics.  It says this:

+_NET_WM_STATE_FOCUSED indicates that the window is being presented as
+focused. This is purely an hint about how the Window Manager visually displays
+the window, in particular it's unrelated to input. Clients MUST regard this as
+a read only hint which they can't change.  The window given by
+_NET_ACTIVE_WINDOW will usually have this hint, but at times other windows may
+as well, if they have a strong association with the active window and will be
+considered as a unit with it by the user. This hint generally corresponds to
+whether window decorations are drawn in an active state.

There is no indication of what clients are expected to do with this, or why.  I suggest the inclusion of something like this:

Clients that modify the appearance of internal elements when they expect to receive input (keyboard or mouse) SHOULD use this indication in preference to FocusIn or EnterNotify events, when it is available.  By doing so they will accurately reflect the intentions of the Window Manager.

Giles

-----Original Message-----
From: wm-spec-list-bounces gnome org [mailto:wm-spec-list-bounces gnome org] On Behalf Of Owen Taylor
Sent: 28 October 2011 18:40
To: Martin Gräßlin
Cc: wm-spec-list gnome org
Subject: Re: Re: Add _NET_WM_STATE_FOCUSED to _NET_WM_STATE

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


_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
http://mail.gnome.org/mailman/listinfo/wm-spec-list