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

[Danny]

On Wed, Feb 5, 2014 at 3:25 PM, Mikael Magnusson <mikachu at gmail.com> wrote:
> On 5 February 2014 10:42, Danny <danny.smit.0 at gmail.com> wrote:
>> On Tue, Feb 4, 2014 at 5:59 PM, Dana Jansens <danakj at orodu.net> wrote:
>>> On Tue, Feb 4, 2014 at 6:42 AM, 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
>>>
>>>
>>>
>>> _______________________________________________
>>> openbox mailing list
>>> openbox at icculus.org
>>> http://icculus.org/mailman/listinfo/openbox
>>>
>>
>>
>> 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".
>
> --
> Mikael Magnusson
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox

No offence, but that still doesn't give me a clue what is wrong. I'm
no expert at this low level of display/window management, therefore
I'm requesting your help. I'm not really sure what you're trying to
tell by solely pointing at the standard.

>From my perspective the issue seems to point at a bug of openbox, but
since I'm no expert I cannot prove it and can't be sure. From your
firm statements, I'm getting the impression that you don't agree. So
it would be helpful if you could elaborate about why your so convinced
and/or point me in a more concrete direction where to look further.

If your trying to tell me with your statements that openbox is doing
it right, then are you saying that gnome is doing it wrong?

That also makes me wonder why openbox does not accept
_NET_WM_STATE_BELOW, while it does accept _NET_WM_STATE_ABOVE.

I concluded from the output of obxprop in my previous message that the
_NET_WM_STATE client message was successfully delivered to the root
window. Please tell if that is incorrect to assume?

I'm just trying to find a possible bug, in order to make the
opensource world a better place for everyone. Are you willing to help
me to achieve that goal?

Kind Regards,
Danny Smit