Example:  launch "Run Application" from the Actions menu; note that
this dialog can be dragged over a bottom panel or side panel.

Isn't the panel run dialog a transient child of the panel?  Or perhaps
it's in the same group.  The code has always intended to do this,
though it's only recently that it actually worked.

What dialog that isn't a transient ancestor of a window in the panel
group gets promoted to the dock layer?

OK - problem is that the Run Application dialog obscures the GOK
window too, when GOK is in "Dock Mode".  GOK is a separate app - are
you saying that metacity puts all the WM_DOCK windows in the same
group?  That would actually not be good - it would mean that GOK
needed to be override-redirect instead of a DOCK to avoid this
problem.  Ouch.

no; it promotes dialog windows that are in the same group as a dock
window or are a transient ancestor of a window in the dock layer or a
transient ancestor of a window that has been promoted to the dock layer.

This means that panel dialogs will be above the panel, but you can
still raise other dock layer windows above panel dialogs if you focus
them.

Rob: your "no" looks like a "yes" to me, i.e. I asked if all
_WM_TYPE_DOCK windows are in the same group, and you seem to have said
"yes".

That's bad for GOK because GOK needs to be on top of ALL dialogs, even
those modal for other DOCKS; also, GOK doesn't take focus/can't be
focussed.

So the "promote all transients without explicit parent" behavior does
break GOK.

I am trying to set the "_NET_WM_STATE_ABOVE" hint on the GOK window;
do you think the metacity logic could be tweaked to avoid the
promotion for Null-parent modal dialogs above other windows in the
group with the "ABOVE" hint?  I.e.

* if modal dialog, 
* AND null-parent,
* promote above all windows in same group which DO NOT have the ABOVE
hint set.

Would that work?  Or does the panel have ABOVE set too?

This is a significantly bad breakage for GOK.  I think the EWMH
deviation from the ICCCM spec might be biting us here.

If by "group", you mean "layer", then yes.  If by "group" you mean
"group", then no.  We will _enforce_ gnome-panel dialogs above
gnome-panel, but not above other windows in the dock layer.  For other
windows in the dock layer, if the gnome-panel dialog overlaps and has
focus, it'll end up above those.

It might make sense to add a new layer just above the dock layer --
the "dock above" layer, for windows which are both dock windows and
have above set.  Then gok could be above everything, including gnome
panels (though override redirect still poses a problem for gok).

I wish I could test gok, but it segfaults immediately on startup for me.

segfault-on-start bug is http://bugzilla.gnome.org/show_bug.cgi?id=135926

which turns out to be a gtk+ bug (colliding with a weird gok usage
that needed to be binned anyway).

GOK from HEAD avoids the problem, and Padraig's patch for gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=136259 should be applied by
Matthias tonight. 

Then by all means, try gok!  
If you go to GOK's "Windows" button and press "Dock Bottom" and "Fill"
(without a bottom panel of course) you will get gok's "DOCK" mode
which tries its hardest not to be obscured.

You are right, we need a _WM_STATE_ABOVEALL or something, or
_WM_TYPE_ABOVE.  THe same sorts of things happen with gnome-mag's
magnifier window (or did, until I made it override-redirect).

Beware of using GOK via the core pointer, especially if popping up
menus and such, since gtk+ does a pointer grab.  Ugh.  Better results
are achieved by using an alternate mouse/trackball/whatever via
XInput; you'll need to edit XFree86Config to ensure that your extra
XInput device isn't SendCore or AlwaysCore, and you'll need "gok
--settings", where you should select one of the 'switch' Actions and
indicate the extended Input device name you wish to use (for instance,
Mouse[3]).

there's a GOK README that covers the gory details about 'corepointer
mode' and 'extended input'.

I think that it makes sense for metacity to maintain a separate layer
above the dock layer for windows that have above set.  The patch is
really pretty trivial.

Could you try having gok set _STATE_ABOVE in addition to _TYPE_DOCK
and then try it with metacity with the patch that I'm about to attach?
 I don't think that gnome-panel currently sets _STATE_ABOVE; if it
does a patch for gnome-panel may also be necessary.

Created attachment 25239 [details] [review]
add DOCKTOP layer

thanks Rob; I'll try this tomorrow to see what impact it has.
(too bad I discarded the patch I already tried, which set _ABOVE) 
:-/

This could really use wm-spec-list discussion, in particular I'd
suggest this implementation note be extended:
http://freedesktop.org/Standards/wm-spec/1.3/ar01s07.html#STACKINGORDER
Other WM authors need to know to do this if GOK requires it.

I'd call the enum member DOCK_ABOVE probably

Rob: thanks.  for some reason the patch is not working for me - though
I am calling gdk_window_set_keep_above, in stack.c we don't seem to be
getting the 'above' state on the gok main window (I tried this with
direct Xlib calls to change the _NET_WM_STATE property too).  
Can you perhaps try gok calling gdk_window_set_keep_above in
gok/callbacks.c on_window1_resize?  Or perhaps you can help me confirm
that _NET_WM_STATE_ABOVE is really set on this window...

*** Bug 127963 has been marked as a duplicate of this bug. ***

