To sum up: those behaviours should be selectable in the "Windows" preferences
window and the "Open centered in the desktop" option should be added/implemented.

We don't want to add 1000 placement algorithms, though if you want to look at
the current one and suggest improvements that's helpful. Note that the current
one does center things in certain cases (try opening a window wider than 1/2 the
screen on an empty desktop for example)

Anyhow, there's a policy decision to avoid a config option here. Search for
"placement" in ChangeLog for various other bugs with discussion.

Yes, I know the first window on a empty desktop gets centered. But I think next
opened windows should be centered aswell. If you don't want to clutter the
preferences window, that option could be placed as a gconf key. One thing is
keeping it simple and the other not allowing the user to get the behaviour he wants.

In a lot of WM things work this way, that's why I think it should be an option
in metacity.

If a gconf option is not thought to be implemented, at last the behaviour of
locating the windows at the very edges of the desktop should be avoided, as it
forces the user to move the mouse more that what would be aceptable. Windows
should be placed a bit to the sides when another one is centered, but not in the
exact edge as now does.

If I'm not explaining myself with clarity, I'd suggest you to have a look to the
behaviour of other WMs, i.e. Fluxbox.

I wonder if some kind of "generations" feature would be useful, where each time
there's no space for a new window, rather than cascade the "center tile"
algorithm just resets ignoring the existing windows.

But that might suck also, and I'm not sure how to implement it.

I don't want to enter in too complicated algoritms, as I'm not a developer; I
know you will do it much better than I could think here. But I'll give an
example of what I want to change: I have an Epiphany window opened, maximized,
using all the desktop. Then I opened a Gnome Dictionary window and... it opened
in the top left corner. I had to move it by hand to the center and then type the
word I wanted to search...

What I want to explain, is that IMHO the natural position of new opened windows
is near-centered. There is where the cursor is most of the time, and is easier
to move a window from the center to a side, if you want (but if you opened a new
window, 99% of the time you'll start working in that window, so you won't move
it anyway) than moving the cursor to a side, and bring the window to the center.
And that with each window you open. Every day... is frustating.

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

Hi. This comes from Bug 304763, that as been marked as duplicate of this
(center-windows placement policy). In that thread, Chad Glendenin has developed
a patch that centers windows, and it works great ;-).

I've read some related threads (Bug 106239, Bug 155460, Bug 126792), and I can
see that the key point in the current placement policy is:

  * only one policy please

Well, I have to say that I disagree in that point.

Certainly, we can't repond to the millions of possible preferences of the users.
"We don't want to add 1000 placement algorithms", that's right. But, do we want
only one? Why only one? 90% of users want current policy? My opinion is that, if
40% of users want the current policy, and 40% of users want center-windows
policy, then both policies should be offered.

Another idea. I think that both policies (current and centered) are not
compatible, i.e., centered policy can't be integrated into current policy,
because the key in the current policy is "avoid overlapping" (so an algorithm is
needed), and the key in centered policy is "center, always overlap" (so no
algorithm is needed).

Well, they're some ideas for the debate. I hope that we can obtain good
conclusions, and that, as MaxDamage says, we be able to avoid the frustration to
a big amount of users.

Any comments/ideas/debate?

There are about a zillion placement algorithms and variations on them that
people ask for, but the reality in my view is not the 40%/40% you are talking
about, but more like 95% are happy with anything reasonable and then 0.5% want
option A, .5% want B, .5% want C, .5% want D, .5% want E, and so forth.

So the goal is to make the default algorithm handle all the wacky cases (such as
huge xinerama, etc.) automatically, and then if people really want to experiment
with other approaches they can hack the source code.

But we don't have the time to maintain 20 different placement modes, and I see
no evidence that any of them are particularly more in demand than any of the others.

http://ometer.com/features.html

I do think there's a worthwhile discussion about whether the "give up" mode of
the current algorithm should be top-left cascade. 

The current algorithm tries to avoid overlaps and center a tiled group of
windows; but if there's no way to avoid an overlap it switches to the top-left
cascade.
Maybe if there's no way to avoid an overlap it should center, or cascade from
the center, or something.

