Is this a dupe of bug 82857?

I don't think so - that bug refers to the implementation of it and how
apps themselves set always on top. This bug asks for a new UI element
so users can toggle it for times when an app doesn't actually set
always on top itself, but the user might want to enable it temporarily.

This is a HIGHLY requested item, but one that was figured a lost cause
to get in Metacity (like the minimize animation toggle), but seeing as
this bug haven't been tagged WONT or CLOSED I can only hope and bump.

there's another open bug for an always on top keybinding. 
I think the keybinding is really the way to go here. The menu 
is out of space, it's officially Too Long if you add more stuff.
Of course you could also support always on top from any external app,
such as a tasklist (which <plug>is trivial to write using libwnck</plug>)

I think the WM is the most obvious place to put this feature, and also
of course not all windows appear in the taskbar.

As for the menu being too long, I think partly that could be
alleviated by putting the "move to desktop" items into a submenu. It's
only 1 level deep, so that's OK usability wise I think. That'd free up
options for other features. 

A keybinding I'd guess would have problems with discoverability.

Created attachment 14437 [details] [review]
Add an always on top menu item and keybinding

OK, so this patch is a first cut at such a feature. A few points to note:

1) Internally the code calls it "always on top", but the menu option
is "float/unfloat". A couple of reasons for that, firstly for some
reason I couldn't persuade GTK to do the obvious thing and expand the
width in the presence of a long name, instead it'd simply hide the
shortcut key. Secondly "Always on top/Not always on top" sounded
pretty awkward to my ear, especially the second. Unfortunately the
menu code doesn't support toggle menu items. I think "Always on top"
is more obvious (esp to ex-windows users) than "Float", but that's
what it is in the patch.

2) The new key doesn't appear in the gnome keyboard shortcuts panel. I
can investigate how to make that happen if it's required for the patch
to be accepted.

3) About the menu being too long: I've given a suggestion above for
how it could be cut down, but even without menu rearrangement in this
case I think it's acceptable to add another option, primarily because
the length of the menu comes from all the "Move to Workspace X"
options - because they are the same, and predictable, you don't need
to scan them when looking for an option you want. There isn't any
extra work for the eye or brain, so the ideas behind the usability
suggestion of keeping short menus don't apply so well here - when
looking for an option all you really need to look at are the top few
items.

As I said before, not having it in the window menu (which is the
standard and obvious place to put it) would just lead people to never
knowing it's there, much like I had to discover alt-rightclick to
bring up the window menu from bugzilla :(

Hm, I think that covers everything. I don't know how good the code is,
most of it was simply copy and paste so it should be ok, but feel free
to rip into it if it's not up to scratch.

It's fine if people never know this exists, because 
any app that really needs to be on top should already be setting 
itself on top. "Always on top" for a generic window is a hack that
very few users will think to use, even if it is in the menu.
People won't understand it if they see it, and it won't occur to them 
to use it once they understand it. The whole concept is much too 
abstract and far from the task or problem they're probably 
dealing with.

Marking PATCH to deal with this, but I only plan to merge the
keybinding part.

That goes back to the assumption that "always on top" is working
around apps that don't set it themselves. 

Ignoring the fact that there apparently isn't a standard way for apps
to mark their windows as always on top anyway, I outline some use
cases in my first comment. Why are these invalid?

Being able to stop a window disappearing underneath another one is
useful for say keeping a chat window on top of a web browser so you
can more easily watch what is being said and type things in without
constantly moving the mouse to the tasklist. It's a generic thing, and
depends a lot on situational factors.

Having a keybinding is ok, but in that case why is ie window shading
worthy of a menu item but not this? I can't see the logic behind it. 

"0, 1, or N" is logical for software, but not for UIs.

Always on top is more abstract than Roll Up for when you'd use 
it, I think. Though Roll Up is also a bit dubious, it does 
have a more visible/physical manifestation that's relatively 
comprehensible.

True enough I guess about it being abstract. Having said that,
assuming a user grasps the basic concepts of windows (stacking them)
then "Always on top" is a fairly intuitive label. In particular, if
somebody enables it not knowing what it is, they'll notice as soon as
they try and switch to another window. 

Roll up is certainly more obvious, but I'd counter that it's also less
useful - I personally almost never use it, and am having a hard time
coming up with use cases for it. So.... well, I agree with the general
ideas behind your "keep it clean, keep it usable" principles, but in
this case I think it's a feature that is useful for a significant
number of people, and isn't working around broken apps, and is
therefore justifiable. 

If the feature was definately a crack feature, then fair enough, but
the line seems a tad blurred in this case.

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

How is this related to "raise-on-click", there was talk of it on the
gnome support discussion boards?

Also, does the HIG say something about keybindings with no GUI element?

Id like to suggest that this feature gets added with an 'always on
bottom' or 'sink' feature. I agree it is more of a 'crack' function
then always on top, but:
1) It is a good compliment to the always on top, so you can have 3
states: ontop/normal/onbottom
2) It is particularly useful if you want to put background moniters,
or an app that will basicly sit on the desktop. f.e. Gkrellm, or a
terminal running with top, or other simmilar examples.

