I agree with the sentiments of the OP, or at least a gconf key to set the
default monitor for new application windows, something like:

metacity/general/preferred_monitor:

  "any"      "use any available space" (like current behavior)
  "mouse"    "use monitor containing mouse pointer"
  "1"        "monitor 1"
  "2"        "monitor 2"

I have a second monitor that outputs to a TV that is usually off, when new
windows appear on that monitor it is a pain to move them back to the first.

There's a long discussion I had in private mail with Kevin Martin and Owen about 
Xinerama and the case where people intend the two heads to be really separate
(sort of like X screens, but with windows able to move between them) and the
case where multiple monitors are being combined into a single display. In the
long term we would like X to distinguish these for us. Adding a setting to
metacity is somewhat problematic because some of the decision points on how to
place and treat windows are in the toolkit and apps.

What metacity does now though is assume each xinerama monitor is a separate
head, really (with own panel, etc.) - I think the right default probably is to
place on the current monitor rather than any available space.

As a workaround in the meantime you might want to use two separate X screens
rather than xinerama - you won't be able to move windows between them, which
sucks, but it sounds like that may not matter if you're only going to run a
movie player or something on head 2.

My 2nd monitor is mostly off. I need the 2nd monitor only for some programs and
I like to use xinerama. Because of this I must use "xfwm4" instead of "metacity".

IMHO the idea with the gconf key is realy great!

metacity/general/preferred_monitor:

  "any"      "use any available space" (like current behavior)
  "mouse"    "use monitor containing mouse pointer"
  "1"        "monitor 1"
  "2"        "monitor 2"

After half a year and major progress in other directions, this elementary
problem is not solved yet? I have even made a workaround - a simple application
that is maximized on my second screen so that window opening become predictable,
but still it is a dirty workaround...

Any progress on this?

Somebody went to the trouble of rolling their own RPMs to fix this:

http://www.itee.uq.edu.au/~agn/ag_fedora/extras/

which suggests that there really should be an option to do this (or make it the default)

Which, in fact, was what havoc was suggesting back in 2004:

(from comment #2)

> What metacity does now though is assume each xinerama monitor is a separate
> head, really (with own panel, etc.) - I think the right default probably is to
> place on the current monitor rather than any available space.

Still present in metacity 2.10.3.

If someone went to the trouble to roll their own rpms, why don't they add the patch to this bug? ;-)

(In reply to comment #9)
> If someone went to the trouble to roll their own rpms, why don't they add the
> patch to this bug? ;-)

Good point.  I'll grab the SRPM and extract the patch and attach it here. 

Created attachment 59817 [details] [review]
Patch to ensure xinerama uses current screen

This was a patch against metacity 2.10.3, taken from this SRPM for FC-4:

http://www.itee.uq.edu.au/~agn/ag_fedora/extras/FC4/SRPMS/metacity-2.10.3-2.src.rpm

Don't know if it will apply to CVS HEAD.

That patch is obviously totally wrong, but even with a correct implementation I think it would be a mistake to change this default.  What metacity does now is manifestly _not_ assuming that each xinerama is a totally separate head, but rather attempts to allow the effective use of all of the screen real estate available as automatically as possible.

This allows for a number of very useful cases:
  1) opening a number of windows will effectively find good places for as many windows as possible
  2) windows that start maximized will find an xinerama to occupy.  This is especially useful for things like browser windows.

Destroying all the effort that went into window placement for xinerama would be a mistake.

