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-boun...@gnome.org [mailto:wm-spec-list-boun...@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.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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
