GNOME Bugzilla – Bug 663690
vertical dual screens, can't move windows to top monitor
Last modified: 2015-05-14 23:15:59 UTC
I have Bug 645087 I can't run dual screens side by side, they must be arrange vertically. If i set this with the external VGA above the internal laptop display, by default the gnome-shell panel sits at the top of the laptop screen (ie in the middle of the whole desktop space). In this configuration I can't drag a window from the bottom monitor, onto the top monitor. I can move the mouse onto the top screen, and i can use Alt+F7 to partially move a window onto the top screen. If i move the gnome-shell panel to the top of the external screen i can drag windows everywhere.
This is purely a workaround, not a fix, but if you install the gnome-frippery extensions available here http://intgat.tigress.co.uk/rmy/extensions/index.html and use them to delete the bottom panel and then use the gnome-shell-reflection extension available here https://github.com/ahdiaz/gnome-shell-reflection/downloads to move the top panel to bottom, then you are able to properly utilize the top monitor in your configuration (also mine). Thanks to the guys in the Mint Forum thread located here http://forums.linuxmint.com/viewtopic.php?t=85775&f=205 for doing work that fixes this even though this was the intended purpose. They were just trying to make gnome 3 usable and have mostly returned all the functionality taken away by gnome 3.
*** Bug 668123 has been marked as a duplicate of this bug. ***
Tried this on the latest version of gnome shell on the ubuntu ppa (gnome 3.4), and this problem still exists.
*** Bug 677089 has been marked as a duplicate of this bug. ***
*** Bug 677278 has been marked as a duplicate of this bug. ***
*** Bug 689114 has been marked as a duplicate of this bug. ***
I confirm this bug on gnome-shell with my configuration : - Debian Wheezy 64bits / Linux 3.2.0-4-amd64 - Gnome 3.4.2 - Graphics : AMD FirePro 2460 with proprietary drivers fglrx 8.982.13 - 4 monitors : 1240x1024 (third) left of 1920x1080 (primary) left of 1920x1080 (secondary). If the fourth (1280x1024) is top of the primary, I can't move/drag windows to this screen. I can only drag windows to this screen with the ALT+click+drag option BUT Windows can't take place correctly in this screen and maximisation doesn't work. If I move the gnome-panel to another monitor, all is ok.
*** Bug 689690 has been marked as a duplicate of this bug. ***
I noticed this a long time ago (actually in the gnome 2 days with gnome-panel) and did a little poking at the time and came to the conclusion it was a bug dealing with window struts. a strut (as defined by XDG) always extends from the edge of the outermost monitor to the struts defined position. The shell panel has a strut associated with it, so if the panel is in the middle of two monitors, the strut will completely cover the top monitor. mutter lets a user forcefully drag a window into a strut up to a point with this code I believe: #define MIN_SANE_AREA 100• work_area.y = (workspace->screen->rect.height - MIN_SANE_AREA)/2;• work_area.height = MIN_SANE_AREA;• Of course, we don't need a struts for the panel in gnome-shell. a strut is a way for a panel program to advertise to a window manager where to avoid putting windows. In this case the panel program and the window manager are the same program, so we should be able to communicate that information directly without using struts.
Struts are also used for example to keep right-click menus from being underneath the gnome-shell panel see #641999
Right, that's contrained to the "work area" (i.e. an advertized rectangle where panels aren't; _NET_WORKAREA). Not directly from struts (a list of rectangles where panels are, _NET_WM_STRUT_PARTIAL). It's a good point though, if we take away the strut and replace it with some internal bookkeeping, we still need to make sure _NET_WORKAREA accounts for that bookkeeping. My main point here is, partial width struts are inherently broken with multimonitor setups, if you ever want to have a panel in the middle edges of monitors. There are two ways (that I can think of) that we can fix this: 1) fix the XDG spec to have struts v3 (we already replaced _NET_WM_STRUT with _NET_WM_STRUT_PARTIAL). 2) don't use X properties to figure out where are panel is, since we already know where are panel is. I advocate 2 because it's more straightforward. As an interesting side note, when _NET_WM_STRUT_PARTIAL was being hammered out, the person doing the hammering noticed this problem: https://mail.gnome.org/archives/wm-spec-list/2003-June/msg00004.html
s/are panel/our panel/g
*** Bug 690804 has been marked as a duplicate of this bug. ***
moving multihead bugs off the 3.8 blocker list
From https://live.gnome.org/Boston2012/Multimonitor: "We should use pointer barriers / pressure in the same manner as half-screen tile here." (See bug 685961.)
Wrong bug? This has nothing to do with tiling or pressure barriers.
*** Bug 695489 has been marked as a duplicate of this bug. ***
*** Bug 710857 has been marked as a duplicate of this bug. ***
*** Bug 710960 has been marked as a duplicate of this bug. ***
*** Bug 711307 has been marked as a duplicate of this bug. ***
*** Bug 712195 has been marked as a duplicate of this bug. ***
I can confirmed that this is still a problem in gnome 3.10 (in Ubuntu 14.04). (Why is it marked unconfirmed?)
(In reply to comment #22) > I can confirmed that this is still a problem in gnome 3.10 (in Ubuntu 14.04). > (Why is it marked unconfirmed?) Because we don't make a difference between UNCONFIRMED and NEW.
>Because we don't make a difference between UNCONFIRMED and NEW. Well, IMHO I think it should be marked confirmed. There are many duplicates and it has been around for two and a half years now! This particular bug unfortunately makes Gnome unusable for my configuration, which is a a laptop with a second monitor placed above the laptop screen. I can move the mouse to the second monitor, but I can't move any windows up there.
(In reply to comment #24) > Well, IMHO I think it should be marked confirmed. There are many duplicates and > it has been around for two and a half years now! OK.
*** Bug 724776 has been marked as a duplicate of this bug. ***
(In reply to comment #26) > *** Bug 724776 has been marked as a duplicate of this bug. *** oh. thank you, Florian! Any patches for testing here?
I find only vertical tile quite comfortable for the neck. But this bug is just a blocker for me to use GNOME. Any developer even interested in fixing such bugs?
Created attachment 274384 [details] [review] layout: Stop force-extending struts to the screen edge So I've looked into adding a new struts-like API we can use for our own chrome (see e.g. comment #11); turns out this might not be necessary after all - metacity/mutter's struts implementation deals just fine with struts that don't touch the screen edge ... While NetWM struts are defined in terms of screen edges (rather than monitor edges), our implementation does not actually depend on this. Just keeping struts at the monitor edge fixes secondary monitors above the primary one, which are currently completely unusable.
This was explicitly added by Alex in https://git.gnome.org/browse/gnome-shell/commit/?id=d964d2b . Have you made sure that this won't regress?
Created attachment 274392 [details] [review] layout: Don't always extend struts to the screen edge NetWM struts are defined in terms of screen edges (rather than monitor edges), which works poorly with vertical monitor layouts (as it renders the entire top monitor unusable). Don't extend struts in that case. (In reply to comment #30) > This was explicitly added by Alex in > https://git.gnome.org/browse/gnome-shell/commit/?id=d964d2b . Have you made > sure that this won't regress? No. After a bit of testing, the only oddity I found is the ability to move windows underneath the panel. So I updated the patch to only skip extending struts in vertical monitor layouts, where this is not an issue (e.g. we have to allow it anyway to get to the secondary monitor).
Review of attachment 274392 [details] [review]: Could this also break monitors below the primary for bottom-panel? ::: js/ui/layout.js @@ +1018,3 @@ continue; + let hasMonitorsAbovePrimary = this.monitors.reduce(Lang.bind(this, This would be a lot simpler using this.monitors.some
Created attachment 274394 [details] [review] layout: Don't always extend struts to the screen edge (In reply to comment #32) > Could this also break monitors below the primary for bottom-panel? Good point.
Review of attachment 274394 [details] [review]: LG.
Attachment 274394 [details] pushed as 76c4ec8 - layout: Don't always extend struts to the screen edge
*** Bug 735126 has been marked as a duplicate of this bug. ***
*** Bug 701142 has been marked as a duplicate of this bug. ***
*** Bug 693141 has been marked as a duplicate of this bug. ***
*** Bug 666073 has been marked as a duplicate of this bug. ***