Created attachment 63235 [details]
The fix

@pl: would you be ok with this fix?

According to the EWMH spec this would be wronger still. Please note that the
spec refuses to define FULLSCREEN with respect to Xinerama wholesale. Which
brought us this mess in the first place (yes, Window Managers generally are very
good in creating a mess ;-( ). A utility window would usually be decorated -
which we don't want and it would not be on top - which we want. Moreover utility
windows should usually be transient, which is not the case for the slideshow either.

That said there are some metacity versions that make a fullscreen window full on
one screen while kwin makes fullscreen windows full on all screens. In OOo that
is a user setting, so both behaviors are less than what is needed.

quoting from the EWMH spec:

_NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window
Manager would keep such windows on top of all other windows.

_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as
a palette or toolbox. It is distinct from type TOOLBAR because it does not
correspond to a toolbar torn off from the main application. It's distinct from
type DIALOG because it isn't a transient dialog, the user will probably keep it
open while they're working. Windows of this type may set the WM_TRANSIENT_FOR
hint indicating the main application window. 


Sorry, but I think aside from fixing your special problem on your special Window
manager, that patch is not an improvement and probably as detrimental effects on
other WMs.

@pl: hm. first off, it does work with metacity, kwm & compiz here. second, the
on-top feature is explicitely requested on line further down, so apparently this
is already taken care of. third, decoration also seems to be handled orthogonal
to WINDOW_TYPE (I did not actually check how gtk translates those hints to X11
ones, though your explanation suggests they are taken literally). and last but
not least, we seem to agree that all this xinerama special casing is a gross
hack anyway, so we might get away with making it work on at least the most
common window managers? ;) 

decoration and windowtype are SEEMINGLY handled separately in gtk API.
Unfortunately that does not have an equivalent in the EWMH spec. Window managers
decide about decorations based on the window type (see the second sentence here:
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2522894 ). The
reason I prefer the DOCK type is that it tends to get risen above other windows,
which is not the case for UTILITY windows. gtk_window_set_keep_above basically
sets _NET_WM_STATE_ABOVE - which to work needs to be supported, but is optional
like most other EWMH spec specifics (yes, you can't really rely on anything even
with EWMH). So DOCK works on more WMs than STATE_ABOVE (more or less because
it's older). Plus nobody has an idea whether decorations will be present for the
window or not.

Just that gtk pretends to be able to switch of decorations for any window does
not mean anything; on X11 this simply sets another set of hints (namely the good
old MWM hints) which are directly opposed to the type based decoration handling
that the EWMH encourages. Note that the EWMH spec does not even mention the MWM
hints, this is just a de facto standard guaranteed to be switched off by some
zealot WM in the name of removing "legacy".

However there is one thing I'll grant you: if it works on kwin, compiz and
metacity, and brings an improvement there, you may have a point. If you checked
whether STATE_ABOVE is actually supported (you can use the WMAdaptor for that,
for a EWMH WM it knows all supported protocols), you could use utility instead
of dock.

*** Issue 103277 has been marked as a duplicate of this issue. ***

FWIW, see also issue 103277 my current KWin won't give focus at all to a
GDK_WINDOW_TYPE_HINT_DOCK window :-(

See what I mean about the mess window managers create; you can cater to the
quirks of every single one :-(

So guys, the patches are mutually exclusive, can we come to a single one ?
Obviously DOCK is not en vogue anymore, so would you favor UTILITY or TOOLBAR ?
Both of which are obviously not quite right (as was DOCK int the first place).

Spec is uselessly vague on all of them of course, personally wrt. KWin, I'm not
campaigning in any way to do anything to out of the ordinary to make it work,
just a heads up as to *why* it doesn't work. Maybe it'll get fixed.

let me try with toolbar here.

HINT_TOOLBAR works, swapped it for the former DOCK (and instead of the UTILITY
from the patch). Checked in metacity, kwin & compiz.

For QAing this, you need a xinerama setup, and the mentioned three window
managers. One should now be able to switch workspaces without the slideshow
window  sticking to the screen; additionally no decoration should be visible,
and the slideshow should be as much on top as it was before (n.b. it didn't
always work for me in metacity even before this change).

@pl: verified that tested wms claim NET_WM_STATE_STAYS_ON_TOP in the wmadaptor

Committed & pushed change into CWS vcl103

verified in CWS vcl103

closed, integrated m54