We have several problems with vertical setups:

* message tray for monitors under primary
* panel for monitors above primary
* any monitor above another => maximize by drag-to-top broken

At the moment we're focusing on fixing side-by-side multihead though.

another bug related to vertical setup.

I'm using a vertical setup where a laptop is beneath a large monitor.

On a setup where the primary monitor is the laptop's, drag and drop on the large monitor is broken. The window goes jumpy as if theres something blocking it from entering the center of the larger screen. 

recording of the issue: http://www.youtube.com/watch?v=tcoOoFJlShg

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

Not exactly a "me too" comment, but a justification for why vertical stacking is important:

Some chipsets have only a limited area available for 3D acceleration (see bug #645087). Unless there are plans to make gnome-shell function in an unaccelerated environment (which would, IMHO, improve usability, since one does not expect to loose functionality when plugging in a second monitor), the only choice for those of us with these chipsets who wish to use gnome-shell is to switch to a vertical-stacking mode (at least so long as the sum of our monitors' vertical spans remains within the accelerated area).

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

*** This bug has been marked as a duplicate of bug 648370 ***

Accidentally marked the duplicate the wrong way

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

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

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

The simplest fix might be:

    - If there are monitors above the monitor that is supposed to be
      primary, then reassign primary status to the top-most monitor
      above the original primary.

    - If there are monitors below the primary, then put the message tray
      on the bottom-most monitor below the primary

I don't think there are any real problems with moving the message tray off the primary monitor. But moving the panel without moving "primary" with it would be weird, since it would mean that when you clicked the Activities button on the top monitor, it would activate the overview on the bottom/middle monitor, which would be weird.

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

The original intent was to attempt to use the top left monitor for the primary unless the user overrides it.

Also, "hidden" notification bar on lower monitor hijacks clicks on upper 1cm of lower monitor.

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

Created attachment 189924 [details] [review]
layout: new file handling shell layout

Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.

Created attachment 189925 [details] [review]
layout: deal better with vertically-stacked monitors

If there is a monitor above the "primary" monitor, then make the
topmost monitor be the primary. Likewise, figure out which monitor is
the bottom-most monitor below the primary monitor, and put the message
tray there, rather than necessarily on the primary.

FYI, the other inspiration for this patchset was getting the overview to not draw over the on-screen keyboard. I have further patches to have the LayoutManager keeping track of the "content area" based on whether or not the keyboard is displaying at the bottom of the screen.

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

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

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

Review of attachment 189924 [details] [review]:

Looks good except for _isAboveOrBelow(), which doesn't look like it'll work as advertised.

::: js/ui/layout.js
@@ +14,3 @@
+LayoutManager.prototype = {
+    _init: function () {
+        this._rtl = (St.Widget.get_default_direction() == St.TextDirection.RTL);

Do we care about direction changes?
(probably not, as right now it'd require calling St.Widget.set_default_direction() directly, and for locale-switching from g-c-c to work there are a bunch of more important bits missing anyway ...)

@@ +23,3 @@
+    },
+
+    init: function() {

I assume the _init/init split is to access Main.panel in _updateHotCorners without relying on the order in which objects are initialized in main()? Makes sense, but could probably use a small comment.

@@ +101,3 @@
+    },
+
+    _isAboveOrBelowPrimary: function(monitor) {

Looks like it belongs in the next patch.

@@ +109,3 @@
+        } else {
+            if (monitor.x == primary.x)
+                return true;

I'll be honest, I don't really understand this function - so if the left edges align, the monitor is "above or below" the primary, but not if the right edges align (vice-versa for RTL)? Why?

@@ +114,3 @@
+        if (monitor.x <= primary.x &&
+            (monitor.x + monitor.width) >= (primary.x + primary.width))
+            return true;

And when the monitor happens to be smaller than the primary? Don't we miss a case like

--------
|
|  p r i m a r y
|___________________|
  |
  |  o t h e r 
  |______________|

::: js/ui/panel.js
@@ +548,2 @@
+function PanelCorner(panel, side) {
+    this._init(panel, side);

I don't quite see how that change relates to the rest of the patch. Is it really necessary or should it better be split out?

Review of attachment 189925 [details] [review]:

Looks good (but _isAboveOrBelowPrimary() should be moved here)

(In reply to comment #22)
> +        this._rtl = (St.Widget.get_default_direction() ==
> St.TextDirection.RTL);
> 
> Do we care about direction changes?
> (probably not, as right now it'd require calling
> St.Widget.set_default_direction() directly

Well, environment.js says:

    // Set the default direction for St widgets (this needs to be done before any use of St)
    if (Gtk.Widget.get_default_direction() == Gtk.TextDirection.RTL) {
        St.Widget.set_default_direction(St.TextDirection.RTL);
    }

although st_widget_set_default_direction() itself doesn't have that same warning. But yeah, it's assumed that this does not change. (I don't think there's any way to change the locale in the UI that would be less work to implement than "save state and restart" would be.)

> I'll be honest, I don't really understand this function - so if the left edges
> align, the monitor is "above or below" the primary, but not if the right edges
> align (vice-versa for RTL)? Why?

Hm... I had some reason for this, but I don't remember now. I guess I'll change it so that if there's any horizontal overlap they're considered stacked.

> +function PanelCorner(panel, side) {
> +    this._init(panel, side);
> 
> I don't quite see how that change relates to the rest of the patch. Is it
> really necessary or should it better be split out?

Previously, Main.start() created the panel, and then later called Main._relayout(), which would set the initial panel size and position. Now, the panel lays itself out at the end of its _init(). Which means that PanelCorner cannot refer to Main.panel when it's being laid out for the first time, because that hasn't been set yet.

It could be split out anyway though, since it's silly for PanelCorner to be referring to its parent via someone else's global variable anyway.

(In reply to comment #24)
> (In reply to comment #22)
> > Do we care about direction changes?
> [...]
> yeah, it's assumed that this does not change.

OK with me. The UI in control center currently requires a logout anyway, and to make it work differently there are much more challenging problems to solve (particularly on the gtk+ side) ...


> > I'll be honest, I don't really understand this function - so if the left edges
> > align, the monitor is "above or below" the primary, but not if the right edges
> > align (vice-versa for RTL)? Why?
> 
> Hm... I had some reason for this, but I don't remember now. I guess I'll change
> it so that if there's any horizontal overlap they're considered stacked.

Sounds good!


> [...]
> It could be split out anyway though, since it's silly for PanelCorner to be
> referring to its parent via someone else's global variable anyway.

Ah, OK. Up to you whether to split it out then (and yes, it's silly ...)

Created attachment 190872 [details] [review]
panel: pass the Panel object to the PanelCorners

rather than having them refer to it via Main.panel

Created attachment 190873 [details] [review]
layout: new file handling shell layout

Remove ShellGlobal's monitor-related methods, and have
Main.layoutManager provide that information instead. Move
Main._relayout() to LayoutManager, and have other objects connect to
the layout manager's 'monitors-changed' signal to know when the screen
geometry has changed.

Created attachment 190874 [details] [review]
layout: deal better with vertically-stacked monitors

If there is a monitor below the primary monitor, then put the message
tray there, rather than necessarily on the primary.

=====

Matthias pointed out that if we want to enforce "primary must be on top",
then we should do that in the control center, or else the panel will be
shown on the wrong monitor there. So the updated patch only does the
"move message tray to bottom" part. (And if people complain "it's weird
when there's another monitor above the primary monitor", we can just
tell them, "don't do that then".)

Review of attachment 190873 [details] [review]:

Looks good

Review of attachment 190874 [details] [review]:

Looks good; the commit message could mention the rationale for the change though ...

Review of attachment 190872 [details] [review]:

Looks good.

Alex is out on vacation until guadec; somebody else should probably take care of committing the accepted-commit-now patches in the meantime.

(In reply to comment #32)
> Alex is out on vacation until guadec; somebody else should probably take care
> of committing the accepted-commit-now patches in the meantime.

Dan wrote the patches and he's around, isn't he?

oops, missed that these had been re-reviewed

Attachment 190872 [details] pushed as ae35d0e - panel: pass the Panel object to the PanelCorners
Attachment 190873 [details] pushed as 64b2b4a - layout: new file handling shell layout
Attachment 190874 [details] pushed as 1dfffdb - layout: deal better with vertically-stacked monitors

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

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