[openbox] _NET_WM_STATE_BELOW doesn't work when set by an application

Andrew Gallant jamslam at gmail.com
Wed Feb 5 16:31:25 EST 2014


In order to understand the interaction between a window manager and a
client, one MUST read the relevant standards. The EWMH is quite
explicit on the _NET_WM_STATE property:

"The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn
window requests to be mapped. A Client wishing to change the state of
a window MUST send a _NET_WM_STATE client message to the root window
(see below). The Window Manager MUST keep this property updated to
reflect the current state of the window."

To explain a bit further, this means that it's possible for a client
to simply change the property directly on a client and have it work,
but it MUST be done before the window has been mapped. (A WM only
starts managing a window when it is mapped to the screen by a client's
request---not when it is created.) But after that, the only way to
update the property---from the client's perspective---is to send a
client message. More to the point, a WM may also use Qt, and a WM
*should* be keeping the atoms in the _NET_WM_STATE list up to date.
This explains why there is a way to both change the property directly
and send a message to change it in Qt. The OP shouldn't assume that
these methods are mutually exclusive. The EWMH spec makes it pretty
clear when one should be used.

In general, for each property specified in the EWMH, there are up to
three ways for interacting with each: reading, writing and behavior
changes. For atoms like _NET_WM_STATE---which have valid uses for all
three interactions---generally the client only reads and requests
behavior changes with client messages. The WM is typically the only
one doing the writing.

This advice should translate to, "OK, I need to find a Qt function
that sends a client message to _NET_WM_STATE and NOT a function that
just changes the property."

- Andrew


On Wed, Feb 5, 2014 at 4:10 PM, R. Mattes <rm at mh-freiburg.de> wrote:
> On Wed, 5 Feb 2014 14:08:39 -0500, Dana Jansens wrote
>> On Wed, Feb 5, 2014 at 1:56 PM, Danny <danny.smit.0 at gmail.com> wrote:
>> [...]
>> >>>> Hello,
>> >>>>
>> >>>> I'm using the default openbox (on gdm) on CentOS 6.5 and are working on an
>> >>>> application (based on Qt 5.1.1) which tries to set one of its windows
> to the
>> >>>> background. The application uses the Qt API to achieve this. This should
>> >>>> result in the windows manager flag _NET_WM_STATE_BELOW to be applied to the
>> >>>> window. It seems that openbox doesn't react on this window manager flag.
>> >>>>
>> >>>> To come up with a simple test case, I tried the same with the Qt example
>> >>>> "windowsflags". This results in the same behavior, the window doesn't seem
>> >>>> to be kept below when the application asks for it.
>> >>>>
>> >>>> Additionally testing shows that this also aplies to Openbox 1.5.2, which
>> >>>> is manually compiled from the sources.
>> >>>>
>> >>>> Furthermore, when using the openbox configure to set the specific window
>> >>>> to the lowest layer, it does seem to work as expected, as long as the
>> >>>> application itself doesn't ask to keep the window in the lowest layer.
>> >>>>
>> >>>> Another weird side effect is that the application is able to keep one
>> >>>> window on top. However this doesn't work anymore if the same application
>> >>>> also asks to keep another window below.
>> >>>>
>> >>>> Could this be a bug in openbox? Are there any suggestions how to proceed
>> >>>> with this issue?
>> >>>
>> >>>
>> >>> To change the state of a mapped window, a Client MUST send a _NET_WM_STATE
>> >>> client message to the root window:
>> >>>
>> >>>   window  = the respective client window
>> >>>   message_type = _NET_WM_STATE
>> >>>   format = 32
>> >>>   data.l[0] = the action, as listed below
>> >>>   data.l[1] = first property to alter
>> >>>   data.l[2] = second property to alter
>> >>>   data.l[3] = source indication
>> >>>
>> >>>   other data.l[] elements = 0
>> >>>
>> >>> via http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
>
> This isn't really helpfull for the OP since he/she uses Qt and does not
> send raw messages to the server ....
>
>> >>
>> >> I noticed the Qt library uses xcb_change_property() calls to update
>> >> the windows properties, which seem fine to me and also are working
>> >> properly under gnome2.
>> >>
>> >> Is it correct to assume that if the obxprop command gives the
>> >> following result on the window:
>> >>
>> >> _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_BELOW,
>> >> _OB_WM_STATE_UNDECORATED
>> >>
>> >> The messages are correctly applied and the window is expected to stay
>> >> below the others?
>> >
>> > There is not much ambiguity in "MUST send a _NET_WM_STATE client
>> > message to the root window".
>
> Which neither answers any of the OP's questions nor helps in deciding who's
> responisble for the described behaviour (OpenBox/libxcb/X).
>
> I'm in a hurry, but a quick grep and a bit of Google shows that Qt provides
> _two_ methods, QXcbWindow::setNetWmWindowFlags which only calls
> xcb_change_property and QXcbWindow::changeNetWmState which _does_ send an event
> to the root window.
>
>  HTH Ralf Mattes
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox


More information about the openbox mailing list