Thank you.

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

10 not so geeky use-cases for always on top:

1.  Watching music videos.  I watch a lot of music videos and I like
to do other things like surf the net or check my email meanwhile.

2.  Listening to oggs/mp3s.  It's nice to have xmms (or equivalent) on
top so it's easy to change songs, see what's playing, see status etc.

3.  Using the calculator (as already mentioned).  The only time I ever
use the calculator on the computer is when I'm in the middle of taxes,
finances, a report, etc. and have a bunch of stuff open.  I almost
always am switching between apps and want the calculator on top.

4.  Using any of the multi-window apps like the gimp, sodipodi, glade,
 dia, etc.  These are great apps that are widely used but they become
nearly useless when you have to juggle 4 or 5 dialogs and the taskbar
icons get smaller and smaller.  I always have to search for the main
menu or pallet menu and it is annoying and time consuming.

5.  When writing a paper.  There are a bzillion examples of when this
is useful when you're trying to create a document with multiple
sources.  The 2 main ways I used to use this (when I was using
sawfish) are: a) to have a couple of mozilla windows on top with my
sources and to be writing in the wordprocessor below  b) if I'm just
gathering info I'll put a gedit window on top and then cut n paste
from mozilla below. I tend to use at least a couple mozilla tabs at a
time so I can do something else well a page is loading, not having to
keep popping the gedit window back up for reference or to cut n paste
into saves lots of time and frustration.

6.  Using any sort of status utility like gkrellm or enlightenments
thingy.  I like gkrellm but it's sort of silly to run it if I can
never see it.

7.  Sorting files.  When using a drag and drop file manager app like
nautilus I like to open 3 or 4 windows so I don't have to keep going
up and down through folders.  It's annoying to have the window you're
copying from to keep getting covered up.  Especially if you're using
icon view.  Even in list view you have to manipulate the other windows
so they don't cover the part of the screen you need to copy from. 
This is a common situation, especially for p2p folks.

8.  Using terminals.  I don't need to list the bzillion times we all
want our terminals to stay on top.

9.  Using xcdroast (or equivalent cd burning app).  I like to keep an
eye on the small burn status window when a burn is in progress so I
can watch the software and hardware buffer.  I don't like buffer
underruns too much.

10.  Using an instant messenger of any sort.


Now I must admit I'm partial to the always on top option more than a
brand new user as I'm used to having it (from the sawfish days). 
However, these are not obscure use-cases.  Save for terminals, this is
stuff newbies want to do.  I help a lot of people into the linux
world, most of them use their computer to write papers, use instant
messenging, and to download and listen to music.  That's about it but
always on top applies to all of these cases.  They always get
frustrated and say 'agh, why does this window keep getting covered
up!'.  They don't get mad at the window manager obviously but they get
frustrated and I used to be able to say, "oh, if you want this to stay
on top, do this".