(In reply to comment #12)
> That patch is obviously totally wrong, but even with a correct implementation I
> think it would be a mistake to change this default.  What metacity does now is
> manifestly _not_ assuming that each xinerama is a totally separate head, but
> rather attempts to allow the effective use of all of the screen real estate
> available as automatically as possible.

Well, at least provide an alternative.  It is *very* annoying for new windows screens to go elsewhere than where the cursor is as several bug reports attest.   What would you propose?

The solution is a programmatic way to distinguish between cases like a random extra device attached and using xinerama the way it was designed.  The use case the placement is designed for now is the "xinerama" use case, where multiple monitors are used as part of a single console.

Perhaps a way of declaring in the xorg.conf file displays that are "head non grata" would make sense.  But this is a corner case.

(In reply to comment #14)

> Perhaps a way of declaring in the xorg.conf file displays that are "head non
> grata" would make sense.  But this is a corner case.

I don't think that it's such a corner case, I think the safe user expectation is that the screen will open where the cursor is, because even with xinerama, unless your monitors are completely adjacent then it isn't a true single virtual monitor.  I suspect that most users of xinerama are users like me with a laptop screen and an external monitor, where the monitors are unlikely to be exactly side-by-side.

Anyway, what about a gconf key as proposed in comment #1 and comment #3?  

Yes, in ideal world, there should be no distinction, but metacity should take into account the fact the configurations that many users do actually use.  The solution shouldn't require re-compiling the code to get what they want (disabling xinerama as havoc proposed in comment #2 isn't an option because you can't move apps back and forth as havoc points out).

Downstream bug report:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199520

Patch is a hack for obtaining that behavior, as Rob pointed out, so updating the status accordingly.

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

Developers, what is your opinion on that? You still have this bug UNCONFIRMED but the facts are clear. Metacity is unusable with Xinerama on and one monitor off. There has been a suggestion for the new opinion. Default setting could be same so I do not know what you dont like it.

Could you please take a stand with that? Where is the problem you do not want to accept this setting which could make lots of lifes a little easier. If you are too busy then just suggest a solution and we can provide the patch. The one that could be acceptable for you. But do not ignore this for next 2 years.

I said what I thought in 2004, comment #2. It disagrees with what Rob said, and I think Rob is wrong, at least as of the last time I looked at the code; metacity treats each Xinerama head as a separate monitor right now. If it didn't, then there would be no "Xinerama support" in metacity at all.
If the placement algorithm doesn't treat each xinerama as a separate head then I don't think the placement algorithm is correct.

I think a preference is fairly lame because you need this same pref in gtk and various apps; I still think the X server should have this setting to be honest, since it's a question of describing the physical hardware setup.

But if someone else wants to try and sketch out all the issues and argue for a good solution please do - I don't see much of that on this bug.

The UNCONFIRMED state does not have any meaning btw, everyone just ignores it for metacity afaik. It's only there because some other modules might use it.

I still not understand but you know better why is this wrong. What I understand is you need to have clean design no matter if it bothers the users. If you find a solution somethimes I will be glad. 

You should close this bug then. Thanks.

I don't think this bug should be closed. As to no one having supposed any solutions, I think the suggestion made in comment #1 is perfect - No one has actually criticised this comment, so what's wrong with it?

Well, comment #2?

comment #2 isn't a direct criticism of comment #1, and I don't see what's stopping implementation of the suggestion in comment #1. Waiting for this to be handled at the X level is unrealistic and, I think, unnecessary.

A patch implementing the suggestion in comment 1 would not be acceptable; see bug 151818 comment 10 by Havoc for why.  I agree with you and think things can be much improved without waiting for something to be fixed at the X level, and that the original comment of this bug is close to correct (though the behavior would likely need to be modified to handle keynav better; if the user hasn't used the mouse for an hour then the mouse pointer position is irrelevant).  Havoc also agreed with that in comment #2 (and bug 106239 comment 0 and I'm pretty sure elsewhere).  See also bug 151818 comment 22 for some related issues in this design space.  At some point I'll sit down, review all the bugs and design decisions in this area, and try to fix the current policy.  But a dissertation needs to be finished first.  ;-)

Thats great. Thank you!

Ubuntu bug about that: https://launchpad.net/products/metacity/+bug/43582

Hello,

I also have this problem and I know I'm not the only one.
(Friend of mine, my sister, ...)

And alright, I do understand that this should be handled at X, but they are already giving you guys the xinerama's to use, so what not use them like you should?

This "bug" pisses me off quite some times a day.
I have a 2 monitor system (in a month that will be 3) and every morning I turn on one of the screens to check my mail. I don't bother turning on the other one. And hwat happends? My mails open in the other screen.

I don't think we should call this a bug since it's just a matter of policy.

So please bend a little!
I don't see the use of NOT putting the window where the mouse is.
I do see a million reasons why you'd want it there :)

And if you're concerned about the few (or zero) people who want to use this "efficient, althou unpredicatble" window placement, make an option for it! Let the user choose! That is, in my eyes, the true meaning of linux.

Anyway I can't code c++ so I should shut up ;-)

I don't think the issue is bending a little, it's someone doing the work. Fixing this properly, whether in X or in metacity, should be very easy. There just isn't anyone working on it.

There are two suggestions already that are trivial, metacity-only, and simply don't have patches contributed to implement them. In comment #2, I suggested:

> What metacity does now though is assume each xinerama monitor is a separate
> head, really (with own panel, etc.) - I think the right default probably is to
> place on the current monitor rather than any available space.

Then there's also bug #106239 which further suggests mouse placement if the monitor is "big"

Both of these are trivial to implement.

The X or gnome-settings-daemon change would make things a bit nicer by adding a global configuration for whether we should think of multiple xinerama heads as one or many monitors; this setting would essentially enable/disable what metacity's current codebase calls "xinerama support" ("xinerama support" = "act as if one X screen has multiple distinct monitors").

This needs to be in X or at least GNOME-wide because GTK+ (or any other toolkit), the panel, etc. handle a lot of the "Xinerama support" magic - if only metacity ignores Xinerama and other stuff doesn't, things will be pretty screwy.

Doing the change in X is trivial from a code standpoint, but possibly a headache from a political standpoint. (The issue here is simply giving apps enough info to know if they have a single virtual monitor that happens to be composed of multiple CRT tubes or LCD panels, or whether they want a separate desktop setup on each monitor. I think the "single virtual monitor" case should probably report only one Xinerama head, so apps are forced to do the right thing, but failing that just a boolean flag would be helpful. Logically, this will always be configured at the same place and time one configures Xinerama itself, and always be queried from the X server at the same place and time one queries Xinerama itself, so I would think it should just be part of Xinerama to mark this info.)

It's worth a try though; if the X developers don't like this, then we could agree on an XSETTING or something across GNOME/KDE, and if that fails we could have a GNOME-specific setting in gnome-settings-daemon.

None of these things are at all hard other than writing up a couple of mails to the relevant lists with a concrete proposal.

I think the two metacity-only fixes already suggested would fix the immediate placement-related complaint in this bug report though, so it isn't even as hard as fixing the whole desktop. Someone just has to do these simple fixes which were suggested in 2003 and 2004.

I just started using metacity + xinerama very little time ago. The result was quite cool when I was at home with both screens on, but here is the downside: when I take the laptop to work, I can't reach the windows I create. Let me say this again:

METACITY WON'T LET ME REACH THE WINDOWS I CREATE.

I could only classify that behaviour as disabling, since it effectively prevented me from using xinerama at all. So please, will you make me happy and allow a sad gconf checkbox that will allow me to be able to see the windows I open when my second screen is not on?

Thanks a lot for your attention.

Will people stop acting like there's a debate here? There is no debate. Everyone (as far as I can tell) pretty much agrees that the fixes as described in comment #2 and comment #29 would solve the problem.

There is nothing hard about implementing these fixes, someone just has to do it.

In comment #30, why are you asking "please let me check an obscure box to fix the bug" when there's already a perfectly good and even *easier* to implement suggestion for how to simply fix the bug, period, which nobody has seriously argued against? Nobody *wants* their windows to vanish, a "please don't vanish my windows" button sounds pretty silly.

Again, there's no debate. There are perfectly good, trivial to implement solutions agreed upon for the last 2 years.

What's missing is someone who will code and test those fixes. Anyone is very welcome to do so.

Created attachment 78405 [details] [review]
Always place new windows on the current xinerama

How's this for a first stab at it?

This would work for small windows but not I believe for maximized windows if I remember correctly.

Regardless this throws the baby out with the bathwater.  We have 2 cases:
1) desktop xinerama; multiple monitors on a desktop computer
2) laptop/projector/weird setup xinerama: a laptop plugged into an extra monitor/projector/Tv-out/whatever
3) Same as (2), but where they don't have or refuse to use xrandr for some reason

