Created attachment 8404 [details]
screenshot to display this bug

Can you try with a CVS version containing this ChangeLog entry:

2002-05-10  Havoc Pennington  <hp@pobox.com>

	* src/tools/metacity-window-demo.c: add override redirect test
	window

	* src/stack.c (raise_window_relative_to_managed_windows): new
	function, used to avoid moving windows above override redirect 
	popup windows.
	
	* src/display.c (event_callback): don't lower panels on
	LeaveNotify if they have focus, #70895

I have done so, but still no luck.
to be more specific, sawfish from gnome1.4 does not have this bug. I 
have not tried with sawfish in gnome2.

I just tried out with sawfish in GNOME2 and it does not have
this bug, i.e the app window does not hide the drawer panel.
So, is this something that we need to fix in metacity?

The fix probably involves Metacity somehow. I'm not sure exactly what
needs fixing though. The fix might also involve the panel.

It's possible the fix is that when Metacity raises a panel it should
raise all panels, not just the focused panel... I'm not sure.

Yeah, I guess it should raise all panels. I created a floating
and a sliding panel and with Metacity, these can also be hidden
behind the app. But in sawfish, all the panels are always raised.
Havoc, how do we keep all the panels raised?

The way it works now is that a panel raises when the mouse moves over
them, and lower when the mouse moves away from them. Perhaps we want to 
adjust this behavior a bit, and raise all panels when you move into
any of them.

Do we want to raise all panels only when we move into one of
them, or do we want to keep all the panels raised all the time?
I think sawfish exhibits the latter behaviour. Not sure if that
is the correct one.

Havoc, from a code perspective how do we identify windows
that are panels? And if we want to keep them raised at all
times, does it need to be done in Metacity or in panel? I was
wondering how sawfish does it though.

I'm not totally sure what the behavior should be; I kind of like only
raising them when you move the mouse into one of them, I guess. But 
we should ask the UI guys. I think raise-on-mouseover seems to make
people fairly happy, no one has asked for a preference for whether the
panel stays on top yet, and I bet if we make it stay on top always
they will start asking.

From a code standpoint this is done in Metacity, and a panel has 
window->type == META_WINDOW_DOCK.

Always raised has the advantage that it works the most predictably.
That is, the user doesn't really need to think about it or figure out
anything.

What sort of things do you expect people would file bugs about if the
panels were always raised (in other words, what cases are there where
we want the panel covered?).

My conception of the panels is that they are "glued to the front of
the monitor" which is why they appear in all workspaces, etc. That
also suggests they'd always be on top. I'm a little concerned about
introducing more window-like behavior to them (specifically allowing
them to interact in terms of "depth" with other windows).

That said, the current behavior has been pretty much transparent to
me, so I don't know if its really an issue. Just speculation...

What "always raised" means is that you permanently lose the screen
area belonging to the panel, while at the moment you can have a window
that uses that area.

I think the current "raise when you're using the panel" behavior has a
nice do-what-I-mean feel to it, as long as the panel is mostly controls. 
If the panel were mostly monitors and indicators we might lean more
toward always-on-top, perhaps.

Thinking about it that way, there's a clock on there already and I'm
thinking of adding some other monitor-type features by default in Red
Hat anyway, so that argues for always-on-top.

Think you've hit the nail on the head there-- the current setup works
great when your panels are mostly on-demand controls, but isn't so
good when it's all stock tickers and weather reports :)

This may be idle ill-informed Friday evening speculation, but I'm
guessing that making panels always-on-top, in combination with the
existing show/hide/autohide options, would just about cater well
enough for everyone with the minimum of fuss.

One thing I'm worried about for always-on-top is that things like Xine
try to play a fullscreen movie by just raising their window to the
top. So there you'd end up with the panel on top of your movie. :-/
There's no way for Metacity to distinguish that movie from 
a regular application window, we would have to say that the bug is in
Xine and that Xine must use "fullscreen mode" (as in gnome-terminal) -
Metacity could then put "fullscreen" apps above the panel. But that 
would break current versions of Xine. 

I'm willing to do that but it's kind of a "take a stand" kind of thing
that will break some stuff short-term so I'd want to feel like I had a
good rationale.

Of course it's broken if we add a pref as well, since you usually want
panels on top but have to manually change them all to be 
on bottom when you start Xine, then fix them again later, etc., so 
taking a stand is probably right, but everyone will whine about it.
;-) Louie was just complaining about something like this the other
day. ;-)