The phrase 'always on top' makes sense to people in my experience,
even my mom understood it as soon as I said it (she still uses sawfish).

I really think it's strange that a feature that is requested so much
is being locked out.  The appeals to UI standards seem weak to me and
to say that it's too cluttered to add something that people really
want is silly too.  Why not get rid of less useful stuff if that's the
case?  I've never met anyone that uses shading, ever.  If we're
talking about appealing to newbies, honestly how many newbies do you
know that quickly embrace multiple workspaces?  None.  It's a
confusing concept and usually people hate it.  "I was working and then
all my applications dissapeared but I didn't do anything and it looks
like linux is still working and my mp3's are still playing! What's
going on!".  Seriously, completely axe all the workspace stuff if your
interested in reducing complexity. Even if there was an obscure
setting somewhere, maybe 'always on top' and all that workspace crap
could only show up in the right-click menu if a 'show advanced
options' toggle was set in metacity setup or something.

Anyway that's my rant.  It's the single complaint I have about
metacity but a really important one (and I've had it ever since I
started using metacity months ago).  Especially cause there has been
no good arguments against doing it and the code is already there.   
Regardless, this issue isn't going to go away because people simply
really, really want it.  I think it needs to be dealt with for real.

The patch here should be using window->wm_state_above instead of 
creating a new flag. (wm_state_above may not have existed when 
the patch was written.)

I don't think "float" and "unfloat" are good names, "always on top" 
seems better to me.

The patch should save always on top state in the session, 
or at least we should file a bug to do that later.
However there are versioning problems (breaking old 
versions of metacity using same session file)

Re: the UI issue of whether to have this at all - 

To add always on top we would need:
 - to decide on the name
 - a default keyboard shortcut for Always On Top
 - a name for the menu item when the window is already on top
   ("Un-Always On Top")

The caveats in my view are:
 - it encourages application authors to fail to set this 
   hint (or other hints such as fullscreen) on their 
   own/automagically, when they should be setting it
 - it could lead to users sitting there trying to get 
   another window above the always on top window, 
   going "dammit!"
 - maybe something else should be in the menu instead
   that would be more useful; have we thought 
   through other stuff? We can't add N items here, 
   1 more is already pushing it.
 - we still don't have good window history, and when 
   people are using always on top as a hackaround for 
   app authors not setting it automagically, 
   you would want window history. On the plus side, 
   you probably don't need history for the use-cases
   that are more legitimate, like "keep this document 
   on top for reference". Anyhow, see bug #91481
 - having always on top will make bug #97635
   far more visible (whenever you return to a 
   workspace with an always on top window, the 
   always on top window will be focused)

And no <aol> or rant comments please, or the real discussion gets 
buried. That just slows things down.

> The patch here should be using window->wm_state_above instead of 
> creating a new flag. (wm_state_above may not have existed when 
> the patch was written.)

I don't recall such a variable, but I wrote the patch some time ago now.

> I don't think "float" and "unfloat" are good names, "always on top" 
> seems better to me.

Agreed, but for some reason I never discovered GTK wouldn't grow the
width of the menu, instead it would simply refuse to render the menu
item completely. Well, that's my excuse :) I didn't have time to debug
it, and I had little GTK experience back then, so easier to change the
label.

> The patch should save always on top state in the session, 
> or at least we should file a bug to do that later.

Yes, perhaps, but for the use cases I had in mind for this feature it
would be a temporary thing. I'm not sure you'd want it to be enabled
permenantly for a window. But I suppose it wouldn't hurt, and some
people would just assume it'd work and get confused when it didn't.

> The caveats in my view are:
> - it encourages application authors to fail to set this 
>   hint (or other hints such as fullscreen) on their 
>   own/automagically, when they should be setting it

Perhaps, but I'm not completely convinced that inside the app is the
best place to decide the always-on-top status of a window anyway. It
would seem to be too dependant upon the state of the desktop - I can't
think of many times an app would want to force a window to the top,
it's more a user decision.

Not saying this isn't a valid concern, it is, but it's the magic part
of automagic which concerns me.

