Truls Becken wrote: > On Nov 22, 2007 11:28 AM, Fred Kiefer <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep