[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Menu windows appear in window manager windows list ?
From: |
Fred Kiefer |
Subject: |
Re: Menu windows appear in window manager windows list ? |
Date: |
Thu, 29 Nov 2007 02:47:07 +0100 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20070801) |
Truls Becken wrote:
> On Nov 22, 2007 11:28 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
>>> I see from xprop that _NET_WM_STATE is not set on the menus. How about
>>> setting that to _NET_WM_STATE_SKIP_TASKBAR and
>>> _NET_WM_STATE_SKIP_PAGER ? My panel does this in addition to
>>> _NET_WM_WINDOW_TYPE_DOCK.
>>>
>> We already have code that should be doing exactly this in place in
>> XGServerWindow.m, starting line 3152. Most likely I did get the
>> specification wrong and it isn't sufficient to send a message, we also
>> have to set the property. In the other places where I call sendRoot: we
>> already do this.
>>
>> Anybody willing to write a patch for this?
>> Some simple XChangeProperty() with add and remove should be enough.
>
> I gave this a shot, but could not get it to work correctly. The
> following observations were made:
>
> 1) The net_wm_state hint needs to be set every time the window is
> about to be displayed. I open TextEdit and the main menu has
> skip_taskbar and skip_pager set. Switching to xterm and back to
> TextEdit, and the state hint has been cleared. The first time I open
> the Document menu, skip_taskbar and pager are set. Second time it is
> opened the hint is cleared. Reading the EWMH spec reveals that this is
> actually correct behavior for this particular hint:
>
> http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2511406
>
> "The Window Manager should remove the property whenever a window is
> withdrawn, but it should leave the property in place when it is
> shutting down, e.g. in response to losing ownership of the WM_Sn
> manager selection.
>
> Rationale: Removing the property upon window withdrawal helps legacy
> applications which want to reuse withdrawn windows. Not removing the
> property upon shutdown allows the next Window Manager to restore
> windows to their previous state. "
>
> 2) For some odd reason that I was not able to figure out, the actual
> document windows in TextEdit get skip_taskbar and skip_pager set, even
> though they are window_type_normal. The code is supposedly not setting
> up that combination.
>
> 3) OpenBox includes the net_wm_window_type_menu windows in the alt-tab
> ring even when they do have skip_taskbar/pager set, but it leaves them
> out of the window list (middle click on desktop) - until the issue in
> 1) kicks in of course. The net_wm_window_type_normal windows OTOH are
> excluded from alt-tab while the skip flags are set. Oh, the joy.
>
> I made an attempt at setting net_wm_state when windows are re-mapped
> by simply removing an if statement in -setwindowlevel. This did make
> the hint stick, but also introduced a weird situation where xprop
> sometimes gave results like:
>
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_ADD, _NET_WM_STATE_SKIP_TASKBAR,
> _NET_WM_STATE_SKIP_PAGER, PRIMARY
> or:
> _NET_WM_STATE(ATOM) = _NET_WM_STATE_REMOVE,
> _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, PRIMARY
>
> on windows that stick around for longer periods, i.e. the ones that
> are not unmapped when the application looses focus. This urged me to
> try to only use net_wm_state_skip_taskbar and net_wm_state_skip_pager
> as data, but this somehow only set skip_taskbar, and it was cleared
> again on window unmap. I also tried using PropModeAppend without much
> success. Note that PropModeReplace might even be wrong for this hint
> since the window manager adds state info such as shaded, maximized,
> sticky, below, etc.
>
> Attached is a patch that adds the XChangeProperty() call. It also adds
> three atoms to XGWMNetStates, which I assumed was the proper way for
> frequently used atoms. The attempt to repeatedly set the hint is in
> the second file. Alas, neither of these are any good. It seems that
> successfully applying the net_wm_state hint requires quite a bit more
> work, and a different hint is probably necessary to skip the alt-tab
> cycle on some window managers.
>
It turned out that my code there was wrong, _NET_WM_STATE_REMOVE and
_NET_WM_STATE_ADD aren't X atoms, but simple constants. After changing
that and adding the same setting in orderWindow::: it seems to work for
me. Please give the latest SVN a try.
For some most likely unrelated reason I now have problems with
activating a GNUstep application without windows, but this already
happened before this patch. I will have to take another look at the
activation mechanism :-(
Fred
- Re: Menu windows appear in window manager windows list ?, (continued)
- Re: Menu windows appear in window manager windows list ?, Stefan Bidigaray, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Philippe Roussel, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Charles philip Chan, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Philippe Roussel, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Charles philip Chan, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Philippe Roussel, 2007/11/22
Re: Menu windows appear in window manager windows list ?, Gregory John Casamento, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Truls Becken, 2007/11/21
- Re: Menu windows appear in window manager windows list ?, Fred Kiefer, 2007/11/22
- Re: Menu windows appear in window manager windows list ?, Truls Becken, 2007/11/22
- Re: Menu windows appear in window manager windows list ?,
Fred Kiefer <=
- Re: Menu windows appear in window manager windows list ?, Philippe Roussel, 2007/11/29
- Re: Menu windows appear in window manager windows list ?, Truls Becken, 2007/11/29
- Re: Menu windows appear in window manager windows list ?, Fred Kiefer, 2007/11/30
- Re: Menu windows appear in window manager windows list ?, Truls Becken, 2007/11/30