Created attachment 141676 [details] [review]
Improve support for multihead setups

Fix panel, run dialog, app switcher, and looking glass to limit
themselves to the primary monitor.

The overview is also limited to the primary monitor now (with the
other monitors being blacked out), although the workspaces within the
overview are shaped like the full "screen" (the bounding box of all
monitors). To be fixed later.

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

Comment on attachment 141676 [details] [review]
Improve support for multihead setups

No real comments on the JS portions - it will obviously evolve with our UI conception for this.

Comments on the C portions:

 - Using Mutter API's rather than GDK API's would allow MUTTER_DEBUG_XINERAMA=1
   to be used (though the aspect ratio of dividing the screen in half
vertically
   may be too different for that to be very useful.)

   The mutter API's would have to be publicized.

   I wouldn't suggest using the mutter terminology in gnome-shell, it's just
   too weird (a monitor is a "xinerama")

   No strong feelings on which way to go with this.

 - The randr terminology is "Primary Monitor" not "Main Monitor" might as well
stick to this.

 - I think it would be better to expose monitors as rectangles - there's no
reason the main monitor has to start at 0,0 (other than fits-law for
Activities)

   It's not even clear that C wrappers are needed, though it requires the:

     let r = new Gdk.Rectangle();
     Gdk.Screen.get_default().get_monitor_geometry(0, r);

   workaround for out properties, and maybe that's worth wrapping into a
GdkRectangle * returning function to avoid compat problems later. (Would also
abstract the mutter-vs.-gdk issue.)

(In reply to comment #3)
>  - Using Mutter API's rather than GDK API's would allow MUTTER_DEBUG_XINERAMA=1
>    to be used (though the aspect ratio of dividing the screen in half
> vertically
>    may be too different for that to be very useful.)

That seemed like a bad idea to me, since then mutter/shell would see multiple monitors, but apps running inside it would not...

>  - I think it would be better to expose monitors as rectangles - there's no
> reason the main monitor has to start at 0,0 (other than fits-law for
> Activities)

When I swap the monitors around with gnome-display-properties, the panel always moves itself to the top-left. Hm... though I guess it's maybe not guaranteed that that's monitor 0? And I guess with some layouts, 0,0 would be offscreen.

OK, yeah, if we can't make that assumption then the easy fix of s/screen_width/main_monitor_width/ won't work.

(The new overview code was going to need to work in terms of rectangles anyway.)

Very few apps care about (In reply to comment #4)
> (In reply to comment #3)
> >  - Using Mutter API's rather than GDK API's would allow MUTTER_DEBUG_XINERAMA=1
> >    to be used (though the aspect ratio of dividing the screen in half
> > vertically
> >    may be too different for that to be very useful.)
> 
> That seemed like a bad idea to me, since then mutter/shell would see multiple
> monitors, but apps running inside it would not...

Apps don't care much about monitors - stuff like placing dialogs, maximizing windows, etc, is mostly done by the WM. Some things will break (menus not being forced onto the monitor, etc), but it's probably good enough for testing.

You could switch Mutter to use a 2x2 grid rather than a 2x1 grid - then GDK and Mutter would be in sync and you could set both envvars.... but the monitors would be really tiny.

Created attachment 142137 [details] [review]
Improve support for multihead setups

Same as before, but via meta_screen_get_monitors() now

Created attachment 142163 [details] [review]
Improve support for multihead setups

now with meta_screen_get_n_monitors/meta_screen_get_monitor_geometry

Comment on attachment 142163 [details] [review]
Improve support for multihead setups

Two overall comments:

1) We could really use some sort of dialog abstraction; don't need to do it in this patch, but a lot of stuff lately has involved changing altTab, LG, and the overview.

2) Can you add say shell_global_get_primary_size (ShellGlobal *global, int *width, int *height) ?

Then the code could just be let [x, y, width, height] = global.get_primary_geometry()instead of get_monitors()[0]..

Created attachment 144402 [details] [review]
Improve support for multihead setups

I've now added

GdkRectangle *shell_global_get_primary_monitor (ShellGlobal  *global);
GdkRectangle *shell_global_get_focus_monitor   (ShellGlobal  *global);

in addition to shell_global_get_monitors() (which is now unused, but will
be needed if we want to make the overview display indepently on each
monitor). The panel, overview, app switcher, and looking glass use
get_primary_monitor; the run dialog uses get_focus_monitor, so it pops up
on the same screen as the currently-focused window. I was intending to
move looking glass as well, but the way it currently deals with the panel
made that non-obvious, so I didn't.

My only worry about getting this in for 2.28.0 is that the "overview only
on the primary monitor" is wrong, but not obviously wrong, meaning people
will assume we're doing it on purpose and then complain about it.

Review of attachment 144402 [details] [review]:

Two minor comments, otherwise: full steam ahead.

::: js/ui/lookingGlass.js
@@ +258,1 @@
                                          reactive: true

Not your bug, but we should Math.floor this.

@@ +529,1 @@
         this.actor.y = this._hiddenY;

I'd do this as:

srcX += primary.x;
srcY += primary.y;

Since it seems a little less repetitive.

Attachment 144402 [details] pushed as 2b78d5b - Improve support for multihead setups

The part of lookingGlass._resizeTo that you didn't like was
actually wrong anyway (we base the new position of the lookingglass on
the slave actor's transformed_position, so adding in primary.x and primary.y
is wrong and only worked because they're normally both 0).

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

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