Apparently, this was intentional.  From stack.h:
  META_LAYER_DESKTOP        = 0,
  META_LAYER_BOTTOM         = 1,
  META_LAYER_NORMAL         = 2,
  META_LAYER_TOP            = 3,
  META_LAYER_DOCK           = 4,
  META_LAYER_FULLSCREEN     = 5,
  META_LAYER_SPLASH         = 6,

What would you suggest?  I probably wouldn't have a problem with using
META_LAYER_NORMAL instead of META_LAYER_SPLASH in most cases because it would
just appear on top of other windows when mapped and the user would probably just
sit and wait most of the time for the real app window to appear.  This would
also allow the user to interact with other windows if they really wanted to.

However, there's somewhat of a sticking point--what about windows that are "On
Top" (_NET_WM_STATE_ABOVE) or other docks (a11y stuff like gok or whatever)?  If
the user has any of those (besides of course the standard panels that should
only be found at the screen edges), then the splashscreen could appear below
such windows, which may not be what we want.  Of course, it might be exactly
what we want.  I'm not sure.

Havoc, usability people -- thoughts?

I assumed it was intentional, but it's not required or implied by the standard,
and it is causing problems for users of our application which can take about 30
seconds to start up (obscuring their other applications in the process).  I
would suggest that it be treated as a normal window in terms of stacking order
(META_LAYER_NORMAL).

If you ask the usability people they are just going to tell you splash screens
are evil I bet, fair warning ;-)

Normal stacking is probably fine. I thought about some fancier stuff (e.g.
minimize on click) but it could all cause problems.

A really fancy trick would be if there's a splash, associate it with the
"starting ..." button in the task list so you could minimize/unminimize it, but
that sounds hard and not too worthwhile.

IIRC, the GNOME splash screen that displays while logging in can be removed
simply by clicking on it once - perhaps this could be adopted to all
META_LAYER_SPLASH-windows?

It's a fairly simple thing, and it's also a very natural "reaction" to apply to
a splashscreen you want to go away, I'd think.

Of course, this doesn't solve it for users without a mouse ... Perhaps it could
be made to vanish on 'Esc' as well?

Do you know off-hand which version of metacity introduced this stacking order
for splash screens?  We will probably have to stop using the hint in eclipse
because of this problem.

  https://bugs.eclipse.org/bugs/show_bug.cgi?id=83667

Havoc: Well, I almost made the evil comment myself--although perhaps that is due
to being used to a window manager that makes them evil?  ;-)

Billy: The following appears to be the ChangeLog commit:

2002-02-09  Havoc Pennington  <hp@pobox.com>

        * src/themes/Atlanta/metacity-theme-1.xml: put in some kind of
        distinctive frame for UTILITY, though it's ugly. Also put in the
        borderless look for maximized windows.

        * src/stack.c (compute_layer): put splash screen in the splash
        layer

        * src/stack.h (enum): create a splash screen layer

   ...

Which pre-dates Gnome 2.0 and I believe means that it has been in every stable
Metacity release so far.

As far as making splashscreens disappear when they are clicked on or when they
have focus and the user presses Escape--wouldn't that be something that would be
better done at the gtk+ level?

As a general principle I would not advise working around WM bugs in apps; you
get in infinite loops where not all the bugs can be fixed. For example in this
case you could easily create other bugs since metacity won't know what kind of
window that is, and then I can't fix those bugs in metacity.

My favorite historical examples of everyone working around everyone else and
breaking things are:
 - clipboard; app A used CLIPBOARD and app B used PRIMARY, then in the 
   next release they swap to work around each other, multiply times 
   100 apps and watch everything be broken indefinitely
 - handling of backspace/delete in the terminal; apps kept changing to 
   treat one sequence as bs and another as delete (see the options in
   gnome-terminal), and terminals kept changing what they sent when 
   you pressed bs/del to work around the apps. Watch everything be broken
   indefinitely.

The way to avoid these eternal bugs is always the same: write down the spec, and
everyone follow the spec instead of chasing everyone else's tail.

I'd say this is especially true of bugs that aren't critical in nature, as this
one is not. You may as well take the course of action that leads to an eventual
steady-state.

</today's editorial>

This bug in particular is more awkward than it may appear.  On startup, while
showing the splash screen, eclipse pops up a dialog asking where it should look
for data.  This dialog is now being obscured by the splash screen under
metacity.  Similar problems can occur if the Java VM crashes, which will also
cause a dialog to pop up while the splash screen is still present.

I have confirmed that the splash screen is always on top on older versions of
metacity, and since this makes it difficult to start eclipse due to the dialog
being obscured, I am going to have to stop using the hint.

It would be nice if metacity announced its version number in a window property,
as I would really like to use the appropriate hint for our window.  In general I
agree that work arounds are dangerous and should be avoided.  However, if the
side effects are too awkward and the work around is carefully written, they can
be quite useful.  Specs are great, but so are reference platforms and tested code.

</op-ed>

That sounds fine, as long as you're thinking about it in each case.

I'm not opposed to a _METACITY_VERSION hint on the WM check window, that's
pretty trivial for us to do.

I filed bug 165350 about the hint.

Created attachment 36584 [details] [review]
Treat splashscreens same as other windows for stacking; fix unrelated warning about lack of prototype stuff

committed.