I don't know what's right here in pragmatic terms. I'm increasingly
convinced that always on top is better overall, but breaking apps like
xine is a little annoying (as I found out last night when I played a
DVD and had to remov ethe gnome-panel from the session so it wouldn't
show up :-)

On the other hand there aren't too many major apps that do this with
legitimate reason (basically movie players, slide shows and powerpoint
style things, and games, but those usually grab the screen through
opengl anyway)... So maybe we could go to "always on top" and just
make an effort to get application writers such as Xine to make the
fixes *now*, and help them as necessary.

So, are we agreed on keeping the panel raised at all times?

I fixed the drawer panel problem in a simpler way (handle window raise
requests). I think I can work around Xine etc. by automatically
putting things in the fullscreen state if they are sized to the entire
screen 
and not decorated, too. So that might make panel-on-top more feasible.

We may still want panel-on-top for the case of keeping monitor-type
gadgets visible, or maybe we should just say "don't move your windows
over your monitors if you want to see the monitors"

I like panel-on-top because it makes the interface stable. It means
that navigation, launching, etc are static things in GNOME that I
don't have to futz with or worry will get hidden.

If I take a mozilla window and move it over my bottom panel (the
application switcher), its completely non-obvious how I get the panel
back on top. These things really really do happen. They happen all the
time to my mother (that and getting windows lost off the screen).

Panel on top removes this concern, and it makes the interface less
abstract. Interface constants are *good* they make the experience more
stable, even if they aren't the "smartest" action in any given situation.

The magic word here is "cognitive friction". Having places on the
screen that always do the same thing no matter what is very good,
particularly *management* tasks like application switching and
launching. It makes the escape route very obvious.

Fixing some things is fairly doable (xine, for example) but the odds
of getting, for example, open office to fix their slideshow viewer are
really low. My community-member self says 'screw 'em' but speaking
with my Sun hat on, fixing proprietary software isn't always an
option, so if this happens, some other fix for full-screen apps really
ought to go in as well.

Given that the original cause of this (the drawer panel problem) is
now fixed, is it fair to mark this an enhancement? I've done that now,
but this is clearly overrulable.

Oh no, please don't change the current behaviour. metacity is the
first wm to get it "right" the way I just come to expect it. I hate it
when I move a window _under_ a panel and can't do anything to show it
again (other than move the whole window e.g. up)

I need to check what KWin does.

One point here is that autohide panels should always be on top, even
if regular panels aren't; and also, autohide panels could work well
for people who like the current behavior. Hmm.

Note to self, close
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70739
when this is closed.

Not having panels always on top has a whole host of problems. A new
one I've noticed is when you have a window covering the panel, and the
current focused window maximized. Its a realy PITA, very annoying.
Particularly when Mozilla insists on positioning itself over the panel
all the time, and all of the sudden you look down to find your panel
covered by 10 mozilla windows.

The extra "flexibility" here just isn't worth the loss of
realiability. Being able to depend on always having something like the
panel available is critical. It is the escape path.

What are the cases where we should allow windows to be on top anyway?

I made the change to always-on-top yesterday afternoon.

throw an eye on my comment from
http://bugzilla.gnome.org/show_bug.cgi?id=90012 thank you.

I have a really strong feeling this change will bring hellfire from
the more vocal members of the GNOME community.

Personally, I like my panels to be below all other windows.  I
understand some of the points made above for panels above all other
windows, but I treat my panel as an active part of the desktop (I use
a panel pixmap so that it blends in with the desktop wallpaper).

Please consider an option in to position panels above or below all
other windows.

Never change anything in the midst of hellfire - always wait for the
dust to settle. ;-) That's my motto.

http://bugzilla.gnome.org/show_bug.cgi?id=90012 and now throw an eye
on the attached picture.... hypothetical one but maybe there is a
chance that exactly 1 person is using his panels that way.

it would be fair to have a toggable preferences in metacity either
from gconf or whatever. this would be a fair temporarely solution that
i can live best with.

> Never change anything in the midst of hellfire - always wait for the
> dust to settle. ;-) That's my motto.

the way you listen to 'users needs' ? i mean i respect you as
programmer somehow.. but not everything you decide and do is well
thought. probably something for /. with the topic 'look how they give
a shit to users needs'