My two cents (since I've been named here): I think Metacity's "give-up mode" has
at least two problems that are more than just subjective user preference:

-- Problem 1: Desktop icon occlusion.

Nautilus, by default, places icons on the desktop starting from the upper-left
corner. Metacity, after doing the center/tile thing and running out of space,
places new windows in the upper-left corner of the workspace. As a result,
desktop icons soon become occluded. Once occluded, either they are useless
because they are inaccessible, or else the user is forced to move the
newly-placed window manually, which I think is evidence that Metacity should not
have placed that window there in the first place. (A third choice is to access
the icons through the Places menu, but at that point they aren't really desktop
icons any more.)

My own experience with this problem is that all my desktop icons are occluded
almost immediately after starting my GNOME session, because the first thing I do
is to open large Firefox and Thunderbird windows, after which Metacity gives up
and cascades every subsequent window.

-- Problem 2: Tightly packed, overlapping windows.

With the center/tile algorithm, it looks like Metacity is trying to avoid piling
windows on top of each other too tightly. This makes sense, because with the
windows spread out, the user can see window contents and have large targets to
hit with the mouse without manually rearranging windows. However, the fallback
cascading algorithm is doing the opposite; it's trying to pack all new windows
tightly into one corner of the screen.

Furthermore, after center_tile fails, Metacity is annoyingly persistent in its
attempts to pile up windows at the upper-left corner. Rather than having, say, a
static variable to keep track of the next cascade position to choose, Metacity
essentially searches for the free space closest to the upper-left corner in
which to place a new window.

I have a couple suggestions for solving these problems.

-- Solution 1: Better cascading.

One improvement could be to have find_next_cascade() spread out the cascaded
windows by more pixels horizontally and vertically, rather than trying to place
the new frame at the origin of the previous window, as it does currently.
Cascading could have a minimum horizontal and vertical offset in pixels, which
should be at least many pixels as the height of the titlebar in the current
theme's window frame.

Another possibility is to replace the search with either a global or a
per-screen memory of the previously chosen cascade position, so that windows
would be cascaded sequentially.

-- Solution 2: Avoid placing windows directly above desktop icons.

Metacity and Nautilus could communicate so that Metacity could try its best to
avoid occluding desktop icons. Since the user can fill the entire desktop with
icons, there is always a potential occlusion problem, but if, for example, the
user only has a few icons along the left edge of the screen, then Metacity could
simply start its cascade algorithm offset from the left edge by icon_width pixels.

However, this seem like potentially a very complicated solution to a relatively
minor problem. A simpler solution that might have some occlusion-avoiding
benefits without a lot of complexity would be to combine this with new cascading
behavior. For example, the first cascade position could be preset to some offset
away from the left edge of the screen, like N pixels, or one quarter of the
workspace-width, or some distance based on a hint from Nautilus.

Thanks,
ccg

Havoc Pennington wrote:

> There are about a zillion placement algorithms and variations on them 
> that people ask for, but the reality in my view is not the 40%/40% you
> are talking about, but more like 95% are happy with anything reasonable
> and then 0.5% want option A, .5% want B, .5% want C, .5% want D, .5%
> want E, and so forth.

Do you mean 95% prefer current policy (that is the "reasonable" option) and 0.5%
prefer centered policy (that is one of the "unreasonable" options)?

I wasn't saying alternate policies were unreasonable and current one is
reasonable. I'm saying most people just aren't that picky and are happy with
anything that is reasonable, and then there are 0.5%-ish small groups that feel
they really must have some specific behavior. (Said specific behavior may also
be reasonable.) But sometimes implementing all possible reasonable behaviors is
not in the aggregate a reasonable thing to do ;-)

One thing I forgot to mention in the previous comment: I would argue that some
sort of cascade algorithm is a better fall-back than simple centering because of
the stacking problem. Imagine opening four identical xterm windows. With
cascade, they will be placed at different locations on the screen, allowing the
user to select one by clicking on it directly. However, if each xterm window is
centered, then they will all be placed at the same screen location, completely
overlapping each other, and the only way to select one from the stack is to use
a different widget (taskbar, menu, etc.) or manually move the top xterm away
from the others in the stack.

Sorry about the length of the previous screed, but I'd like to know where the
developers are planning to go with this before I spend any more time hacking
Metacity. Is there a discussion on this going on someplace else?

Thanks. --ccg

we can probably make this a lot better by simply changing the cascade origin to
like 50,50 instead of 0,0.  That should be like a 1-line patch.

I'm going to have to disagree with your arguing for a cascade algorithm.  Think
back to what you just said: "Imagine opening four identical xterm windows".  You
are imagining opening several applications without using any of them between
launches.  There are times that users do that (including me), but I don't
believe it's the common case.  Besides, it's not that difficult to move other
windows out of the way in the rare cases were one might want to do this.  The
majority of the time, when the user launches an application they intend to make
use of it.