> - it could lead to users sitting there trying to get 
>   another window above the always on top window, 
>   going "dammit!"

Only if they set it in the first place, although it's conceivable a
user could switch it on and then not be able to switch it off again,
the same argument could apply to say window shading or virtual
desktops. If anything this is more likely to happen with apps that set
the state themselves.

> - maybe something else should be in the menu instead
>   that would be more useful; have we thought 
>   through other stuff? We can't add N items here, 
>   1 more is already pushing it

Certainly the line must be drawn somewhere, it's essentially your call
exactly where that is. I personally think always on top should fall
inside the line, but that's just my humble opinion. Specific examples
of what other functionality this would exclude might be useful.

>  - we still don't have good window history

I don't really understand what window history is, but I don't think
the primary use for this would be working around broken apps - there
just are not that many apps that would legitimately set it anyway.

> - having always on top will make bug #97635
>   far more visible

*shrug* don't think that's all that relevant personally, bugs should
be fixed, but I'm busy with adding support for all these lovely hints
to Wine anyway so I won't be producing a patch for 97635 any time soon.

thanks -mike

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

Names: Escalate/De-Escalate  Hover/Lower  Float/Lower  Float/Sink

None are ideal but I'm not sure english contains a more suitable word
pair.  Although we're not really 'lowering' or 'sinking' the window I
think 'lower' or 'sink' is consistent with the metaphor of the window
hovering above or floating on top of the others.  If a user
accidentally hit 'Float' for a particular window and was frustrated
that they couldn't get other windows over top of it, I think most
would easily identify that lower or sink would be the option that
would do what they wanted.  "Always on top / Not always on top" are
super clear I think and would be ideal if they weren't such long phrases.

I have to agree with Havoc here. We shouldn't have an "Always on Top"
in the titlebar menu. It's just extra clutter that 99.9% of the people
won't use anyway. If an app needs to be on top, it should have that
option itself, or should just be doing it anyway. If you want random
normal apps to always be always on top between sessions, one leet
hax0r should probably be using something like Devil's Pie to do the
matched window things.

Created attachment 17149 [details] [review]
up-to-date patch implementing keybinding only

I think that the right solution here is to use a keybinding with no
default setting, and no menu item, since this is really an "advanced
users" feature and I doubt most users will want/need this.

The attached patch is semi-based on the other patch on this bug, but
uses the latest and greatest API.

One note: the meta_window_raise on (un)make_above is needed to avoid
the case where turning off the always on top state makes the window
suddenly vanish behind other windows in sloppy or mouse focus.

Just for the record, opposing argument is:

Apps can't realistically know when they should be on top or not, as it
depends entirely on the state of the desktop, ie on other apps. So,
what you would get is apps randomly having this feature or not, and
when they had it, in an inconsistant manner. Therefore the place that
this makes the most sense is in the WM.

Now, as to whether it makes the window menu cluttered, well, I don't
really know. It's used rarely enough that I think it matters little
either way. Pure keybinding has discoverability problems, as I've said
before, it would mean in practice users would have to be told about
the keybinding. It would also mean if they accidentally hit it, they
are shafted - they won't know what they did, nor how to disable it as
there is no visual indication of the sticky state.

Having said all that, I've kind of lost interest in this bug. Do with
it what you want.

The keybinding is unbound by default so a user would have a lot of
trouble hitting it accidentally, since they'd have to accidentally
open gconf-editor, accidentally navigate to the key, accidentally type
in a binding, and then accidentally hit that binding.

But honestly, this is a power-user option with, I think, real,
demonstrated use cases.  Which is why I think that it makes sense to
make this into a keybinding only unbound by default.  This also has
the advantage that application authors aren't going to omit the
feature because "the WM can do it" since we're making it such a pain
in the ass to get the WM to do it.

What do you think, Havoc?  OK to commit?

Created attachment 17621 [details] [review]
menuitem only, without keybinding, using window->wm_state_above.

