GNOME Bugzilla – Bug 609258
multiple monitor behavior for the overview
Last modified: 2011-09-20 09:57:00 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?
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.
(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
(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.
"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.
*** Bug 581833 has been marked as a duplicate of this bug. ***
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
(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)
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.
+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 ;-)
*** Bug 635507 has been marked as a duplicate of this bug. ***
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...
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.
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.
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.
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.
Jasper: don't mark my bugs needinfo please.
Whoops, did I? Sorry about that.
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.
The wiki page has moved to http://live.gnome.org/GnomeShell/DesignerPlayground/MultipleMonitors
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
Created attachment 182470 [details] [review] Add MetaScreen::monitors-changed signal
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.
Created attachment 182472 [details] [review] Track the primary monitor for each window
Created attachment 182473 [details] [review] Add API to get the primary monitor of a window
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.
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).
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.
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.
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.
Created attachment 182479 [details] [review] Switch to using the mutter primary monitor APIs
Created attachment 182480 [details] [review] Enable the workspaces_only_on_primary feature of mutter
Created attachment 182481 [details] [review] Add and export shell_global_get_primary_monitor_index
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.
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.
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.
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).
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.
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.
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.
Eh, "the first patch is straight from bug 609258", obviously meant bug 642355.
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...
federico: git bz apply
(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
(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.
(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.
owen: I guess that is true, we can leave some information hanging around for later use.
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.
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.
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.
Created attachment 182872 [details] [review] Switch to using the mutter primary monitor APIs
Created attachment 182873 [details] [review] Enable the workspaces_only_on_primary feature of mutter
Created attachment 182874 [details] [review] Add and export shell_global_get_primary_monitor_index
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.
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.
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.
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).
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.
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.
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.
New rebased series, some patches moved to bug 643786 as they make more sense there.
Review of attachment 182871 [details] [review]: Looks correct.
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
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
Created attachment 182971 [details] [review] Add MetaScreen::monitors-changed signal
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.
Created attachment 182973 [details] [review] Track the primary monitor for each window
Created attachment 182974 [details] [review] Add API to get the primary monitor of a window
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.
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.
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).
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.
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.
Created attachment 182980 [details] [review] Switch to using the mutter primary monitor APIs
Created attachment 182981 [details] [review] Enable the workspaces_only_on_primary feature of mutter
Created attachment 182982 [details] [review] Add and export shell_global_get_primary_monitor_index
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.
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.
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.
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).
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.
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.
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.
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 on attachment 182969 [details] [review] exposing MetaWindow.move() and .resize() in javascript and adding .move_frame() This was commited from bug 642355
(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
*** Bug 611909 has been marked as a duplicate of this bug. ***
Created attachment 183508 [details] [review] Add MetaScreen::monitors-changed signal
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.
Created attachment 183510 [details] [review] Track the monitor for each window
Created attachment 183511 [details] [review] Add API to get the monitor of a window
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.
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.
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).
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.
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.
Created attachment 183517 [details] [review] Switch to using the mutter primary monitor APIs
Created attachment 183518 [details] [review] Enable the workspaces_only_on_primary feature of mutter
Created attachment 183519 [details] [review] Add and export shell_global_get_primary_monitor_index
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.
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.
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.
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).
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.
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.
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.
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.
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.
New series is a rebase to latest + rename "primary monitor" to monitor on MetaWindow. Also adds a new patch that fixes comment #85
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.
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?
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
Review of attachment 183512 [details] [review]: Sure.
Review of attachment 183511 [details] [review]: Looks good.
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?
Review of attachment 183508 [details] [review]: Looks good.
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).
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.
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.
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.
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 on attachment 183508 [details] [review] Add MetaScreen::monitors-changed signal Attachment 183508 [details] pushed as 0ff602b - Add MetaScreen::monitors-changed signal
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?
(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.
(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.
(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)
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?
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.
(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.
(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).
(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.
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(); ...
Review of attachment 183523 [details] [review]: Sure.
Review of attachment 183519 [details] [review]: Looks good.
Review of attachment 183525 [details] [review]: Looks right.
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 ...
Review of attachment 183518 [details] [review]: Looks good.
Review of attachment 183517 [details] [review]: Sure.
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?
Review of attachment 183528 [details] [review]: Looks right (except me not liking the signal names ...)
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.
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)
Review of attachment 183524 [details] [review]: Yup.
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 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
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
(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.
All patches updated according to feedback and commited. Remaining issues will be splitted up to separate bugs, blocking a multihead tracker bug.
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.