I believe our cascading optimizes for
open-lots-of-windows-with-no-intervening-interaction use case, which happens to
be highly suboptimal for the open-a-window-and-start-using-it use case.  I feel
the latter is far more common (if it isn't, then I don't see why we focus new
windows by default; it seems the default should be the opposite for the open
many windows case[1]).

Just my $0.02.

[1] In fact, others have requested not focusing new windows at all on the exact
grounds that they were the weird kind of user that opens lots of applications
without using any until several were launched.  We denied it on the grounds that
users launch applications so that they can use them right away.

I'm not sure I understand where we disagree. I'm suggesting that Metacity's
find_next_cascade() fallback behavior could be improved, and that improved
cascading would be a better fallback behavior than simple centering. I only
picked the four-xterm thing as an obvious case where centering causes immediate
and complete occlusion of window N by window N+1.

Just to be clear, I'm *not* suggesting replacing the default
center_tile_rect_in_area() behavior; I'm only suggesting improving the fallback
behavior.

I don't think that the intervening time between opening windows is really an
issue. The issue is avoiding window occlusion and giving the user a larger
target to hit with the mouse without requiring manual interaction with the
window manager.

Here are the assumptions I'm making on this:

1.) Window occlusion is mostly bad.
2.) The user should have to manually arrange windows as infrequently as possible.
3.) Cascading is a decent way to avoid some occlusion when center/tile cannot
place a window.

Because center/tile is the default, I suspect we agree on #1, and probably #2.
If not, please let me know.

#3 is certainly debatable. Cascading helps window N avoid being completely
occluded by window N+1, but beyond that -- especially when the cascade algorithm
is interacting with the center/tile algorithm -- it's harder to say how helpful
it will be. Spreading the windows out more while cascading them will keep the
cascaded windows from overlapping each other as much as they do now, but it will
probably also cause more overlap between the cascaded windows and the
center/tiled windows.

Maybe what this comes down to is how often the fallback behavior is needed. Is
there existing empirical data on what happens in the common case?

Should patches for experimenting with the fallback mode be posted here? This
seems to have drifted away from the original topic of centered window placement.

Havoc Pennington wrote:

> I wasn't saying alternate policies were unreasonable and current one is
> reasonable. I'm saying most people just aren't that picky and are happy
> with anything that is reasonable, and then there are 0.5%-ish small
> groups that feel they really must have some specific behavior. (Said
> specific behavior may also be reasonable.) But sometimes implementing
> all possible reasonable behaviors is not in the aggregate a reasonable
> thing to do ;-)

Ok. So, if most people like any reasonable thing, and there're only 0.5%-ish
small groups that prefer a specific policy, how was the policy_to_use choosen?

> Should patches for experimenting with the fallback mode be posted here?

That makes sense to me.

> how was the policy_to_use choosen?

By trying to figure out a good one. See the discussion here for example.
The default policy has changed a lot over time.

Havoc Pennington wrote:

> The default policy has changed a lot over time.

The "default" one? I think you mean the *only* policy has changed.

Well, after knowing your view, I'll try yo explain my view. I think that
software should do what user want, not what developers want users want. You say
that the placement policy does not matter to 95% of users. I'm not so sure. In
fact I would say that, for any software and for any behabiour, 95% will make a
choose. People always prefer one option when they can choose. And developers
must give the most demanded options.

You say all options are equally demanded. I'm not so sure. I've made a search in
this bugzilla, and I've only found one demanded option, "center windows" (Bug
304763 and Bug 151818). Supposing that bugzilla entries are proportional to the
demanded options, and having in mind that only a little percentage of users make
petitions, we can suppose that there are a big group of users that prefer other
behabiour.

Is that group sufficiently big to add a new behabiour? We'd need a poll to be
sure, but we can do some reasoning. For example, is that group more little than
the group of users that prefer to "Select windows when the mouse moves over
them" (it's an available option in metacity)? Is more little than the group that
prefer "Raise selected windows after an interval", or than the group that prefer
"Double-click titlebar to roll up the window", or than the group that prefer to
"Move a window with Windows Super key"?

Sincerely, I think not.

Chad: Sorry for the slow response, and yeah, I think you may be right that we're
kind of going at the same thing from just slightly different angles.  I'm also
only talking about the fallback behavior, though I have different assumptions:

