RE: Re: Add _NET_WM_STATE_FOCUSED to _NET_WM_STATE (original) (raw)



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

The keyboard grab issue can possibly be handled by the client by looking for NotifyGrab/NotifyUngrab/NotifyWhileGrabbed, but the other situations seem harder.


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



[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]