My patch have two problems:
 1. Splash on focusing hinder window after setting always above.
 2. The window cover up the panel.
    And the panel cover up the window on mouseOver.

And, if hp don't like to accept this feature is useful,
would you please let us know how to set _NET_WM_STATE_ABOVE
from external utility like xprop?

I've tried xprop -set _NET_WM_STATE with cases of value
but failed always.

ok well we now have a patch implementing every combinatorial
possiblity here.  Let's pick one.

Rob why not go ahead and commit the keybinding-only patch, I think 
we clearly want to do that one at least.
It looks like you had an accidental change to the <default> for 
toggle_maximized in .schemas, be sure to clean that up.

OK committed the toggle_above keybinding patch.  I guess I'll leave
the bug open, though I must admit closing it seems awfully tempting...

I think that unless someone posts some compelling argument for why we
should add a menu item in the next couple days I will just go ahead
and close it.

Discoverability?

I do hereby declare this bug resolved.

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

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

Hehe, in which metacity version this bug is fixed and I can make some
applications on top of other (at least) ?

I compiled latest version from ftp.gnome.org - 2.6.3 but I don't see
any menu item :(

read the bug comments, dude.  And don't reopen bugs without a damn
good reason.

Hmm, just as a (maybe off-topic) sidenote: we still have N menu
entries for "Move to Workspace X" which could be easily de-cluttered
by having "Move to another Workspace" and a submenu containing entries
for the workspaces. This would give us ample space for a "Put on top"
menu entry. This could be hidden if not activated by a GConf flag.

Would code that implements this be considered or should I not bother?

Please see Bug 110904 for discussion on reorganizing the window menu.
 Though I don't see an "always on top" ever making it in there, unless
a solid argument is made as to why it increases usability.

I will argue for this feature again, as I've not been convinced by any
of the arguments against it put forward so far.

"This also has the advantage that application authors aren't going to
omit the feature because 'the WM can do it' since we're making it such
a pain in the ass to get the WM to do it."

To me this argument makes no sense. Always on top is about controlling
window position and stacking. The user, not the app, controls every
other aspect of this, with good reason - only they can know how they
want their desktop arranged. If always-on-top has to be activated in
the app, why not maximize as well? Why not close?

Of course there are good reasons we have these functions in the WM:

* Consistancy. If Close was controlled by the app, it'd end up in many
different locations that the user could not predict - just like always
on top has done. Some apps put it in preferences, some in "View", some
don't bother and then the user is screwed if they want to do that etc

* Discoverability. Clicking the button or icon is a fairly direct way
to access the window management functions

* Simplicity for app developers. If each developer has to reimplement
the maximize/minimize control/ui code, some of them will get it wrong.
Better to write that code once and have it work every time.

* There are a very large number of use cases. It's not practical to
expect every app to have "always on top" in every combination, and it
would just lead to an even worse UI if we did.

Why is an unbound keybinding bad? Basically really poor
discoverability. Even if we work on the assumption that always-on-top
is a power user feature (though I don't think it is), discoverability
is still a problem for power users. How many power users know that
Windows command.com can do tab completion? Not many, and the reason is
because it's off by default and buried in the registry, meaning most
people never know about it.

Why is always-on-top not a power user feature?

It's not a power user feature because it's as basic as being able to
move windows around, between virtual desktops, being able to minimzize
and maximimize them. It's about being able to lay out your workspace
in the way that works best for you. It has virtually no cost, yet it's
often useful and I've already given a variety of use cases. These use
cases are not exclusive to power users - things like floating chat
windows while reading a web page are using the same apps and doing the
same tasks that my mother does.

Finally, why should it go on the menu? Because:

* If each menu item for the workspace were put in a submenu, it would
no longer be too long. 
* The cost/benefit analysis is in my view favourable. Given the amount
of frustration it can save people from, a tiny loss in efficiency in
scanning the window menu is a small price to pay indeed.
* If it's not in the menu, almost nobody will be able to find it.

thanks -mike

always on top is not really a fundamental window operation like
maximize, or resize; it's in fact exceedingly rare that an application
would ever need to be always on top.  In fact I can't really think of
a case where an app should be always on top.  (There are a couple of
corner cases like drag and drop, but we should fix those rather than
adding an "always on top" menu item as a workaround)  It's just not
something that a lot of people are going to want to be doing.  And as
for the lack of discoverability: there's two sides to that coin.  When
something is easily "discoverable", then it's also easy to
accidentally turn it on and not know how to get rid of it.

I do think that the keybinding should be configurable in
control-center though, and not just in gconf-editor.  Someone should
implement that.

It is not a matter of "which application does need to be on top" but
"what application does the user want to put on top". This virtually
can be any application, depending on the user's state of mind ;-) --
xload, videos, chat windows, realtime logging, you name it.

For the sake of the argument let's assume that only 1% of the users (a
hypothetical value -- if we want real hard numbers, we should ask the
users) would use this functionality. I guess that this would still be
a huge absolute number and not only 20 or 30 people.

I would agree that you can see this as a power user feature, but if a
user discovered a "Put this Window on Top" menu item and enabled it,
wouldn't he remember where to disable it in the event he wants to? I
do think so. After all, this weren't an icon somewhere on the window
frame, but an entry in the menu containing all window operations. Hard
to not look there for it, if you ask me ;-).