1) There are multiple factors to consider in a usability placement (I'll ignore
many of them here, but I point it out because I think we sometimes pigeonhole on
too few factors)

2) The fallback behavior should be aimed at the most common use case

3) Predictability of window placement is important

Neither of us have suggested anything that would cut down on predictability, but
I mention it because others have when talking about placement algorithms.  I've
seen others (Havoc and Rob, I think) argue that this is the most important point
in placement of windows, and it seems to make sense to me--though a couple bug
reports suggest there are special cases when we might be willing to sacrifice a
little of this if we can gain enough of one of the other desired features.

4) We should minimize the work needed for users to manually move a new window.

I think that this is the second most important point; we can't remove all manual
rearrangement that users do without a libmindread module ;-) but we should try
to minimize it.  This is similar to one of your points, though subtly different.
 See also bug 106239 ("what about HUGE screens?") though "placing near the
mouse" could come at the expense of predictability (e.g. if the user happens to
be using the mouse at the time the window happens to be ready to be placed then
the window weirdly pops up near where the mouse was part way through the mouse
movement).

5) Avoiding window occlusion is desirable.  However, it's not really possible
once we've hit the fallback behavior; we can only try to reduce it in certain cases.

This is why I think we try to tile windows so they don't overlap if possible; it
meets all the needed and desireable criteria (for single monitor setups
anyway...).  However, once we hit the point where overlap is necessary, trying
to avoid occlusion merely means deciding how to reduce it (e.g. having launched
window N+1 not occlude launced window N (even if windows 1 through N-1 were more
recently used than N?); or trying to minimize the number of fully occluded
windows, or trying to minimize the total occluded area of all windows, or trying
to minimize the total occluded area of windows that we decide to leave at least
partially visible), all of which have dubious effect at some point.

6) Common behavior for users is to launch one application and then use it

I think this is important and often overlooked.  To understand why this is true
(I'll explain why it's important below), think about what we do with new windows
by default: we focus them.  If we didn't expect the user to use the window right
away, why would we focus it?

7) Minimizing occlusion, as we currently do in the fallback comes at the expense
of minimizing window movement, which I think is backwards.

When a window pops up in the upper left corner of the desktop, someone working
in the lower right has to move their mouse across the whole desktop to get to
the window, then drag it all the way back.  Placing in the center would reduce
the amount of movement necessary; there may be other ways to also reduce the
amount of window movement (e.g. place the window near the mouse as in bug 106239).

8) Additional rationale on why we may want to have minimizing window movement
trump avoiding occlusion:

Our current non-fallback behavior will place windows on a xinerama ("monitor")
that the mouse pointer is currently not on if that xinerama has room but the
active one does not.  I.e. we allow avoiding occlusion to trump minimizing
window movement.  However, many users have complained about this and in both bug
106239 and bug 145503 Havoc argues that this is wrong (I believe he may have
said the same thing in other bugs as well).  Note though, that placing on the
current xinerama can be problematic for predictability (though fairly
minimially) because it is possible that the user happens to be moving the mouse
from one xinerama to the next during application launch.

There is a case where I believe it would be more useful to the user to avoid
occlusion than to minimize window movement, namely the "launch N windows" use
case.  In fact, this exact case is often brought up and given heavy
consideration, while (6) appears to be ignored.  I think that's backwards
because I don't think "launch N windows" is the common use case for most users.
 I feel weird saying that because I spend more time in a terminal than any other
app (other than perhaps emacs) and I am one of the people that often uses this
edge/corner case--but just as with orthogonal raise I've come to the conclusion
that I'm the weirdo.  Now, if "launch N windows" was the common use case, I
think we should revisit our policy of focusing new windows by default--because
in such cases, the user does not intend to use such windows yet but would rather
keep interacting with whatever app they were using in order to launch such
windows.  In other words, if we want to design for "launch N windows" then we
should not focus new windows by default.

9) Other food for thought:

One could argue that if minimizing window movement were to always be more
important than avoiding occlusion, then we shouldn't tile windows at all and
just always place in the center.  adrian may be arguing that.  However, I don't
think that's the case.  It's a trade-off, just as predictability isn't king in
all cases as shown above.  (Plus there's always stuff like focus stealing
prevention, dialog and utility windows that should be placed with respect to
their parent only, PPosition hints, strict pointer mode (see bug 152004, in
particular comment 14--though I'm worried about losing significant
predictability there), etc.)  I think that avoiding occlusion is an important
benefit to weigh and that for an empty desktop on a single xinerama it makes
sense.  In fact, always centering as the fallback seems a little odd to me and I
think we might be able to do something better (though always centering as a
fallback sounds *FAR* better than our current cascade-from-upper-left syndrome)