Bill: In reference to you asking for help in confirming that
_NET_WM_STATE_ABOVE is set on a window, doesn't 'xprop | grep
_NET_WM_STATE' (followed by clicking on the appropriate window) work?

One current behavior that strikes me as wrong is the fact that dialogs
can get posted into areas reserved by _WM_STRUT.  If we make metacity
post dialog/promoted windows outside STRUT-reserved space, the impact
of this bug on GOK would disappear.

Metacity won't place dialogs into areas reserved by struts, but it can
do nothing to stop applications from positioning their own dialogs
this way.

I tried testing gok the other day.  I had a bit of trouble because the
code for setting struts seems to be exceedingly broken, perhaps
because of my xinerama setup.  gok was setting utterly nonsensical
struts, such as a right strut when it positions itself at the top left
of the screen.

But the behavior is currently as I has predicted -- it's in the same
layer as panel dialogs but not constrained above or below them. 
Clicking in the gok window raises it above the panel dialog.  I
haven't had a chance to try it with a patched gok, however.

There seems to be both a gtk_window_set_keep_above and
gdk_window_set_keep_above.  The GTK one mentions the EWMH explicitly
in the documentation, so perhaps they are actually doing different
things.  You might try using the GTK version instead of the GDK version.

weird about the struts malfunction.  I admit gok isn't very smart
about struts that are set on the "same edge" of the screen it wants to
use, but I haven't encountered anything quite as broken as you report.
 Can you help me diagnose that perhaps?

when I run GOK with "Actions... Run Program" and move the dialog so
that it overlaps GOK, I see lots of "fighting" between them as both
try to stay on top.  Were you not seeing that?

Note that "clicking on GOK" is not a normal user activity for most GOK
users, as they would be using an alternate XInput device as opposed to
the core pointer/mouse.  GOK needs to stay on top/raise to top without
a mouse click.

Yea I realize that -- I was just saying that the behavior was as I
expected, so I don't think that anything weird is going on, so
therefore  the DOCK_ABOVE/DOCKTOP trick ought to work, once the
correct hints are set up on gok.  As Elijah mentioned, xprop is a
useful tool for diagnosing hint-related problems.

Rob; thanks a lot for the extra investigation.  I haven't had time to
reinstate the ABOVE patch and mess with xprop, but will try next week.
 It would be really cool to get this working in the next couple of
weeks, even if such a metacity change wasn't acceptable for 2.6.1.

This is probably something we can fix for the first Gnome 2.6 point
release.

We can't add a _NET hint without any comment on wm-spec-list

Note that this has been discussed on the wm-spec list.

The topic of discussing making it possible to make certain windows
appear above all others was summarized by me here:

  http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00041.html

Bill made a few additional comments here:

  http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00043.html

David Bolter made some good comments here as well:

  http://mail.gnome.org/archives/wm-spec-list/2003-September/msg00016.html

Here is where Lubos asked for a proof of concept:

  http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00048.html

And Havoc agreed a proof of concept was in order:

  http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00056.html


So, shouldn't it only be necessary to create a proof of concept in order to move
forward with this?

With JDS3-release_07 :

With GOK using 'Dock Bottom', the GOK application can still be obscured.

-GOK -> Window -> Dock Bottom
-Activate bottom panel
-CTRL + F10
-the panel menu obscures GOK

GOK should not be docked at the same edge of the screen as an existing GNOME panel.

With GOK docked at the Top of the screen, open 'Run Application'
There seems to be a conflict of resources when GOK and this application occupy
the same area of the screen. The focus switches between the two applications.

*** Bug 144100 has been marked as a duplicate of this bug. ***

Ref bug #144100

The following sequence is also dangerous : 

gnome-terminal : View -> Full Screen : GOK obscured by gnome-terminal
GOK unusable.

gnome-terminal : View -> Full Screen : GOK obscured by gnome-terminal (deselect)

gnome-terminal : Alt+space (context menu) Maximise window : GOK obscured
GOK unusable.

Perhaps an option would be to remove the 'Full Screen' option from gnome-terminal

I believe removing "Full Screen" from gnome-terminal is wrong.  Rather, I think 
we should simply document what will happen when this option is chosen, and 
encourage GOK users to "not do that" (also Gnopernicus users).  In fact, we 
discussed this very situation recently with BAUM for Gnopernicus, coming to the 
same conclusion.

In that case I wonder if we should provide some user preference like:
Would you like to hide functionality that will lock you out of using the desktop?
And maybe then we can show/hide things like "Full Screen" accordingly?

(Just thinking aloud)

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

wow this fell off the face of the earth.  Independant of WM-Spec issues, I don't
see any reason not to add this minor change to create the DOCKTOP layer, which
is a metacity internal thing.  Havoc?

Comment on attachment 25239 [details] [review]
add DOCKTOP layer

This seems OK but I'd really like to call it DOCK_ABOVE rather than DOCKTOP
just so I don't get confused ;-)

No need to resubmit for review, with that change it can be committed.

Falling off the ends of the world again?

Rob, Havoc: is there a good reason not to call this OVERLAY and not use the word
"DOCK" at all?  Several of the applications we need this for are not 'Dock'
applications, and with COMPOSITE, we have good reason to occasionally want such
windows to be non-WORKAREA-reducing.

What is the status of this?

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

Ping.

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.