To save the uninitiated from accidentally clicking on it and not
knowing how to undo this, we still can make this configurable --
whether in control-center or only through GConf I personally don't
care (I will find it), as long as I don't have to recompile stuff. And
I think a window menu item makes sense because admittedly I don't use
it every day, but rather every other week or so and it's hard to
remember keyboard short cuts you don't use regularly.

I need "Always on top" control menu item when I am doing calculations
with the data from other windows using the calcullator.

I need "Always on top" TV-tuner window when I am watching TV and doing
something else in the same time.

Sometimes it would be useful to declare some window "Always on top"
when copying files betwen windows.

Please, include "Always on top" into this menu. 

We can discouse also a possibillity to assign every window to some
layer for organising more levels of windows apearence.

Please include "Always on top" item in window menu. 

I like to have this feature because I like to have a small xchat 
window runing on top of other windows. What is more the ability to use
calculator without switching between windows is a need. My friends are
always complaining about how it would be great to use gnomemeeting
without pressing alt-tab all the time.

This item should be marked with tick. If the window is on top then the
tick should be present and vice versa.

Developers don't be ignorant to users and include this simple but
useful function. And don't make your own decisions what is useful for
users and what is not. Let decide them.

Rob Adams <readams@hmc.edu>:
> And don't reopen bugs without a damn good reason.

the summary of this bug is a damn good reason:
 [patch] Always on top control menu item

this means:
1. RESOLUTION can't be set to FIXED while there is no Always on top
control menu item

2. patch for this bug is available and lots of people want this patch
to be checked in, so this bug should be FIXED only when patch is
checked in.

Btw, I see lots of duplicates of this bug, also many people are
telling lots of good reasons to add Always on top control menu item
but 2 intransigent Gnome developers don't like to accept work of
others and don't hear users opinion :(

Btw2 - I know lots of people, who use sawfish instead of metacity only
because of "Always On Top" menu item.

there's always a vocal minority in support of adding little features
like this; the problem is that we simply can't add every possible
little feature into the window menu.  The argument that there are a
few people who might find it slightly more convenient to have an
"Always on Top" toggle in the window menu is not sufficient, since
otherwise we'd have 50 things in there.

The whole point of metacity is to be a simple window manager that's
easy to use for everyone.  It should do the right thing out of the
box.  _STATE_ABOVE is an application-specific thing; there are
specific application that ought to support it, which is why it's in
the spec.  But these applications can make this support largely
user-transparent, without having to force the user to engage a feature
of the window manager that they may or may not even know about in
order to get it to do the right thing.  We want the application to do
the right thing on its own.  Having a toggle in the window manager can
only be described as a workaround; and an obscure one at that.  I
don't think that having "Unbreak my application" in the window menu is
appropriate.