In summary:
  - there's lots of tradeoffs to consider--and I think some just weren't
    thought of at the time the cascase-from-upper-left-as-a-fallback stuff was
    written.
  - I think center-as-fallback would be much better than current behavior, 
    though perhaps not optimal and there's definitely room for discussion.

Adrian: I believe your point is valid for two or three of those options, but
"other preferences exist and this one is likely wanted by just as many people"
isn't good enough rationale for adding more preferences.  (And the argument can
actually be used to say "oh, well maybe we should remove that preference from
Metacity if it isn't used that much").  Each preference has an associated cost
and a benefit, and they need to be weighed.  

Sloppy/mouse focus ("select window when mouse moves over them"): still a niche
usage, but vastly outnumbers the users of all the other preferences you list. 
Unfortunately, there is also a pretty large cost associated with this
preference; it affects all kinds of stuff (including disallowing app authors
from making certain design decisions) and created a huge maintainence load.  But
there are just too many developers attached to this that would certainly fork
metacity if it didn't exist.  It's not removeable from Metacity (though it and
all other window preference options could certainly be removed from any
appliction in the preferences menu in the panel).

Autoraise ("Raise selected windows after an interval"): moderate benefit for a
very small niche.  It's absolutely stupid that we have such a preference in the
user interface as it also causes all kinds of confusion (see bug 312421, bug
154614, and probably others), so it should definitely be a gconf-only option at
most.  Very small maintainence load, though.

"Double-click titlebar to roll up the window": Also a small niche usage, with
moderate benefit to its users (*cough* I personally don't believe that it
actually helps people but I'll given them the benefit of the doubt).  Also
doesn't belong in the UI (and why isn't
don't-do-ANYTHING-when-I-accidentally-double-click-a-titlebar-you-stupid-annoying-WM
an option?).  Virtually no maintenance load at all, though (assuming you allow
windows to become shaded by other means; it does have a small maintainence load
if you assume that removing this option would allow you to remove the
possibility of having shaded windows).

Modifier ("Move a window with Windows Super key"): small niche usage, but
certain proprietary apps that we can't change are unusable for users unless we
provide this option.  Very small, if any, maintenance load.

Placement behavior option: small niche usage, with moderate benefit to its
users.  Huge maintainence increase approaching the level of sloppy/mouse focus
(there are all kinds of special cases that have to be considered for window
placement--see e.g. bug 307875 comment 11 and below especially the comments in
attachment 49307 [details] [review], bug 152004 comment 14, bug 166757, bug 106239, bug 138290, bug
145503, bug 167042, bug 166524, bug 165381, bug 107347, bug 93590, and many others).

Hope that explains things a little better.

Elijah, thank you for your explanations.

I deduce from them that you consider that the important thing is not only the
amount of people demanding an option, but also its maintenance load. Well, in my
opinion, the maintenance load of the center policy is low in comparison to the
current policy, since the algorithm is very simple (always center).

I'd also like to comment one point that hasn't been mentioned. A big percentage
of users (like me) use always the task list applet to change the active window.
We never click on other window to make it active, we use exclusively the tasklisk.

That is why overlapping/occlusion doesn't matter to us. We just find quick and
easily any window in the tasklist. And that is why the center policy is so
useful: because we know exactly where a window is going to appear (maximum
predictability), both if we are openning a new one or if we are focusing a
minimized/overlapped one; and because we don't have to move any window, all
windows are in their place (the work for moving windows is zero).

It sounds to me like the arguments for falling back to center rather than
cascade are pretty good.

The arguments for making it a preference are not there at the moment imo.

Maybe an ideal behavior would be that the "center-tiling" behavior we have now
would happen over and over. So right now if you open four terminals on a blank
screen they are in a 2x2 grid, with the grid centered. We could say that if you
open 8, you get two 2x2 grids stacked on top of each other. That seems sort of
cute. Tricky to implement, though. And basically who cares since as Elijah says
nobody opens a ton of windows at once, possible exception being terminals.

The reality is that most of the time the fallback placement policy gets chosen,
since most app windows are too large to open two of them non-overlapping, and
dialogs always get centered on parent so don't use the "center-tiling" anyway.
So if we center as the fallback, centering will happen except in the "center
tiling" case of e.g. opening a bunch of terminals.