Currently we handle case (1) excellently and I haven't heard anyone claim otherwise.  Case (2) works fine if they use Xrandr to remove the monitor from the configuration.  This is analogous to how it works under Windows, though Windows doesn't place windows but instead puts them wherever you had them before in most cases.

Your change would make case (1) and (2) basically nonfunctional from a window placement point of view in the sense that you'd have to always place windows manually in exchange for making case (3) work.

Case (3) is probably a real use case we should worry about somewhat mainly since reconfiguring using Xrandr isn't always easily doable, but (1) and (2) are also important use cases.

Is this not what Havoc was suggesting in comment 2, then? or are you saying that he was mistaken?

No I agree mostly with Havoc in that case; doing this would indeed make (3) work and (1) and (2) with continue to work but in a degraded mode.  Havoc also mentions in his most recent comment a case (4) which is basically the video wall case, but in this case you can run a metacity with xinerama support disabled.

We should probably put a giant #ifdef __X_WINDOWS_STILL_SUCKS around the code changes though, since all we need to be able to use this totally excellent code (if you've ever used it in case 1 you'll agree with me that this is definitely the way to go for desktop users).  All we need is a way to easily attach and remove monitors to a running X desktop.  From what I understand, this support is going to be in the next version of Xorg.

Also, separately, I was making the comment to you that I believe there are two cases where it uses the natural xinerama ordering: the case you found and also another place where it uses it to try to find an empty monitor to place "large" windows.

