Contents
Two usage cases
- Monitors are independent; each has its own taskbar and its own workspaces.
- Monitors define a single big screen; only a single taskbar and a single set of workspaces.
You may even want to switch between these modes within a single session; see below.
Monitors are independent
This is useful for people who want to use separate monitors as more or less separate computers. Each monitor gets its own set of workspaces.
This allows different kinds of work:
You flip workspaces often in one monitor to do most of your work, while the other monitor remains static. In the static monitor, you keep a pervasive to-do list, web browser, IM program — the things that "you always need to glance at". Currently (in Metacity) I fake this behavior by using multiple workspaces, and a few sticky windows that stay in the second monitor. It works very well for my to-do list and journal.
- Flip workspaces independently in each separate monitor, so you get as close to having "multiple computers" as you want.
Note that this really means "each monitor has a separate set of workspaces". It doesn't mean that you can drag workspaces into monitors - that would be an unwieldy UI, and it would have problems when you change a workspace to be in a monitor with a different resolution.
You may of course drag windows across monitors as usual, but you can't have a window straddle two monitors; the dragging UI would have to take this into consideration to make it obvious where you are actually dropping the window.
Implementation notes
This is probably easiest to implement if the root-relative window positions are kept just as RANDR would expect them, instead of trying to do compositing magic to make windows appear in the right place.
That is, with two monitors left-to-right, windows on the rightmost monitor would have high X coordinates regardless of their workspace. If you are in a workspace in some monitor, and a client wants to place a window outside that monitor's area, then the shell overrides that request and puts the window in the monitor you are in. The details of this may get tricky to implement; we may need to constrain the mouse to the monitor's area when resizing (but not when moving, as moving outside the monitor means "move to another monitor").
Monitors are a single big screen
Useful for artists; they'll want to keep their biggest monitor for image windows, and the other monitor for toolbars/etc.
In general, this is useful for people who have separate tasks that require a lot of real estate.
Workspaces are just big screens that span all monitors. Switching to another workspace makes all your monitors change.
Proposal
Have a "link monitors together" toggle somewhere. That switches you between independent monitors and a single big screen.
Behavior invariants
No matter if monitors are linked or not, you can always drag a window from one monitor to another just by press-drag-release on its titlebar (or whatever alt+drag shortcuts you may have for moving windows). If monitors are not linked, this would effectively move the window from one workspace to another.
If monitors are not linked, then moving a window to another monitor will make the window be on the top of the stack in the destination monitor. Metacity gets this inadvertently wrong: if you have sticky windows in the second monitor, when you drag a window from the first monitor it may end up below the one in the second monitor (e.g. the window retains its stacking order).
Bugs
Discussion
SriramRamkrishna - added a discussion portion. I'd like to make sure that we have a "primary" monitor option indicating which monitor is the primary one. In Gnome 2.x this was broken as it seems that gnome-panel did not respect what the primary monitor was initially. (I believe there is a bug I put in already for this) In any case, people should be able to select which monitor will be their static in the unlinked case.
AlexanderLarsson - We need to handle the dead areas that appear when monitors have different sizes in a better way than we do today, hitting the panel or the notification tray with dead areas around it is very painful. Also, having a monitor to the right or above the primary makes the hot corner useless, so it should probably be the far corner, not just the corner of the primary monitor.
EmmanueleBassi - The should be some clipping when switching to the overview mode, to avoid "bleeding" UI components (windows, controls) into the secondary display.
SriramRamkrishna - The response from Jon McCann regarding this is this: The issue isn't multiple monitors. it is the intersection of heavy multiple physical monitors and heavy workspace users and the specific interactions they are used to. I understand the issues but no one has put forth a proposal that will work for that and ensure we cover or priority use cases well. To be precise, don't try to show a screen sized workspace preview in the overview, consider monitors separate, workspaces on primary display, expose' on externals
So we need to address his concern here if we want to go anywhere with this. What possible proposal can we come up with that would make sense?
NilsGoroll - I would like to raise my voice for better support of the intependent Monitors alternative (which I would phrase as independend workspace switching). As of GNOME Shell 3.8.4 it is possible to have workspaces on the primary Monitor only or all, which is already a choice, but being able to switch workspaces on both monitors independently would be ideal. I find it particularly efficient to be able to combine arbitrary "left" and "right" workspaces in a two-Monitor setup. With GNOME2, I used a setup with two X screens on one display (ie :0 and :0.1), which metacity managed both, having two instances of the other desktop tools (nautilus, taskbars etc). Now that support for this setup was discontinued, I would highly appreciate a replacement with the same functionality.