Ali if you think you can flame me into changing anything you are wrong.

The point of Metacity is to experiment with making everything Just Work,
by specifying what's required in the window manager spec, and adapting 
apps to handle that. This is the point.

If keeping the panel on top doesn't work we will change it back. But 
first we have to try it out and give it time to "cook" including
looking at the correct fix for each UI issue that arises. Metacity's
main original reason for existence is to _find_ all the correct fixes,
instead of adding a bunch of workarounds.

If you don't want to participate in the project to make things Just
Work, then use another window manager, please. Don't try to change the
project goals of Metacity.

I have no idea why people who want traditional WM behavior use
Metacity. Metacity has always been about hardcoding things and fixing
things properly in the long term. If you are not interested in those
goals, use another WM. That's why there's a choice of WMs available.

We are trying this change for now, we need to look at each specific UI
issue, root causes, and possible ways to address it, and when we have
collected all that data then we will see whether to change it back or
whether to fix apps. But not before. If you want to speed things up,
you need to be looking at how xmms and gkrellm work, what WM hints
they are setting, and cataloging _each_ specific UI issue and
considering ways to avoid that issue that do not involve adding
preferences.

(Sorry, I made this comemnt on the bug this morning, but I don't see
the comment; maybe somebody accidentally overwrote it in a "submission
collision).

Ali, I highly suggest you file bugs against xmms and gkrelm. XMMS
bugzilla can be found at http://bugs.xmms.org/. GKrellM appears to
have no bug database but does have a mailing list. Alternatively, you
can use Rhythmbox for playing music and use the system monitor panel
object to replace GKrellM.

Its important to remember that you are not the only user. Listening to
"all user requests" is part of what got GNOME into a usability mess.
Principle: the union of user requests is *NOT* the maximuum of
usability (in fact, its probably very poor usability). 

There is a cost to ever preference, to every work-around, etc. For
example, if window managers hadn't kept adding workarounds we wouldn't
have to deal with problems like xmms and gkrellm today: they would
have been written right in the first place. We're all better off if we
take a little pain today in return for long term benefits. I hope you
can appreciate this, even if its obnoxious to have this behavior in
your daily work.

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

I would like to vote for a reversion away from "Always on top" back to
either "always on bottom" (i.e. the panel is part of the background)
or "raise on mouse over".

Seth Nickel gave an argument for "always on top" but has used only one
cognitive model to support this.  Havoc Pennington has used Seth's
argument as grounds for trying the idea, which is fine but I would
like to argue that the result is not always correct and is therefore
problematic.

I think we can all agree that there are only really three basic
behaviours:  always on bottom, raise on mouse over and always on top.
These three represent three distinct views of the role of the panel: 
background information, low priority control and information, highest
priority control and information.  Seth has argued for the last of
these but I would say that it is personal preference rather than an
objective statement of human--computer interaction, that the argument
he puts forward is not true for all users.

I personally work with always on bottom whereever possible since the
panel is, for me, part of the background and I want my windows to
obscure the panel -- the windows are more important for me than the
panel:  the windows are the applications that I am working with and
the panel is an information device.  If I want to access the panel as
a control device I move the windows out of the way.  I reinfoce this
view by making the panel background a part of my screen backdrop. 
This however is a personal view albeit shared by many not a statement
of absolute usage.  That is realy my point.

I would say that extremes such as always on the bottom or always on
the top disenfranchise part of the user population, those whose
working methods do not fit with the given model.  This indicates that
 normally below with raise on mouse over is the least troublesome
solution if there is to be only one.

I would argue for this to be a user selected option between the three
behaviours but if there is to be only one behaviour that it should be
 raise on mouse over.

I know that this "bug" is marked RESOLVED but I feel it should be
reopened.

There are very few objective statements in HCI, but that doesn't mean
that the rest based off personal preference (or, at least, not the
personal preference of the designer). The "cognitive model" I have
proposed is, I believe, substantially dominant does not produce
healthy interfaces. Its good coding practice and bad design practice.
Instead you should focus the design on the majority use case, trying
to pick up as many edge cases as you can without substantially
impacting the majority use case. I think your assesment that "many
people" like to work with the panel like you do is incorrect. I have
spent countless hours watching people use workstations, and I have
seen *very* few people use panels as a "below the windows" sort of
object. So the above is an argument against making this preference... 

