After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 609258 - multiple monitor behavior for the overview
multiple monitor behavior for the overview
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Florian Müllner
gnome-shell-maint
: 581833 611909 635507 (view as bug list)
Depends on: 643786
Blocks: randr-tracker 645023 646912
 
 
Reported: 2010-02-07 18:45 UTC by William Jon McCann
Modified: 2011-09-20 09:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
overview with dual monitor and 6 windows (740.56 KB, image/png)
2010-11-22 11:15 UTC, Johannes Schmid
  Details
exposing MetaWindow.move() and .resize() in javascript and adding .move_frame() (4.09 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Add MetaScreen::monitors-changed signal (1.91 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Add api to get the primary monitor of the screen (3.17 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Track the primary monitor for each window (3.62 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Add API to get the primary monitor of a window (1.64 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Split out on_all_workspaces and on_all_workspaces_requested (13.31 KB, patch)
2011-03-04 15:18 UTC, Alexander Larsson
none Details | Review
Add workspaces_only_on_primary preferences (default FALSE) (5.12 KB, patch)
2011-03-04 15:19 UTC, Alexander Larsson
none Details | Review
Add signals for when windows change primary monitors (3.95 KB, patch)
2011-03-04 15:19 UTC, Alexander Larsson
none Details | Review
Bail early from check over all permutations (1.08 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
dnd: Avoid division by zero, etc for zero-size actors (1.20 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Switch to using the mutter primary monitor APIs (3.62 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Enable the workspaces_only_on_primary feature of mutter (2.07 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Add and export shell_global_get_primary_monitor_index (1.67 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Only show the primary monitor region in the workspace thumbnails (4.18 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor in the workspace thumbnails (5.94 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor on the overview workspace (8.09 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Move the font color CSS rule from .workspaces-view to .window-caption (827 bytes, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Add workspaces on non-primary monitors (8.03 KB, patch)
2011-03-04 15:20 UTC, Alexander Larsson
none Details | Review
Always reserve space in all workspaces on a drag (3.18 KB, patch)
2011-03-04 15:21 UTC, Alexander Larsson
none Details | Review
overview: hidden workspace thumbnails should not stick out on other monitor (1.21 KB, patch)
2011-03-08 09:08 UTC, Alexander Larsson
none Details | Review
Emit monitor-window-removed when windows are unmanaged (1.07 KB, patch)
2011-03-08 09:19 UTC, Alexander Larsson
none Details | Review
Bail early from check over all permutations (1.08 KB, patch)
2011-03-08 21:25 UTC, Alexander Larsson
committed Details | Review
Switch to using the mutter primary monitor APIs (3.60 KB, patch)
2011-03-08 21:25 UTC, Alexander Larsson
none Details | Review
Enable the workspaces_only_on_primary feature of mutter (1.99 KB, patch)
2011-03-08 21:26 UTC, Alexander Larsson
none Details | Review
Add and export shell_global_get_primary_monitor_index (1.67 KB, patch)
2011-03-08 21:26 UTC, Alexander Larsson
none Details | Review
Only show the primary monitor region in the workspace thumbnails (4.18 KB, patch)
2011-03-08 21:26 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor in the workspace thumbnails (5.94 KB, patch)
2011-03-08 21:26 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor on the overview workspace (8.09 KB, patch)
2011-03-08 21:27 UTC, Alexander Larsson
none Details | Review
Move the font color CSS rule from .workspaces-view to .window-caption (827 bytes, patch)
2011-03-08 21:27 UTC, Alexander Larsson
none Details | Review
Add workspaces on non-primary monitors (8.03 KB, patch)
2011-03-08 21:27 UTC, Alexander Larsson
none Details | Review
Always reserve space in all workspaces on a drag (3.18 KB, patch)
2011-03-08 21:27 UTC, Alexander Larsson
none Details | Review
overview: hidden workspace thumbnails should not stick out on other monitor (1.21 KB, patch)
2011-03-08 21:27 UTC, Alexander Larsson
none Details | Review
exposing MetaWindow.move() and .resize() in javascript and adding .move_frame() (4.07 KB, patch)
2011-03-09 15:02 UTC, Alexander Larsson
committed Details | Review
Add MetaScreen::monitors-changed signal (1.91 KB, patch)
2011-03-09 15:03 UTC, Alexander Larsson
none Details | Review
Add api to get the primary monitor of the screen (3.16 KB, patch)
2011-03-09 15:03 UTC, Alexander Larsson
none Details | Review
Track the primary monitor for each window (3.62 KB, patch)
2011-03-09 15:03 UTC, Alexander Larsson
none Details | Review
Add API to get the primary monitor of a window (1.62 KB, patch)
2011-03-09 15:03 UTC, Alexander Larsson
none Details | Review
Add meta_window_is_on_primary_monitor function (1.54 KB, patch)
2011-03-09 15:03 UTC, Alexander Larsson
none Details | Review
Split out on_all_workspaces and on_all_workspaces_requested (13.31 KB, patch)
2011-03-09 15:04 UTC, Alexander Larsson
none Details | Review
Add workspaces_only_on_primary preferences (default FALSE) (5.00 KB, patch)
2011-03-09 15:04 UTC, Alexander Larsson
none Details | Review
Add signals for when windows change primary monitors (4.33 KB, patch)
2011-03-09 15:04 UTC, Alexander Larsson
none Details | Review
Only show workspace and stick/unstick in menu item for primary monitor (3.60 KB, patch)
2011-03-09 15:04 UTC, Alexander Larsson
none Details | Review
Switch to using the mutter primary monitor APIs (3.60 KB, patch)
2011-03-09 15:05 UTC, Alexander Larsson
none Details | Review
Enable the workspaces_only_on_primary feature of mutter (1.99 KB, patch)
2011-03-09 15:05 UTC, Alexander Larsson
none Details | Review
Add and export shell_global_get_primary_monitor_index (1.67 KB, patch)
2011-03-09 15:06 UTC, Alexander Larsson
none Details | Review
Only show the primary monitor region in the workspace thumbnails (4.18 KB, patch)
2011-03-09 15:06 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor in the workspace thumbnails (5.94 KB, patch)
2011-03-09 15:06 UTC, Alexander Larsson
none Details | Review
Only show windows from the primary monitor on the overview workspace (8.07 KB, patch)
2011-03-09 15:07 UTC, Alexander Larsson
none Details | Review
Move the font color CSS rule from .workspaces-view to .window-caption (827 bytes, patch)
2011-03-09 15:07 UTC, Alexander Larsson
none Details | Review
Add workspaces on non-primary monitors (8.04 KB, patch)
2011-03-09 15:07 UTC, Alexander Larsson
none Details | Review
Always reserve space in all workspaces on a drag (3.18 KB, patch)
2011-03-09 15:08 UTC, Alexander Larsson
none Details | Review
overview: hidden workspace thumbnails should not stick out on other monitor (1.21 KB, patch)
2011-03-09 15:09 UTC, Alexander Larsson
none Details | Review
Constrain zoomed overview windows to the current monitor (1.40 KB, patch)
2011-03-09 15:09 UTC, Alexander Larsson
none Details | Review
Add MetaScreen::monitors-changed signal (1.91 KB, patch)
2011-03-16 10:47 UTC, Alexander Larsson
committed Details | Review
Add api to get the primary monitor of the screen (3.16 KB, patch)
2011-03-16 10:48 UTC, Alexander Larsson
committed Details | Review
Track the monitor for each window (3.54 KB, patch)
2011-03-16 10:48 UTC, Alexander Larsson
reviewed Details | Review
Add API to get the monitor of a window (1.57 KB, patch)
2011-03-16 10:48 UTC, Alexander Larsson
committed Details | Review
Add meta_window_is_on_primary_monitor function (1.53 KB, patch)
2011-03-16 10:48 UTC, Alexander Larsson
committed Details | Review
Split out on_all_workspaces and on_all_workspaces_requested (13.30 KB, patch)
2011-03-16 10:48 UTC, Alexander Larsson
committed Details | Review
Add workspaces_only_on_primary preferences (default FALSE) (4.96 KB, patch)
2011-03-16 10:49 UTC, Alexander Larsson
committed Details | Review
Add signals for when windows change monitors (4.26 KB, patch)
2011-03-16 10:50 UTC, Alexander Larsson
committed Details | Review
Only show workspace and stick/unstick in menu item for primary monitor (3.60 KB, patch)
2011-03-16 10:50 UTC, Alexander Larsson
committed Details | Review
Switch to using the mutter primary monitor APIs (3.60 KB, patch)
2011-03-16 10:53 UTC, Alexander Larsson
committed Details | Review
Enable the workspaces_only_on_primary feature of mutter (1.99 KB, patch)
2011-03-16 10:53 UTC, Alexander Larsson
committed Details | Review
Add and export shell_global_get_primary_monitor_index (1.67 KB, patch)
2011-03-16 10:53 UTC, Alexander Larsson
committed Details | Review
Only show the primary monitor region in the workspace thumbnails (4.18 KB, patch)
2011-03-16 10:53 UTC, Alexander Larsson
committed Details | Review
Only show windows from the primary monitor in the workspace thumbnails (5.92 KB, patch)
2011-03-16 10:53 UTC, Alexander Larsson
committed Details | Review
Only show windows from the primary monitor on the overview workspace (8.06 KB, patch)
2011-03-16 10:54 UTC, Alexander Larsson
committed Details | Review
Move the font color CSS rule from .workspaces-view to .window-caption (827 bytes, patch)
2011-03-16 10:54 UTC, Alexander Larsson
committed Details | Review
Add workspaces on non-primary monitors (8.03 KB, patch)
2011-03-16 10:54 UTC, Alexander Larsson
committed Details | Review
Always reserve space in all workspaces on a drag (3.18 KB, patch)
2011-03-16 10:54 UTC, Alexander Larsson
committed Details | Review
overview: hidden workspace thumbnails should not stick out on other monitor (1.21 KB, patch)
2011-03-16 10:54 UTC, Alexander Larsson
committed Details | Review
Constrain zoomed overview windows to the current monitor (1.41 KB, patch)
2011-03-16 10:55 UTC, Alexander Larsson
committed Details | Review
Handle workspaces going empty due to windows changing monitors (1.83 KB, patch)
2011-03-16 10:55 UTC, Alexander Larsson
committed Details | Review

Description William Jon McCann 2010-02-07 18:45:58 UTC
Didn't see an existing bug for this and since it is something we've only casually discussed before... here we are.

It doesn't really work very well, for a variety of reasons, to zoom out the entire "screen" onto one monitor.
 * The screen size may have a very strange shape that doesn't fit on the monitor well
 * We don't really want users to ever think about the "screen" as a unit.  It is an implementation detail.  Monitors are the units that make sense.
 * The zoom effect was never intended to have windows fly that far.  It doesn't really work.
 * It is too hard to identify windows
 * We break the spatial relationship of windows to monitors
 * It is weird to have monitors go black when all the windows are moved off them
 * We aren't taking advantage of the virtual real estate and that is the entire point of multiple monitors
 * and so on

So the rough plan for a while has been to:
 * Only show the top menu bar on the primary monitor.
 * Only show the message tray on the primary monitor.
 * Display the activities overview on the primary monitor only.
 * The primary monitor may be changed using the display settings in the control center (not yet implemented)
 * Show the equivalent of the Window picker on all non-primary monitors without zooming out.
 * Only the primary monitor will use workspaces.  Non-primary monitors should remain stable as workspaces change.  Some of the reasons for this (iirc) are discussed in the design doc.

Discussed in separate bugs:
 * Show the app switcher (alt-tab), workpace change, and volume etc confirmations on the monitor closest to the active one (likely where the mouse is).  I think I'm changing my mind about using the message try for them.


What have I missed?
Comment 1 William Jon McCann 2010-02-09 20:48:45 UTC
Not to confuse the issue but to form a bigger picture...
We may want to try to make the upper left most monitor the primary (in LTR locales) unless it is explicitly set by the user.  I think this would work fairly well for most cases.  This obviously is a g-s-d/g-c-c issue.
Comment 2 Dan Winship 2010-02-09 22:01:56 UTC
(In reply to comment #1)
> We may want to try to make the upper left most monitor the primary (in LTR
> locales) unless it is explicitly set by the user.  I think this would work
> fairly well for most cases.  This obviously is a g-s-d/g-c-c issue.

This contradicts gnome-panel's heuristic (and therefore bug 608647), which prefers the internal laptop monitor to any external monitor
Comment 3 William Jon McCann 2010-02-09 22:04:13 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > We may want to try to make the upper left most monitor the primary (in LTR
> > locales) unless it is explicitly set by the user.  I think this would work
> > fairly well for most cases.  This obviously is a g-s-d/g-c-c issue.
> 
> This contradicts gnome-panel's heuristic (and therefore bug 608647), which
> prefers the internal laptop monitor to any external monitor

Not necessarily.  By default new monitors can appear to the right of my primary screen.
Comment 4 Alexander Larsson 2010-05-31 13:37:48 UTC
"Only the primary monitor will use workspaces.  Non-primary monitors should
remain stable as workspaces change."

This makes it hard to use e.g. a dual screen setup in many typical ways. For instance, i use a dual head setup where on one workspace i show a fullscreen emacs on each monitor. This lets me see more data on the same time. Similar setups is to use two monitors for e.g. viewing two files in gimp, or debugging on one screen and running the app on the other. 

If the non-primary monitor is stable this means you can't use a workspace for such a setup.
Comment 5 William Jon McCann 2010-06-06 21:24:25 UTC
*** Bug 581833 has been marked as a duplicate of this bug. ***
Comment 6 Sri Ramkrishna 2010-06-07 06:45:12 UTC
I agree with Alex.  We have a dual monitor set up so that we can have more real estate in setups as Alex has described.  If you have things in the stable screen, won't that create distraction?  For instance I have gimp and picassa running in a two monitor setup because I'm doing some photo editing, I switch to another work space to respond to someone on IRC or maybe an open IM window and I still see one half of a setup from my previous workspace.

I guess the question is, what is the motivation behind someone who wants dual monitor?  Are they looking for a 3200x1200 virtual workspace or two discrete 1600x1200 workspaces and does this setup address both?  I'll have to read the relevant design docs on this..

sri
Comment 7 Florian Müllner 2010-07-16 15:49:56 UTC
(In reply to comment #0)
> Didn't see an existing bug for this and since it is something we've only
> casually discussed before... here we are.
> 
> It doesn't really work very well, for a variety of reasons, to zoom out the
> entire "screen" onto one monitor.
>  * The screen size may have a very strange shape that doesn't fit on the
> monitor well
> [...]
> What have I missed?

 * If the monitors differ in vertical resolution, gnome-shell dies a quick and painless death
   (when updating the root-pixmap, e.g. the moment the second monitor activates)
Comment 8 Sam Pattuzzi 2010-11-09 11:33:27 UTC
Looks like this bug has been left for a couple of month. Could we have an update on this? It is an issue that affects me as I regularly use multiple monitors and I find the was they are dealt with currently is horrible.

To weigh in on the static monitor while switching workspaces vs linked monitors. Why not have the two monitors independent? So you can mix and match the workspaces. If people want to use the screens linked together there could be a separate keyboard short cut for doing that.

The most logical way to deal with multiple monitors seems to be treating them as completely separate "computers" (from a lay users point of view) that can share windows between each other.
Comment 9 Robert Bruce Park 2010-11-10 15:28:42 UTC
+1, the way secondary monitors are currently handled (blanking them) is terrible. My primary display is relatively small (laptop) screen, my secondary display is an enormous 24" widescreen. Having the workspaces shrink onto the smaller screen makes them unusably tiny. I'd like to see each screen have independant workspaces (ie, you trigger the activities menu and each monitor shrinks to show workspaces only existing on it's own monitor). 

It would be ok if they were "linked" (change to workspace 2 on the left screen and then right screen changes as well), which I believe is the behavior expected by Alexander Larsson. But my primary concern is that the workspace view shows only windows from the left monitor on the left monitor, and only windows from the right monitor on the right monitor.

This is the best way for dealing with irregular screen shapes, because every screen will simply be displaying at 1/4 size four times on each screen (so it always fits well because it's always 1/2 the width and 1/2 the height) as opposed to the current situation where you're trying to squeeze four 4:1 "screens" onto a single 4:3 monitor.

Thanks guys, other than this GNOME Shell is looking incredible. As soon as this is fixed I intend to use GNOME Shell as my primary DE. Keep up the great work ;-)
Comment 10 Florian Müllner 2010-11-22 11:08:03 UTC
*** Bug 635507 has been marked as a duplicate of this bug. ***
Comment 11 Johannes Schmid 2010-11-22 11:15:43 UTC
Created attachment 175018 [details]
overview with dual monitor and 6 windows

This is how it currently looks like in overview-relayout - it's not really nice.

Small addition: The "hot corner" doesn't work if the is a second monitor to the left...
Comment 12 Sean 2010-11-25 22:16:33 UTC
In response to the original design and to comment #4, I want to voice my needs with multiple monitors and why I think having the secondary monitor be stable is critical.  Essentially, my secondary monitor is an informational display 50% of the time, is off 45% of the time, and is a real citizen of my virtual workspaces 5% of the time.

It is beyond frustrating that changing between my four workspaces on my primary monitor also changes what's on my secondary monitor.  I often have my work log (web page with my tasks and such for work), a debugger, or IRC on the secondary monitor.  If I've got my work log there and I'm using two workspaces to switch between a browser and a terminal, it's irrtating that I lose the work log if I switch between them.  It's irritating that IRC is only visible if I'm looking at once of my workspaces.

However, comment #4 indicates that other people want it to work differently.  As much as I hate to say it, this may be a case where an option is necessary... in the end, multiple monitors are used in different ways for different tasks by different people.

What I would love the most is to just have each monitor be its own view into the workspaces.  I'd love to be able to change the workspace of each monitor independently.  If i set both monitors to the same workspace, it would more or less act as if mirrored (which is easy with the compositor, of course).  Other people might not want the workspaces on the secondary monitor, and other people want their desktop (and hence workspaces) to just be extended.

Also keep in mind that osme people use more than two monitors.  I have colleagues that use three on a frequent basis.  Their needs are, again, different than my own or commenter #4's.

Doesn't need to be a complex set of options, but some way to indicate how I want to use the secondary monitor would be of great help.  I could see the options being:

(1) Extended desktop, sharing a single workspace
(2) Fixed workspaces on secondary monitors
(3) Independent workspaces on secondary monitors

Although I really think you could just skip supporting (2) if you had the UI designed cleanly enough (that part I'm not helpful with, unfortunately).

All I know for sure is that linking the workspaces together is TOTALLY BROKEN for my needs, and almost entirely invalidates the usefulness of workspaces entirely.  This is what I'm stuck with on Metacity and Compiz today and I can't tell you how tempted I am to just return my second monitor as it's borderline useless the way things are now.
Comment 13 Rovanion Luckey 2010-12-08 14:53:27 UTC
Another example would be with the proposed removal of the maximize button from the mutter borders. Instead of using the as proposed removed maximize button, the user pushes the window up to the top edge of the screen in a Aero snap like move and the window is maximized.

The issue arises when the user has no endless top edge, when the user has another screen above the main screen.
Comment 14 Federico Mena Quintero 2010-12-08 23:51:10 UTC
I started http://live.gnome.org/GnomeShell/Design/Whiteboards/MultipleMonitors to brainstorm this.  I think a single option to link monitors together (workspaces span all monitors vs. workspaces are independent in each monitor) would let people work in all the ways they have mentioned so far without things getting unwieldy.
Comment 15 Jasper St. Pierre (not reading bugmail) 2010-12-09 02:18:56 UTC
Right, those are the two cases (with the first, you could drag one workspace to another monitor). The hard part is making the "link workspaces" work. There's no guarantee that the user will be able to see a full rectangle: they could have two different resolutions on their monitors (17" vs. 19") or have them mounted in an L-shape.. Or you could be this guy: http://data.glacicle.org/screens/6mon.png

The problem is making both cases work well. Do you want an "L"-shaped workspace, or how do you flip workspaces from a higher-res-screen to a lower-res-screen? Having one option naturally is quite a bit of work: both together would be a bit insane.
Comment 16 William Jon McCann 2010-12-09 03:37:01 UTC
Jasper: don't mark my bugs needinfo please.
Comment 17 Jasper St. Pierre (not reading bugmail) 2010-12-09 03:47:32 UTC
Whoops, did I? Sorry about that.
Comment 18 Federico Mena Quintero 2010-12-09 19:18:59 UTC
I just revised the wiki page.  Note that now it explicitly disallows moving workspaces across monitors:  in the "unlinked" case, each monitor has completely independent sets of workspaces.

I also added some notes about behavior when moving windows, and some implementation notes for how to make this work with RANDR's view of the world.
Comment 19 Federico Mena Quintero 2010-12-09 20:12:30 UTC
The wiki page has moved to http://live.gnome.org/GnomeShell/DesignerPlayground/MultipleMonitors
Comment 20 Alexander Larsson 2011-03-04 15:18:31 UTC
Created attachment 182469 [details] [review]
exposing MetaWindow.move() and .resize() in javascript and adding .move_frame()

.move() and .resize() are straightforward exposures of existing methods
.move_frame() is a version of .move() that moves a window using the
frame's origin as the reference point for moving the window. If the
window doesn't have a frame, then it besides the same as .move()

https://bugzilla.gnome.org/show_bug.cgi?id=642355
Comment 21 Alexander Larsson 2011-03-04 15:18:37 UTC
Created attachment 182470 [details] [review]
Add MetaScreen::monitors-changed signal
Comment 22 Alexander Larsson 2011-03-04 15:18:42 UTC
Created attachment 182471 [details] [review]
Add api to get the primary monitor of the screen

We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
Comment 23 Alexander Larsson 2011-03-04 15:18:46 UTC
Created attachment 182472 [details] [review]
Track the primary monitor for each window
Comment 24 Alexander Larsson 2011-03-04 15:18:52 UTC
Created attachment 182473 [details] [review]
Add API to get the primary monitor of a window
Comment 25 Alexander Larsson 2011-03-04 15:18:57 UTC
Created attachment 182474 [details] [review]
Split out on_all_workspaces and on_all_workspaces_requested

Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.

on_all_workspaces means this window is visible on all workspaces.

on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.

Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
Comment 26 Alexander Larsson 2011-03-04 15:19:02 UTC
Created attachment 182475 [details] [review]
Add workspaces_only_on_primary preferences (default FALSE)

This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
Comment 27 Alexander Larsson 2011-03-04 15:19:07 UTC
Created attachment 182476 [details] [review]
Add signals for when windows change primary monitors

This is useful in order to track e.g. which windows are on the primary
monitor.
Comment 28 Alexander Larsson 2011-03-04 15:20:12 UTC
Created attachment 182477 [details] [review]
Bail early from check over all permutations

If we're already doing worse than the best so far there is
no need to continue checking this particular permutation.
Comment 29 Alexander Larsson 2011-03-04 15:20:17 UTC
Created attachment 182478 [details] [review]
dnd: Avoid division by zero, etc for zero-size actors

When rescaling due to a possible parent actor resize avoid problems
if any of the sizes is zero.
Comment 30 Alexander Larsson 2011-03-04 15:20:22 UTC
Created attachment 182479 [details] [review]
Switch to using the mutter primary monitor APIs
Comment 31 Alexander Larsson 2011-03-04 15:20:27 UTC
Created attachment 182480 [details] [review]
Enable the workspaces_only_on_primary feature of mutter
Comment 32 Alexander Larsson 2011-03-04 15:20:31 UTC
Created attachment 182481 [details] [review]
Add and export shell_global_get_primary_monitor_index
Comment 33 Alexander Larsson 2011-03-04 15:20:36 UTC
Created attachment 182482 [details] [review]
Only show the primary monitor region in the workspace thumbnails

Make the thumbnail the size of the primary monitor and only show
the windows from that area.
Comment 34 Alexander Larsson 2011-03-04 15:20:41 UTC
Created attachment 182483 [details] [review]
Only show windows from the primary monitor in the workspace thumbnails

Also, if windows are dropped on the thumbnail, move them to the primary
monitor.
Comment 35 Alexander Larsson 2011-03-04 15:20:46 UTC
Created attachment 182484 [details] [review]
Only show windows from the primary monitor on the overview workspace

This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
Comment 36 Alexander Larsson 2011-03-04 15:20:51 UTC
Created attachment 182485 [details] [review]
Move the font color CSS rule from .workspaces-view to .window-caption

This is needed once we start seeing window captions outside the
workspaces view (for other monitors).
Comment 37 Alexander Larsson 2011-03-04 15:20:55 UTC
Created attachment 182486 [details] [review]
Add workspaces on non-primary monitors

We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
Comment 38 Alexander Larsson 2011-03-04 15:21:01 UTC
Created attachment 182487 [details] [review]
Always reserve space in all workspaces on a drag

We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
Comment 39 Alexander Larsson 2011-03-04 15:37:33 UTC
All right, this patch series depends on the patch from bug 643786, and the first patch is straight from bug 609258. This makes multihead support *much* *much* better. 

It starts with a bunch of mutter changes that are required, then comes a bunch of gnome-shell patches building on the mutter changes.

There are still a few issues left, but I can work on these after we've landed the initial support:

* For some reason, the first time the overview is shown, the workspace actors
  are tweened in from opacity=0 to 255, on all other times they start from 255. 
  I have been unable to track down the reason for this so far...

* Right now mutter considers a window to be on the monitor where i has most 
  area. This is perhaps not ideal, as discussed on irc. For instance, it makes
  it hard, and in some cases impossible to put a large window on a small monitor
  when there are large monitors beside it. I think we should switch it to use
  the monitor with the center of the window in it, which will give the same 
  result in typical cases where a window only overlaps two monitors.

* When dropping on a workspace/thumbnail we sometimes have to move the window
  to that monitor. Right now there code simply moves the window to the top left
  corner of the monitor. We should be able to do better than this with a bit
  of work.

* Dragging a launcher from the dash to a workspace or thumbnail doesn't 
  consider what monitor to launch it on, so if you e.g. drag the launcher to an
  external monitor it may end up being launched on the primary screen anyway. 
  Fixing this may need extensions to the startup notification framework.

* The window menu shows "always on visible workspace" checked for windows
  on a non-primary monitor. While this is true, its not really what is 
  expected. We should rather hide both the "always on..." and "only on..."
  menu items when on the non-primary monitor.

Thats all folks, have fun reviewing this.
Comment 40 Alexander Larsson 2011-03-04 15:38:56 UTC
Eh, "the first patch is straight from bug 609258", obviously meant bug 642355.
Comment 41 Federico Mena Quintero 2011-03-04 16:45:48 UTC
The Alex gets busy! :)

Do you have publicly accessible branches with your patches?  I'm a bit lazy to am them in by hand right now...
Comment 42 Dan Winship 2011-03-04 17:22:50 UTC
federico: git bz apply
Comment 43 Owen Taylor 2011-03-04 17:33:51 UTC
(In reply to comment #39)
> * Dragging a launcher from the dash to a workspace or thumbnail doesn't 
>   consider what monitor to launch it on, so if you e.g. drag the launcher to an
>   external monitor it may end up being launched on the primary screen anyway. 
>   Fixing this may need extensions to the startup notification framework.

We actually do have the information to
Comment 44 Owen Taylor 2011-03-04 17:43:43 UTC
(In reply to comment #43)
> (In reply to comment #39)
> > * Dragging a launcher from the dash to a workspace or thumbnail doesn't 
> >   consider what monitor to launch it on, so if you e.g. drag the launcher to an
> >   external monitor it may end up being launched on the primary screen anyway. 
> >   Fixing this may need extensions to the startup notification framework.
> 
> We actually do have the information to

Ah, didn't mean to post that, but then accidentally did when reassigning to fmuellner. But what it had occurred to me to say is that we don't necessarily need to pass new information over the startup notification protocol as long as we can associate the resulting windows with the launch action since we're both the WM and the launching process.
Comment 45 Florian Müllner 2011-03-04 17:48:17 UTC
(In reply to comment #39)
> * For some reason, the first time the overview is shown, the workspace actors
>   are tweened in from opacity=0 to 255, on all other times they start from 255. 
>   I have been unable to track down the reason for this so far...

I have reproduced it on master and tracked down the problem. I still have to figure out a proper solution, but it definitively is unrelated to your patches.
Comment 46 Alexander Larsson 2011-03-04 18:45:55 UTC
owen: I guess that is true, we can leave some information hanging around for later use.
Comment 47 Alexander Larsson 2011-03-08 09:08:25 UTC
Created attachment 182803 [details] [review]
overview: hidden workspace thumbnails should not stick out on other monitor

We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
Comment 48 Alexander Larsson 2011-03-08 09:19:23 UTC
Created attachment 182805 [details] [review]
Emit monitor-window-removed when windows are unmanaged

We need this to be able to track windows going away in the gnome-shell
overview for Workspaces on the non-primary monitor, as these get
no window-removed event from the workspace.
Comment 49 Alexander Larsson 2011-03-08 21:25:42 UTC
Created attachment 182871 [details] [review]
Bail early from check over all permutations

If we're already doing worse than the best so far there is
no need to continue checking this particular permutation.
Comment 50 Alexander Larsson 2011-03-08 21:25:58 UTC
Created attachment 182872 [details] [review]
Switch to using the mutter primary monitor APIs
Comment 51 Alexander Larsson 2011-03-08 21:26:13 UTC
Created attachment 182873 [details] [review]
Enable the workspaces_only_on_primary feature of mutter
Comment 52 Alexander Larsson 2011-03-08 21:26:24 UTC
Created attachment 182874 [details] [review]
Add and export shell_global_get_primary_monitor_index
Comment 53 Alexander Larsson 2011-03-08 21:26:39 UTC
Created attachment 182875 [details] [review]
Only show the primary monitor region in the workspace thumbnails

Make the thumbnail the size of the primary monitor and only show
the windows from that area.
Comment 54 Alexander Larsson 2011-03-08 21:26:52 UTC
Created attachment 182876 [details] [review]
Only show windows from the primary monitor in the workspace thumbnails

Also, if windows are dropped on the thumbnail, move them to the primary
monitor.
Comment 55 Alexander Larsson 2011-03-08 21:27:04 UTC
Created attachment 182877 [details] [review]
Only show windows from the primary monitor on the overview workspace

This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
Comment 56 Alexander Larsson 2011-03-08 21:27:14 UTC
Created attachment 182878 [details] [review]
Move the font color CSS rule from .workspaces-view to .window-caption

This is needed once we start seeing window captions outside the
workspaces view (for other monitors).
Comment 57 Alexander Larsson 2011-03-08 21:27:24 UTC
Created attachment 182879 [details] [review]
Add workspaces on non-primary monitors

We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
Comment 58 Alexander Larsson 2011-03-08 21:27:32 UTC
Created attachment 182880 [details] [review]
Always reserve space in all workspaces on a drag

We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
Comment 59 Alexander Larsson 2011-03-08 21:27:45 UTC
Created attachment 182882 [details] [review]
overview: hidden workspace thumbnails should not stick out on other monitor

We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
Comment 60 Alexander Larsson 2011-03-08 21:28:47 UTC
New rebased series, some patches moved to bug 643786 as they make more sense there.
Comment 61 Florian Müllner 2011-03-09 12:50:53 UTC
Review of attachment 182871 [details] [review]:

Looks correct.
Comment 62 Alexander Larsson 2011-03-09 12:58:23 UTC
Comment on attachment 182871 [details] [review]
Bail early from check over all permutations

Attachment 182871 [details] pushed as 16a675b - Bail early from check over all permutations
Comment 63 Alexander Larsson 2011-03-09 15:02:50 UTC
Created attachment 182969 [details] [review]
exposing MetaWindow.move() and .resize() in javascript and adding .move_frame()

.move() and .resize() are straightforward exposures of existing methods
.move_frame() is a version of .move() that moves a window using the
frame's origin as the reference point for moving the window. If the
window doesn't have a frame, then it besides the same as .move()

https://bugzilla.gnome.org/show_bug.cgi?id=642355
Comment 64 Alexander Larsson 2011-03-09 15:03:09 UTC
Created attachment 182971 [details] [review]
Add MetaScreen::monitors-changed signal
Comment 65 Alexander Larsson 2011-03-09 15:03:24 UTC
Created attachment 182972 [details] [review]
Add api to get the primary monitor of the screen

We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
Comment 66 Alexander Larsson 2011-03-09 15:03:34 UTC
Created attachment 182973 [details] [review]
Track the primary monitor for each window
Comment 67 Alexander Larsson 2011-03-09 15:03:43 UTC
Created attachment 182974 [details] [review]
Add API to get the primary monitor of a window
Comment 68 Alexander Larsson 2011-03-09 15:03:57 UTC
Created attachment 182975 [details] [review]
Add meta_window_is_on_primary_monitor function

This is useful in a couple of places to avoid opencoding it.
Comment 69 Alexander Larsson 2011-03-09 15:04:11 UTC
Created attachment 182976 [details] [review]
Split out on_all_workspaces and on_all_workspaces_requested

Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.

on_all_workspaces means this window is visible on all workspaces.

on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.

Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
Comment 70 Alexander Larsson 2011-03-09 15:04:23 UTC
Created attachment 182977 [details] [review]
Add workspaces_only_on_primary preferences (default FALSE)

This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
Comment 71 Alexander Larsson 2011-03-09 15:04:46 UTC
Created attachment 182978 [details] [review]
Add signals for when windows change primary monitors

This is useful in order to track e.g. which windows are on the primary
monitor.
Comment 72 Alexander Larsson 2011-03-09 15:04:58 UTC
Created attachment 182979 [details] [review]
Only show workspace and stick/unstick in menu item for primary monitor

If workspaces_only_on_primary then it makes no sense to have these
menu items on the monitors where workspaces don't take any effect.
Comment 73 Alexander Larsson 2011-03-09 15:05:34 UTC
Created attachment 182980 [details] [review]
Switch to using the mutter primary monitor APIs
Comment 74 Alexander Larsson 2011-03-09 15:05:55 UTC
Created attachment 182981 [details] [review]
Enable the workspaces_only_on_primary feature of mutter
Comment 75 Alexander Larsson 2011-03-09 15:06:04 UTC
Created attachment 182982 [details] [review]
Add and export shell_global_get_primary_monitor_index
Comment 76 Alexander Larsson 2011-03-09 15:06:16 UTC
Created attachment 182983 [details] [review]
Only show the primary monitor region in the workspace thumbnails

Make the thumbnail the size of the primary monitor and only show
the windows from that area.
Comment 77 Alexander Larsson 2011-03-09 15:06:50 UTC
Created attachment 182984 [details] [review]
Only show windows from the primary monitor in the workspace thumbnails

Also, if windows are dropped on the thumbnail, move them to the primary
monitor.
Comment 78 Alexander Larsson 2011-03-09 15:07:06 UTC
Created attachment 182985 [details] [review]
Only show windows from the primary monitor on the overview workspace

This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
Comment 79 Alexander Larsson 2011-03-09 15:07:20 UTC
Created attachment 182986 [details] [review]
Move the font color CSS rule from .workspaces-view to .window-caption

This is needed once we start seeing window captions outside the
workspaces view (for other monitors).
Comment 80 Alexander Larsson 2011-03-09 15:07:32 UTC
Created attachment 182987 [details] [review]
Add workspaces on non-primary monitors

We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
Comment 81 Alexander Larsson 2011-03-09 15:08:55 UTC
Created attachment 182989 [details] [review]
Always reserve space in all workspaces on a drag

We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
Comment 82 Alexander Larsson 2011-03-09 15:09:09 UTC
Created attachment 182990 [details] [review]
overview: hidden workspace thumbnails should not stick out on other monitor

We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
Comment 83 Alexander Larsson 2011-03-09 15:09:20 UTC
Created attachment 182991 [details] [review]
Constrain zoomed overview windows to the current monitor

Additionally, the constraint to not overlap the panel should only happen
on the primary monitor.
Comment 84 Alexander Larsson 2011-03-10 10:11:48 UTC
Comment on attachment 182969 [details] [review]
exposing MetaWindow.move() and .resize() in javascript and adding .move_frame()

This was commited from bug 642355
Comment 85 Florian Müllner 2011-03-10 15:13:51 UTC
(In reply to comment #39)
> * Dragging a launcher from the dash to a workspace or thumbnail doesn't 
>   consider what monitor to launch it on, so if you e.g. drag the launcher to an
>   external monitor it may end up being launched on the primary screen anyway. 
>   Fixing this may need extensions to the startup notification framework.

Another issue I noticed during testing:
when moving all windows from a workspace/thumb to a non-primary monitor, the workspace auto-removal may fail
Comment 86 William Jon McCann 2011-03-13 19:36:01 UTC
*** Bug 611909 has been marked as a duplicate of this bug. ***
Comment 87 Alexander Larsson 2011-03-16 10:47:44 UTC
Created attachment 183508 [details] [review]
Add MetaScreen::monitors-changed signal
Comment 88 Alexander Larsson 2011-03-16 10:48:00 UTC
Created attachment 183509 [details] [review]
Add api to get the primary monitor of the screen

We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
Comment 89 Alexander Larsson 2011-03-16 10:48:13 UTC
Created attachment 183510 [details] [review]
Track the monitor for each window
Comment 90 Alexander Larsson 2011-03-16 10:48:26 UTC
Created attachment 183511 [details] [review]
Add API to get the monitor of a window
Comment 91 Alexander Larsson 2011-03-16 10:48:39 UTC
Created attachment 183512 [details] [review]
Add meta_window_is_on_primary_monitor function

This is useful in a couple of places to avoid opencoding it.
Comment 92 Alexander Larsson 2011-03-16 10:48:59 UTC
Created attachment 183513 [details] [review]
Split out on_all_workspaces and on_all_workspaces_requested

Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.

on_all_workspaces means this window is visible on all workspaces.

on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.

Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
Comment 93 Alexander Larsson 2011-03-16 10:49:16 UTC
Created attachment 183514 [details] [review]
Add workspaces_only_on_primary preferences (default FALSE)

This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
Comment 94 Alexander Larsson 2011-03-16 10:50:11 UTC
Created attachment 183515 [details] [review]
Add signals for when windows change monitors

This is useful in order to track e.g. which windows are on the primary
monitor.
Comment 95 Alexander Larsson 2011-03-16 10:50:32 UTC
Created attachment 183516 [details] [review]
Only show workspace and stick/unstick in menu item for primary monitor

If workspaces_only_on_primary then it makes no sense to have these
menu items on the monitors where workspaces don't take any effect.
Comment 96 Alexander Larsson 2011-03-16 10:53:01 UTC
Created attachment 183517 [details] [review]
Switch to using the mutter primary monitor APIs
Comment 97 Alexander Larsson 2011-03-16 10:53:14 UTC
Created attachment 183518 [details] [review]
Enable the workspaces_only_on_primary feature of mutter
Comment 98 Alexander Larsson 2011-03-16 10:53:24 UTC
Created attachment 183519 [details] [review]
Add and export shell_global_get_primary_monitor_index
Comment 99 Alexander Larsson 2011-03-16 10:53:36 UTC
Created attachment 183520 [details] [review]
Only show the primary monitor region in the workspace thumbnails

Make the thumbnail the size of the primary monitor and only show
the windows from that area.
Comment 100 Alexander Larsson 2011-03-16 10:53:54 UTC
Created attachment 183521 [details] [review]
Only show windows from the primary monitor in the workspace thumbnails

Also, if windows are dropped on the thumbnail, move them to the primary
monitor.
Comment 101 Alexander Larsson 2011-03-16 10:54:06 UTC
Created attachment 183522 [details] [review]
Only show windows from the primary monitor on the overview workspace

This means a bunch of windows will not be visible at all in the overview.
Those will be added back with per-screen workspaces on the non-primary
monitors.
Comment 102 Alexander Larsson 2011-03-16 10:54:17 UTC
Created attachment 183523 [details] [review]
Move the font color CSS rule from .workspaces-view to .window-caption

This is needed once we start seeing window captions outside the
workspaces view (for other monitors).
Comment 103 Alexander Larsson 2011-03-16 10:54:27 UTC
Created attachment 183524 [details] [review]
Add workspaces on non-primary monitors

We create a Workspace with a null metaWorkspace for each
non-primary monitor, showing the windows on these monitors.
These are saved in WorkspaceView.extraWorkspaces.
Comment 104 Alexander Larsson 2011-03-16 10:54:40 UTC
Created attachment 183525 [details] [review]
Always reserve space in all workspaces on a drag

We used to do this only on automatic workspace switch, but that
doesn't work for the multiple monitors case where we want to reserve
space on the extra monitors.
Comment 105 Alexander Larsson 2011-03-16 10:54:54 UTC
Created attachment 183526 [details] [review]
overview: hidden workspace thumbnails should not stick out on other monitor

We clip the entire WorkspacesDisplay to its allocation to avoid things
like the WorkspaceThumbnails sticking out of the primary monitor into
another monitor.
Comment 106 Alexander Larsson 2011-03-16 10:55:04 UTC
Created attachment 183527 [details] [review]
Constrain zoomed overview windows to the current monitor

Additionally, the constraint to not overlap the panel should only happen
on the primary monitor.
Comment 107 Alexander Larsson 2011-03-16 10:55:16 UTC
Created attachment 183528 [details] [review]
Handle workspaces going empty due to windows changing monitors

If a workspace becomes empty due to a window changing to/from the
primary monitor, but not changing its original workspace then we
were not noticing this. This can happen for instance if you drag
a thumbnail window to a non-primary window.
Comment 108 Alexander Larsson 2011-03-16 10:56:43 UTC
New series is a rebase to latest + rename "primary monitor" to monitor on MetaWindow. Also adds a new patch that fixes comment #85
Comment 109 Florian Müllner 2011-03-16 12:17:50 UTC
Review of attachment 183509 [details] [review]:

::: src/core/screen.c
@@ +363,3 @@
+   * primary.
+   */
+  screen->primary_monitor_index = 0;

That sounds like relying on some implementation detail :(

I discussed this part with Owen, and he suggested using gdk_screen_get_primary_monitor() and matching on rectangle identity.
Comment 110 Florian Müllner 2011-03-16 12:56:40 UTC
Review of attachment 183514 [details] [review]:

::: src/core/window.c
@@ +4097,3 @@
+          meta_window_is_on_primary_monitor (window)  &&
+          window->screen->active_workspace != window->workspace)
+        meta_window_change_workspace (window, window->screen->active_workspace);

Doesn't this get in the way of moving a window to a non-active workspace on the primary monitor?
Comment 111 Florian Müllner 2011-03-16 12:57:03 UTC
Review of attachment 183513 [details] [review]:

Looks mostly good.

::: src/core/window-private.h
@@ +164,3 @@
+  /* This is true if the client requested sticky, and implies on_all_workspaces == TRUE,
+   * however on_all_workspaces can be set TRUE for other internal reasons too, such as
+   * beingoverride_redirect or being on the non-primary monitor. */

Typo: being override_redirect

::: src/core/window.c
@@ +1579,3 @@
+
+void
+meta_window_update_on_all_workspaces (MetaWindow *window)

Is that needed elsewhere as a replacement for meta_window_set_current_workspace_hint()? meta_workspace_update_window_hints() in core/workspace.c maybe?

@@ +1594,3 @@
+          GList* tmp = window->screen->workspaces;
+
+          /* Add to all mru lists */

grep-ability-nitpick: use of MRU is much more common than mru

@@ +1608,3 @@
+          GList* tmp = window->screen->workspaces;
+
+          /* Remove from mru lists except the windows workspace */

Same as above, plus typo: window's
Comment 112 Florian Müllner 2011-03-16 12:57:04 UTC
Review of attachment 183512 [details] [review]:

Sure.
Comment 113 Florian Müllner 2011-03-16 12:57:15 UTC
Review of attachment 183511 [details] [review]:

Looks good.
Comment 114 Florian Müllner 2011-03-16 12:57:15 UTC
Review of attachment 183510 [details] [review]:

::: src/core/screen.c
@@ +2836,3 @@
+  windows = meta_display_list_windows (screen->display,
+                                       META_LIST_INCLUDE_OVERRIDE_REDIRECT);
+  for (tmp = windows; tmp != NULL; tmp = tmp->next)

Is there a particular reason for iterating over the complete list of windows instead of connecting each window to screen::monitors-changed?
Comment 115 Florian Müllner 2011-03-16 12:57:20 UTC
Review of attachment 183508 [details] [review]:

Looks good.
Comment 116 Florian Müllner 2011-03-16 12:57:27 UTC
Review of attachment 183516 [details] [review]:

In my opinion it would be slightly nicer to show those menu items and have them reflect the property as if the window was on the primary monitor (e.g. when toggled on, the window will show on all workspaces when moved to the primary monitor). But this approach is simple and works just fine, so let's go with it (at least for now).
Comment 117 Alexander Larsson 2011-03-16 13:10:05 UTC
Review of attachment 183509 [details] [review]:

::: src/core/screen.c
@@ +363,3 @@
+   * primary.
+   */
+  screen->primary_monitor_index = 0;

I guess it is an implementation detail, but the xrandr xinerama emulation support does this explicitly, and has done so since forever.

Initially I tried to remove all the mutter multi-monitor support instead relying on using the gdk code, but that ended up not really working well. The main problem is that gdk code resorts the monitors, so the indexes are not comparable, and additionally we need the Xinerama indexes, not the xrandr ones.

Matching on rectangle identity will work, but it might get the "wrong" result in the mirroring case. Although that is unlikely to matter.

Additionally it will create complexity in the mutter xinerama handling, as we need to make sure gdk gets to process all the events related to the xrandr event (configure+xrandr event) before we can rely on what gdk_screen_get_primary_monitor() returns.

I dunno if this complexity is worth it but i can pursue if you insist.
Comment 118 Alexander Larsson 2011-03-16 13:22:16 UTC
Review of attachment 183514 [details] [review]:

::: src/core/window.c
@@ +4097,3 @@
+          meta_window_is_on_primary_monitor (window)  &&
+          window->screen->active_workspace != window->workspace)
+        meta_window_change_workspace (window, window->screen->active_workspace);

Hmm, i guess it might, since this will cause meta_window_move() to put the window on the active workspace.
I seem to remember having some problem when not doing this change though. I need to look into that.
Comment 119 Alexander Larsson 2011-03-16 13:25:05 UTC
Review of attachment 183510 [details] [review]:

::: src/core/screen.c
@@ +2836,3 @@
+  windows = meta_display_list_windows (screen->display,
+                                       META_LIST_INCLUDE_OVERRIDE_REDIRECT);
+  for (tmp = windows; tmp != NULL; tmp = tmp->next)

A screen resize event is generally very uncommon, so doing the full traversal on this uncommon event saves a lot of effort having all windows having to connect/disconnect from this signal.
Comment 120 Alexander Larsson 2011-03-16 13:28:03 UTC
Review of attachment 183516 [details] [review]:

If we do nothing, then the menu will do approximately what you wanted. This is kinda problematic though. First of all you expect to be able to change the items and suddenly have the window not show on all workspaces (while still being on the non-primary window). Secondly it just seems contrary to the "new" definition of a workspace. The non-primary monitors are conceptually not on a workspace at all, so being on "all workspaces" doesn't really make sense for them.
Comment 121 Alexander Larsson 2011-03-16 13:37:23 UTC
Comment on attachment 183508 [details] [review]
Add MetaScreen::monitors-changed signal

Attachment 183508 [details] pushed as 0ff602b - Add MetaScreen::monitors-changed signal
Comment 122 Florian Müllner 2011-03-16 13:45:42 UTC
Review of attachment 183515 [details] [review]:

::: src/core/screen.c
@@ +86,3 @@
   WORKSPACE_SWITCHED,
+  MONITOR_WINDOW_ADDED,
+  MONITOR_WINDOW_REMOVED,

I'm not too fond of those names - how about window-entered-primary/window-left-primary?

@@ +2851,3 @@
+  windows = meta_display_list_windows (screen->display,
+                                       META_LIST_INCLUDE_OVERRIDE_REDIRECT);
+  for (tmp = windows; tmp != NULL; tmp = tmp->next)

Again, wouldn't it be nicer to do this from a handler to screen::monitors-changed in window.c?
Comment 123 Florian Müllner 2011-03-16 13:52:03 UTC
(In reply to comment #117)
> I dunno if this complexity is worth it but i can pursue if you insist.

I'd like to relay that question to Owen.
Comment 124 Florian Müllner 2011-03-16 13:54:46 UTC
(In reply to comment #119)
> A screen resize event is generally very uncommon, so doing the full traversal
> on this uncommon event saves a lot of effort having all windows having to
> connect/disconnect from this signal.

OK.
Comment 125 Florian Müllner 2011-03-16 14:00:52 UTC
(In reply to comment #120)
> Secondly it just seems contrary to the "new"
> definition of a workspace. The non-primary monitors are conceptually not on a
> workspace at all, so being on "all workspaces" doesn't really make sense for
> them.

I agree, that's why I meant that the menu should reflect the window state on the primary monitor, even while on another monitor.
(But really, I consider the sticky function a fringe relict not worth arguing about)
Comment 126 Alexander Larsson 2011-03-16 14:03:30 UTC
Review of attachment 183513 [details] [review]:

::: src/core/window.c
@@ +1579,3 @@
+
+void
+meta_window_update_on_all_workspaces (MetaWindow *window)

I don't think so. on_all_workspaces only change when on_all_workspaces_requested is set or when the window is moved to another monitor atm, and all these result in a update_on_all_workspaces.()

meta_workspace_update_window_hints() is a public function though. What is the reason for calling this ever from some external code?
Comment 127 Alexander Larsson 2011-03-16 14:07:50 UTC
Review of attachment 183515 [details] [review]:

::: src/core/screen.c
@@ +86,3 @@
   WORKSPACE_SWITCHED,
+  MONITOR_WINDOW_ADDED,
+  MONITOR_WINDOW_REMOVED,

Right now they get sent for all monitors, but changing it to only to/from primary would work too.
Comment 128 Alexander Larsson 2011-03-16 14:15:18 UTC
(In reply to comment #125)
> 
> I agree, that's why I meant that the menu should reflect the window state on
> the primary monitor, even while on another monitor.
> (But really, I consider the sticky function a fringe relict not worth arguing
> about)

Ah, i see what you mean. Yeah, i guess that would make some sense.
Comment 129 Alexander Larsson 2011-03-16 15:24:02 UTC
(In reply to comment #127)
> Review of attachment 183515 [details] [review]:
> 
> ::: src/core/screen.c
> @@ +86,3 @@
>    WORKSPACE_SWITCHED,
> +  MONITOR_WINDOW_ADDED,
> +  MONITOR_WINDOW_REMOVED,
> 
> Right now they get sent for all monitors, but changing it to only to/from
> primary would work too.

Ah, no. We need the full info to implement e.g. workspace instances for non-primary monitors (they need to show only the windows on that particular monitor).
Comment 130 Owen Taylor 2011-03-16 16:09:26 UTC
(In reply to comment #117)
> Review of attachment 183509 [details] [review]:
> 
> ::: src/core/screen.c
> @@ +363,3 @@
> +   * primary.
> +   */
> +  screen->primary_monitor_index = 0;
> 
> I guess it is an implementation detail, but the xrandr xinerama emulation
> support does this explicitly, and has done so since forever.
>
> Initially I tried to remove all the mutter multi-monitor support instead
> relying on using the gdk code, but that ended up not really working well. The
> main problem is that gdk code resorts the monitors, so the indexes are not
> comparable, and additionally we need the Xinerama indexes, not the xrandr ones.

Long-term the fact that _NET_WM_FULLSCREEN_MONITORS uses the indices from a deprecated extension and that xrandr uses different indices is something that needs to be fixed in spec land. Especially since for an app to *use* the property it needs to be able to resolve the indicies, so does some GDK app link to Xinerama itself and monitor that separate from GDK?
 
> Matching on rectangle identity will work, but it might get the "wrong" result
> in the mirroring case. Although that is unlikely to matter.
> 
> Additionally it will create complexity in the mutter xinerama handling, as we
> need to make sure gdk gets to process all the events related to the xrandr
> event (configure+xrandr event) before we can rely on what
> gdk_screen_get_primary_monitor() returns.

Well, this problem exists in the broader space of Mutter + GNOME Shell in that we do stuff when the monitor configuration changes, and we use a mix of the Mutter view of monitors and the GDK view of monitors. If we don't fix Mutter to use the GDK view of monitors, we need to fix the shell code to exclusively use Mutter's view of monitors, or we need to make sure that the GDK and Mutter view of monitors update synchronously. Otherwise, I can imagine arbitrary edge case bugs.
 
> I dunno if this complexity is worth it but i can pursue if you insist.

If you have something that works, document the assumptions, file a bug if the GDK vs. Mutter synchronization problem sounds like something that we need to fix, move on.
Comment 131 Florian Müllner 2011-03-16 17:26:56 UTC
Review of attachment 183520 [details] [review]:

::: js/ui/workspaceThumbnail.js
@@ +140,3 @@
  * @metaWorkspace: a #Meta.Workspace
  */
+function WorkspaceThumbnail(metaWorkspace, monitorIndex) {

Not sure if the monitorIndex parameter makes sense - it's always the primary monitor by design anyway.

If left like this, the additional parameter should be added to the doc comment above.

@@ +450,3 @@
         this._porthole = {
+            x: monitor.x,
+            y: monitor.y + panelHeight,

Nope. The panel is only on the primary monitor, so unless monitor is the primary monitor, this is wrong.

Again, I wonder if it makes sense to just make the assumption explicit and use

let monitor = global.get_primary_monitor();
...
Comment 132 Florian Müllner 2011-03-16 17:27:00 UTC
Review of attachment 183523 [details] [review]:

Sure.
Comment 133 Florian Müllner 2011-03-16 17:27:13 UTC
Review of attachment 183519 [details] [review]:

Looks good.
Comment 134 Florian Müllner 2011-03-16 17:27:15 UTC
Review of attachment 183525 [details] [review]:

Looks right.
Comment 135 Florian Müllner 2011-03-16 17:27:27 UTC
Review of attachment 183526 [details] [review]:

Sure. From testing, I'd prefer Owen's suggestion in bug 641877 (e.g. don't hide the thumbnails at all if located between monitors) - I've occasionally triggered the thumbnails by accident while changing monitors, or failed to trigger it due to overshooting to the next monitor ...
Comment 136 Florian Müllner 2011-03-16 17:27:36 UTC
Review of attachment 183518 [details] [review]:

Looks good.
Comment 137 Florian Müllner 2011-03-16 17:27:40 UTC
Review of attachment 183517 [details] [review]:

Sure.
Comment 138 Florian Müllner 2011-03-16 17:28:05 UTC
Review of attachment 183527 [details] [review]:

::: js/ui/workspace.js
@@ +226,3 @@
+        if (monitorIndex == global.get_primary_monitor_index()) {
+            monitor.y += Main.panel.actor.height;
+            monitor.height -= Main.panel.actor.height;

That reads slightly odd - it's not like the panel actually shrinks monitors ;)

Maybe just rename monitor to workArea/availArea or something?
Comment 139 Florian Müllner 2011-03-16 17:28:11 UTC
Review of attachment 183528 [details] [review]:

Looks right (except me not liking the signal names ...)
Comment 140 Florian Müllner 2011-03-16 17:28:19 UTC
Review of attachment 183521 [details] [review]:

OK.

::: js/ui/workspaceThumbnail.js
@@ +173,3 @@
         let monitor = global.get_monitors()[this.monitorIndex];
+        this._portholeX = monitor.x;
+        this._portholeY = monitor.y;

Looks unnecessary - _portholeX/Y are update in setPorthole() anyway.

@@ +404,3 @@
             let metaWindow = win.get_meta_window();
+            if (metaWindow.get_monitor() != this.monitorIndex)
+                metaWindow.move_frame(true, this._portholeX, this._portholeY);

As you mentioned already, we could probably do better than placing windows in the upper left corner (possibly doing it in mutter as meta_window_move_monitor() or something), but clearly a future improvement.
Comment 141 Florian Müllner 2011-03-16 17:28:32 UTC
Review of attachment 183522 [details] [review]:

Looks good (some names should be adjusted if you rename the 'monitor-window-added/removed' signals, but I don't think that'll need another review)
Comment 142 Florian Müllner 2011-03-16 17:29:53 UTC
Review of attachment 183524 [details] [review]:

Yup.
Comment 143 Florian Müllner 2011-03-16 17:40:58 UTC
Some additional observations from testing:

 - if the non-primary monitor contains windows from different
   "original" workspaces, there are focus changes on workspace
   switches

 - the behavior when magnified is slightly odd; probably the
   correct fix involves making the magnifier itself "monitor-aware"

 - "sticky" prop is lost when moving from primary to non-primary
Comment 144 Alexander Larsson 2011-03-16 19:29:54 UTC
Comment on attachment 183509 [details] [review]
Add api to get the primary monitor of the screen

Attachment 183509 [details] pushed as f9b5cdf - Add api to get the primary monitor of the screen
Comment 145 Alexander Larsson 2011-03-16 19:34:42 UTC
Attachment 183517 [details] pushed as 079953c - Switch to using the mutter primary monitor APIs
Attachment 183519 [details] pushed as d8bd9f5 - Add and export shell_global_get_primary_monitor_index
Attachment 183523 [details] pushed as 708f1a9 - Move the font color CSS rule from .workspaces-view to .window-caption
Comment 146 Alexander Larsson 2011-03-17 09:14:05 UTC
(In reply to comment #118)
> Review of attachment 183514 [details] [review]:
> 
> ::: src/core/window.c
> @@ +4097,3 @@
> +          meta_window_is_on_primary_monitor (window)  &&
> +          window->screen->active_workspace != window->workspace)
> +        meta_window_change_workspace (window,
> window->screen->active_workspace);
> 
> Hmm, i guess it might, since this will cause meta_window_move() to put the
> window on the active workspace.
> I seem to remember having some problem when not doing this change though. I
> need to look into that.

So, we really need to do this. If a window is on a non-primary monitor that means its always visible. If it for some reason moves (user dragged it, or the app moved it) so that we cross into the primary monitor we don't want the window to suddenly disappear.

The only place this is a problem is when dragging a window from a non-primary monitor to a non-active workspace thumbnail. However, in that case we handle this by first doing the move and then the workspace switch. 

I'm adding some extra comments to clarify this though.
Comment 147 Alexander Larsson 2011-03-17 13:45:26 UTC
All patches updated according to feedback and commited.
Remaining issues will be splitted up to separate bugs, blocking a multihead tracker bug.
Comment 148 Vít Ondruch 2011-03-30 17:32:56 UTC
Where is the settings which will choose if the monitors are independent or single big screen? It should be part of Display settings IMO but I can't see it there.