Incidentally, if you use nvidia drivers you can already easily attach and remove extra displays from a running metacity fairly straightforwardly once you've configured your xorg.conf correctly using the Screen Resolution capplet.  The current code works in this case Like It Should (TM).

Rephrasing so it's not horribly confusing:

Incidentally, if you use nvidia drivers you can already easily attach and
remove extra displays from a running Xorg fairly straightforwardly.  Once
you've configured your xorg.conf correctly, you can do this using the Screen Resolution capplet.

The current code works in this case Like It Should (TM).

I think it's fairly simple. There are two modes, "multiple monitor aware" and "we have one big monitor"

I think those are the only two modes, there's some possibility that some kind of config option in X or GNOME or GTK should allow "force one big monitor even though xinerama is present" but the only code in metacity that would care about that is the code that initializes the "xinerama monitors" list - all other code can be written cleanly and correctly today with no FIXME required. A config option would only change what goes in the "xinerama monitors" list.

The patch seems to have a lot of whitespace changes that aren't related?

"Your change would make case (1) and (2) basically nonfunctional from a window
placement point of view in the sense that you'd have to always place windows
manually in exchange for making case (3) work.

Case (3) is probably a real use case we should worry about somewhat mainly
since reconfiguring using Xrandr isn't always easily doable, but (1) and (2)
are also important use cases".

Well, since Thomas' patch would make (3) case users like myself happier but would be bad for (1) and (2) cases, could we add a gconf option to activate/deactivate its effects?

Created attachment 84381 [details] [review]
xinerama_selection

This patch adds a new gconf options "xinerama_selection" that changes the behavior when metacity has to place a new window.
Two values are accepted:
"all" (default) is the current behavior : first xinerama in which the window fits
"current" will always select the current xinerama

Created attachment 84382 [details] [review]
same patch without blank changes

I think Thomas's original patch to just fix the bug as mentioned in #2, #29, #31 is right, at least as the first cut. (did not look at the code of the patch, just what it claims to do)

If there is a config key, it seems to me it should be broader/desktop-global.
See also recent wm-spec-list thread:
http://mail.gnome.org/archives/wm-spec-list/2007-March/msg00003.html

But I would not block just fixing the default on a debate about configuration and where the configuration should live. Why not just fix the default first, then try to separate out each remaining issue and ideally address them in a "just works" way.

(In reply to comment #43)
> I think Thomas's original patch to just fix the bug as mentioned in #2, #29,
> #31 is right, at least as the first cut. (did not look at the code of the
> patch, just what it claims to do)

Thomas' patch doesn't do what's suggested in #2. The only patches availiables are :
* Alex' : very simple to make metacity believe there's only 1 xinerama when it has to select one
* Thomas' : drop old behavior and always display new windows on current xinerama
* mine : gconf option to select between the two behaviors

> If there is a config key, it seems to me it should be broader/desktop-global.
> See also recent wm-spec-list thread:
> http://mail.gnome.org/archives/wm-spec-list/2007-March/msg00003.html

When something is decided, you'll have something to implement. But right now (and since 2004) we just need a usable xinerama. Many people use a modified version of metacity only because of this bug (see the deb and rpm packages).

> But I would not block just fixing the default on a debate about configuration
> and where the configuration should live. Why not just fix the default first,
> then try to separate out each remaining issue and ideally address them in a
> "just works" way.

I think the expected behavior is indeed to display new windows in the current xinerama.
Any intelligent placement should be optional, because to make it intelligent, you have to make assumptions on usage that may be wrong in some cases. Here you assumed all screens are always visible in a xinerama configuration.