FWIW, the "vocal minority/ui bloat" argument is a convincing one. I
don't think anybody here disagrees with it. So the problem here is
that some people believe having the app decide always-on-top state is
broken, and some (you) believe that having it NOT decide is broken.

So the question is not "is always-on-top a power user feature", or
even "does it belong in the menu" - the question is really "which
program should decide always-on-top state, the app or the WM".

I believe, as do quite a few others it seems, that this decision is
fundamentally about window management just as much as position,
virtual desktop, rollup state etc is. There's no reason why the app
can decide this better than the WM can, in fact, there are many
reasons why it often can't.

"_STATE_ABOVE is an application-specific thing; there are
specific application that ought to support it, which is why it's in
the spec"

I think this is a problem - clearly sometimes an app *can* decide a
window should be always-on-top by default, and so having _STATE_ABOVE
is a good thing. Often though it's *not* something the app can decide,
 but only the user. The logical conclusion is to allow both, hence
this patch.

Please tell me which part of this reasoning is flawed, and why.

Um. What you (Rob) say may be applicable to _some_ applications (which
should deal with putting themselves on top or not), but the points we
(the vocal minority if you wish) are trying to get across (and
seemingly fail to do) is:

- To work (or play) productively, we want to be able to organize our
windows in several layers (two -- normal and "on top" -- is a good
start ;-).
- We don't think that this should be limited to a certain set of
applications -- as we have seen above there is quite a number of very
different candidate apps.
- We see stacking as another dimension in which to organize windows
(additional to x pos, y pos, width, height).
- We (at least I) are willing to put time/code behind it, maybe even
to hide this behind a GConf key that is switched off by default -- by
all means make the default right for 95% of the people, but don't
hardcode the default in the source unless you have a very compelling
reason to do so. I mean we are not talking about something that might
damage your hardware if enabled.

I thought there was some other bug with discussion of this menu item
where I was considering adding it... I believe we were considering
replacing "Roll Up" with an "On Top" menu item.

I'm inclined to think On Top is more useful in the menus than Roll Up,
but I have one big worry about On Top: on multiple occasions I've had
it on and then sat there for a while trying to figure out why I
couldn't focus some other window (clicking it in the window list, and
it would not come up above the on top window).

There are a several possible solutions I think, and maybe we should do
them all:

 1. create an invariant that maximized/fullscreen windows can't be 
    on top

 2. have some feature where if you click the titlebar of the focused
    window a second time, the on top windows lose their on topness;
    OR the focused window becomes on top iff there are on top windows
    if you click the titlebar again

 3. have some visual distinction between regular and on top windows;
    the easiest one to imagine is a deeper drop shadow, but we can't 
    implement that yet; maybe on top windows could have some sort of 
    arrow or something in the titlebar? I don't know. 

Yes, those approaches all sound good. I especially like the click
twice on the titlebar idea.

As for visual distinction, perhaps a new button next to the usual 3
that makes a window not on top anymore? I'm not suggesting a button to
toggle ontopness, just one to switch it off.

To give user ability to organize windows in several levels - this is
one of the main features of windows interface. (I do not agree, that
always-on-top would by a "little feature".)

"Always-on-top" could be combined with "Always-in-back". Putting
window in back sometimes could be useful by dragging objects between
windows. I am sure, users would inventive apply this feature for own
comfort.

About new buttons next to usual 3 window buttons: I would suggest in
the next version to make these new buttons on every window for make
all user know about this feature. In the next version could be created
some system, deciding if the [top], [back] buttons must be presented. 

Suggested ideas for the appearance of these buttons: [<] [o] [>] or
[v] [-] [^].

I'm reopening this bug again, because of summary. We should add
"Always on Top" to window menu or change bug summary before marking
this bug as FIXED.

Btw, If you remove "Roll Up" from window menu, this function should be
available in gnome-control center - many users use double click on
window header for roll up.

Thanks,
Mantas Kriauciunas

For christ's sake: Bug 123162.  Things are the way they are for a reason.