Created attachment 51038 [details] [review]
Fall back to center instead of corner-cascade

Here's a simple patch against 2.10.3 that changes the fallback behavior from
the corner cascade (find_next_cascade) to simple centering on the current
xinerama. All I did was replace find_next_cascade(), so if find_fit_first()
returns FALSE, the next block of code will still try to place the new window at
the origin of an empty xinerama. I don't know if centering in that case would
be desirable.

I tried this patch on a dual-head system, and it seems to behave as I would
expect with Xinerama.

Hi -- 2 cents;

I am constantly repositioning my windows; different windows (read: applications
contained in them) have different uses.

I have no idea how difficult it is to program but I know it wouldn't be
thousands of alogarthims to give users some choices. I would be happy with the
following choices : 1) default (whatever is used now or whatever metacity thinks
is the best choice); 2) centre all; 3) geometry (a command equal to Xwindows
geometry command) that could be set through gconf-editor. 

I would like to see these commands setup in a hierarchical structure; that is:
1) Metacity - for all windows - but could be overriden by 
2) geomtery choices made for applications in gconf-editor -- that could be
overriden by geometry choices 
3) made in launchers (for when an application starts with opening specific files
or under other command line conditions)

E.g.  I could set all windows to open in the center, except my mail-notification
which I could set to open lower right and I could launch one or two specific
files containing research I had been doing on the right hand 1/3 of my screen 
the full hieght of the screen. 

Some of that is already supposed to happen but it doesn't.

I don't consider this suggestion just a passing thought. After using gnome for
over a year, it is getting annoying to be always dragging windows around while I
am trying to concentrate on something else -- like work.
 
Regards Bill 
 

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

Hi Gnome folks,

whatever was your reasoning for marking this WONTFIX, you are WRONG.

Not being forced to manually center each window is not a feature required by some picky 0.5% users.

I love Gnome/Metacity, but I'm basically forced to leave it because of this single thing.
Beryl adds fix for this with the Place plugin (I guess it's because people don't need it!? /sarcasm), but Beryl is still alpha/beta stuff.

I'm not gonna run my mouse additional 10 km a year just because you guys have a problem with implementing a simple solution, for example like presented in the comment right above.

I do not need to see 100% of all my windows at once, side by side.

I don't mean to sound rough, but I know I speak for a lot of users, and I want to make my message clear.

Peace,
J.

FWIW, another vote for remembering window size + position.

I'm constantly resizing / maximizing / repositioning the same windows over and over again.  It's a productivity drain.

Saying that "applications should do this" might be true in a perfect world - but it's not the *reality*.  The *window manager* should manage my windows.

Saying that "95% are happy, then it's 0.5% want this, 0.5% want that" is clearly wrong.  Some percentage may not notice or care, but a very large percentage *do care* ... just spend a couple of hours searching (as I have just done) for 'remember window size | position gnome | linux | metacity'.

As for needing a "zillion placement algorithms" - that's just silly and disappointing that a developer would put forward an 'argument' like that.  Are the developers building for their personal preference or for the community?

However, I don't agree with the 'centre all windows' approach, but 'remember size + position of all windows' as an option would work for *everyone*.

FWIW.

I fully agree that size/position should be remembered. This feature is missing, however, because it is not possible to implement in the WM without app changes. At least I don't know any way to implement it.

(Yes, there are heuristic ways to implement it, but they involve guessing which windows are "the same" as which previous windows; and the guesses are not reliable, so the code would be inherently and forever buggy. No thanks.)

If people want this, there has been plenty of discussion of how to add it to GTK+, and what's missing is someone really making it a mission to do the design and coding work.

Thanks for the reply, Havoc.  That explains a little more about the complexity and why it's not been implemented already.  Unfortunately, I'm one of the majority who offer 'to do it if I could' - hacking PHP is where my coding ability / desire ends. :/

Is there anywhere / anyone else to petition for this?  Or is this a dead issue?  As a newcomer to Linux, I find it very difficult to know where to start discussions about this type of thing - mailing lists, bugzillas, forums, Launchpad, #irc....

Otherwise, looks like we're stuck with window matching apps, such as http://burtonini.com/blog/computers/devilspie?

I posted http://gnomesupport.org/forums/viewtopic.php?p=57546 before seeing your reply.

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

fixing spelling (both ways) so it can be found

This was made a blueprint in Ubuntu (but I don't know who by).

https://blueprints.launchpad.net/metacity/+spec/center-window-shortcut