I think someone has to apply one of the patches and close this bug. I've just acquired a second display and was disapointed to see my windows appear on the "wrong" display. Then I was even more surprised to discover this 2 years old bug still not fixed.

I'd rather let the users choose the behavior (some people probably like the current behavior), with "current" as the default. But if you really want no configuration, apply Thomas' patch.

"some people probably like the current behavior" is the road to madness, trust me ;-) especially when the current behavior is pure historical accident with no real solid rationale.

Either we know why and when the current behavior makes sense and we try to make it happen in those cases (ideally automatically, as a fallback via manual config, the more global/general the config the better), or we have no idea what the current behavior is about so we put a bullet in it because we wouldn't know how to evolve or evaluate changes to that behavior anyway (without understanding the rationale, how could we know what changes make sense)

anyway, I would vote for unconditionally placing on current xinerama as a first cut and then see what happens, if people hate it they will undoubtedly say so...

Actually Michael has said something rather significant:  This is the first xinerama user I've come across who _doesn't_ like the current behavior _and_ is using xinerama in the "normal" case of "side by side monitors".  Literally _everyone_ who's ever even mentioned this behavior has been using xinerama in the case of using xinerama for a weird extra display like a projector or a TV-out or something, or has simply _never used xinerama at all_.  For the "weird" case I think that monitor hotplugging is pretty clearly the right solution, since even changing the placement algorithm is no guarantee that no windows will appear on that xinerama.

Calling the current behavior "historical accident" is disingenuous, since I personally spent a lot of time designing and writing the xinerama placement behavior.  I assure you all the current design of the behavior was no accident (though the fallback cascade is something I never got around to fixing).  Let me explain the current xinerama placement behavior a bit.

First, we define the "natural xinerama ordering".  This is a breadth first-traversal of the xinerama edge graph which prefers first side-by-side and second top-to-bottom.  The placement algorithm proceeds as follows:

1) Check size of new window.  If the size of the new window is the same size or larger than the current display, auto-maximize takes effect
  a) If automaximize, try to find an empty xinerama using the natural xinerama ordering.  If there is no empty xinerama, use the current one.  Maximize window on the chosen xinerama
2) If no automaximize, then we apply center-tiling algorithm (on each xinerama in the natural ordering on turn, starting with the current xinerama).  If center-tiling fails to find an empty place for the window on any xinerama, fall back to cascade algorithm
  a) center-tiling will first attempt to find a edge of an existing window next to which the new window will "fit".  If this fails, center-tiling computes the position for the window such that if you were to open many more of them, the entire group of windows would be "visually centered" on the display.  Visual centering means the space below the window is double the space above the window, and is truly centered horizontally.
  b) cascade (this part really is historical accident) just starts at the upper-left corner and simply iterates by seeing if any window is places at precisely the current point, and moving the window down by a title-bar-height and a fixed x-offset.

The natural xinerama ordering has the purpose of trying to place a window "as close as possible" to the current xinerama, and can handle the case of very large xinerama graphs or unusual monitor arrangements, including 2-dimensional arrangements.  The idea is to enable an xinerama user to use effectively and automatically all of the desktop space available to the user.

I think the natural ordering is especially effective in the case of "automaximized" windows, since you can, for example, open n firefoxen and have then simply and automatically tile your n monitors.  I could be persuaded that perhaps it doesn't make as much sense in the center-tiling case for very small windows (i.e. windows for which center-tiling doesn't simply visually center the window). 

Rob,

I hate to say it, but you are the _only_ xinerama user I have ever come across that likes the current behavior.  In my experience, all others dislike it.  Many have reported a violent dislike for it to me, and I even went and polled a few on my own.

See also the tradeoff rationale at bug 151818 comment 22, which focuses on the fallback cascading behavior in terms of a single monitor, but which lists usability criteria that are important here as well.  For the same reasons listed there for that bug, I think the current behavior for xinerama placement is not optimal.

Anyway, I've avoided changing this for so long because I knew you liked it and because you put so much time into fixing xinerama in Metacity.  But I agree with Havoc (who has stated in this bug and probably a dozen or so others, starting at least back in bug 106239) that placement should default to the current xinerama.

Just my $0.02.

Perhaps part of the reason I like the current behavior so much is that the fallback cascade algorithm is so braindead, so it may simply be a case where using the natural xinerama ordering for placement is a workaround for the cascade algorithm sucking.