As for the specific principles governing the assessment of
panel-on-top as the most desirable "cognitive model":

   a) Reduces cognitive friction - every time you have interface
elements that exhibit multiple behaviors you are increasing the level
of abstraction user's will have to apply to make sense of their
interaction. Panel on top removes the idea of panels as subject to the
window interface and provides a stable set of pixels users can rely on
to be there "in any situation".

  b) Provides a clear exit path - Window switching and application
launching are particularly critical functions. Having the panel on top
reduces the chances that users will find themselves "stuck". If the
panel is always on top

  c) Develops automated responses - most Linux users have stopped
getting any benefit out of this sort of thing because our interfaces
have not provided them. Watch a Macintosh user, however, and you'll
find that their pointer practically flies when accessing menus or, in
particular, the window switching pulldown. This is a combination of
Fitt's law, so called "muscle memory" and the reduction of pauses
caused by variables the user must track to ensure that the operation
is valid. Instead the "I want to switch windows" thought maps very
quickly into a mouse movement. With panels that drop layer, you end up
with a constant extra layer of indirection.

i know this bug is closed, but i thought i'd give my perspective as
well.  first of all, i have no problems with doing it the "right" way,
and asking application developers to "fix" their implementations (e.g.
xine).  however, i noticed a (possibly) annoying side-effect of having
to force applications like xine to use the fullscreen attribute like
gnome-terminal does in its fullscreen mode.  occasionally while i'm
watching a fullscreen movie (in xine), i'll get an im message or
something.  now, sometimes i'd be just as happy if it would pop up in
the background and not annoy me.  but other times i drag the aim
window to the bottom left of my screen and resize it to fit in the
black bars above and below the picture (yay widescreen version).  now
i noticed with gnome-terminal in fullscreen mode that it doesn't allow
other windows on top, even if you alt-tab to select them.

now i may be an abnormal user, and i suppose it might be more
'correct' for me to realise that if i can put up with watching a movie
with an aim window on the bottom, then i can sure as hell just turn
off xine's fullscreen and instead maximise the xine window, which
would allow me to put other things on top of it, and i'm sure that's
exactly what i'll do when xine gets 'fixed.'  but it will be an
annoyance, and i just thought i'd point it out.

also, i was actually wondering _why_ panel on-top-ness is being
handled by the window manager.  as i recall, in gnome 1.4, the panel
itself actually had a preference for it's state - i believe there was
an option for "always under" (tho i don't know why that's useful at
all), "always on top," and "same level as other windows."  there was
also an option to autoraise it when the mouse scrolled over it (which
i liked quite a lot and used myself).

now i'm torn between the window manager's responsibilities here.  in
some ways i agree with the current system of (i presume) having
different window classes - dialog, toplevel, fullscreen, etc. and
having default behaviours defined by the window manager.  in other
ways, i really think the window manager should be quasi-dumb.  the
application should tell the WM its category to _hint_ to thie WM about
its behaviour - e.g. so that dialogs can be placed centered over their
parents, if desired - but i think that if a particular application
wants its window on top of everyone elses, it should say so explicity,
and if it doesn't say so, the WM shouldn't make that choice for it. 
now, i don't know a whole lot about window managers, so i suppose that
could cause some contention - e.g. what to do when two 'always on top'
windows are overlapping - but, IMHO, this is the more 'correct'
approach.  i have no problem with the _default_ being that the _panel_
(not the WM) is set to be always-on-top, but i really don't see it as
featuritis to allow the user the option to change this if he/she so
wishes.

so to summarise my position (sorry for being long-winded):
1) the window manager should not make absolute decisions for
applications if the applications where the apps don't explicity state
what they want - the principle of "if you don't know what to do, do
nothing"
2) applications (including gnome-panel) should tell the window manager
if they want to be on-top, or on-bottom, or whatever
3) ultimately, the user should choose, via a pref, whether in the WM
or in the app itself (i'd like to also see an always-on-top option in
every metacity window system menu, but that's another story entirely ^_~)

if you're still with me by now, thanks for listening...

Hmmm, I don't understand this bug really. Between 2.3.something (the
one before 2.4.0) and 2.4.0, the Totem full-screen window (which uses
the _NTE_WM stuff, nicked from gnome-terminal) stopped showing on top
of the panel.

I'd like to know just how I could fix it.

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

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