In any case, I do think that the current behavior is quite good for the case of automaximized windows at least.  So I propose we try the following:

 1) Remove natural-order-search for center-tiling
 2) Leave natural-order-search for auto-maximizing
 3) Fix fallback placement (for some definition of fix, perhaps as simple as setting the cascade origin to something other than 0,0 )

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

I think Preferences/Windows should have drop down menu for this. And preferably so  that the current behavior is *not* the default, since people really expect windows opened where they look at. If there is some special reasons not to do so, they should be able to change it in configuration.

Nothing has ever, *never*, bugged me in Linux as bad as this one. It's really scary experience to see a major usability issue which has been open as long as this one. 

Most people want things just to work! Temporary solutions are better than no solution at all. When temporary solution is in place, we can use all the time in the world to come up with perfect solution, knowing that those 10 000 people who use Gnome with multi-monitor desktop can sleep their nights peacefully instead of screaming and pulling hair out of their heads.

Going to look for those custom metacity builds...

For Ubuntu users, here are instructions how to fix your Metacity quite easily:

http://www.ailis.de/~k/docs/atilinux/

Let's not make this into some big metaphysical issue about temporary vs. root cause solutions or prefs or usability or whatever. Some bugs may be about that or have significant controversy in those areas, but this one doesn't that I see.

See comment #29

There's already a patch to just fix the thing, which is clearly an improvement according to pretty much everyone, whether or not further tweaks (including prefs or other placement enhancements) are desirable. So the first work to be done is to review and hopefully commit the existing patch to just fix the default.

I'm sure when Thomas or Elijah have time to do this, they will do it. In the meantime, posting more "me too" or "advocacy" comments on the bug does no good. Helping with the overall metacity workload probably _would_ be helpful.

Now that's one interesting read, for something so trivial this has been open for nearly 3 years?

Okay, I'm just adding my 5c here, but I have to say, my use-case is with a television plugged in to my second head, true I should be using separate screens for each head but the reason I like Xinerama or TwinView is due to the fact that I  can't really see the TV from the workstation and tend to drag totem and hit F.

What's really interesting is that if you read the nVidia recommendations they suggest not to use separate screens and instead use TwinView as they explain the default behaviour is that windows open on the screen that the cursor is currently within.

For now I'm using two screens and use my partner to direct me as to what I'm doing on the second head (literally flying visually disadvantaged).


With interest,
-Brett

So, we should apply my patch for now and then talk about configuration?

Yes, please apply your patch. Havoc and Elijah have already agreed (#45 and #47).

Created attachment 90190 [details] [review]
Always place new windows on the current xinerama and keep cascading

Actually, there's a little problem with your patch: metacity doesn't cascade the window anymore when the screen is full (ie when find_first_fit fails).

This patch fixes the problem. I checked it on trunk and current Ubuntu package (based on 2.18.2).

For impatient Ubuntu users, here's the package:
http://lepton.fr/tools/metacity_2.18.2-0ubuntu1.1_i386.deb

Aw, shoot. I applied my patch and made a release about ten minutes before you commented. What do I do now-- make another point release in a couple of hours?

I don't know, it depends how costly it is to make a release and how many people have already started using your new release.

This bug is not critical, but will surely bother people. The placement is changed for everyone, not only xinerama users.

I think you should fix the cascade problem right now, at least in trunk. I don't know how important it is to make another release. I think the most important is that this bug is not released in an official Gnome release.

Created attachment 90255 [details] [review]
Restores cascading

Here's the patch to apply on trunk to restore cascading after Thomas' patch.

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

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

What does it take to get the old behavior back? I am a user of twinview, nvidia's treat multiple monitors as one feature, and the new behavior is very frustrating. I don't expect windows to follow my mouse. I expect the window manager to maximize the usage of screens. Otherwise, why have two monitors?

Case in point, I like to open four terminal window per monitor. This works till terminal window five. At five instead of being to use the second screen, it starts overlapping with the existing four.

Another case is firefox and thunderbird. I open both on one workspace, and I expect them not to overlap. Yet with this follow the mouse pointer I have to always move one to the opposite monitor. It is very annoying.

I tried Michael Witrant's patches to create the xinerama_selection gconf preference. At least against 2.20.2 it didn't work for me. I set the preference to all and it didn't restore behavior.

I then reversed the committed patch, and poof, I am back to window manager with sanity.