Exactly same issue here. It is completely annoying to have all the windows in the second monitor.

I'm not using gnome-shell-extensions-native-window-placement. Platform Ubuntu 11.10, gnome-shell 3.2.1.

I'd love to see a full implementation of workspaces spanning across multiple displays as well.

The mentioned window issue is, however, not the only thing that is going wrong at the moment.
The second display is also not included in the Workspace list view, giving you no way to drag windows to the second monitor of a particular workspace.

This bugs me as well. I use two monitors with many windows open. These windows pertain to different activities that I like having separated on different workspaces. The results is that the overview shown on the external monitor  becomes cluttered, mixing windows from different tasks, and as soon as I open a few more windows it degrades to an big mess where I cannot see the window I was looking for.

I've tried to fix it, but my coding skills are not good enough for understanding the interactions between workspace.js, workspacesView.js, workspaceThumbnails.js and others.

I've found that windows that are shown in the overview are controlled by:

workspace.js:
    _isMyWindow : function (win) {
        return (this.metaWorkspace == null ||
Main.isWindowActorDisplayedOnWorkspace(win, this.metaWorkspace.index()))
&&
            (!win.get_meta_window() ||
win.get_meta_window().get_monitor() == this.monitorIndex);
    },

Now, the metaworkspace for the external monitor is NULL, hence isWindowActorDisplayedOnWorkspace() is skipped and windows from all workspaces are shown.

I've tried something like:
workspace.js:
    _isMyWindow : function (win) {
        if (this.metaWorkspace != null)
            return (Main.isWindowActorDisplayedOnWorkspace(win,
this.metaWorkspace.index())) &&
                (!win.get_meta_window() ||
win.get_meta_window().get_monitor() == this.monitorIndex);
        else
            return (win.get_workspace().index() ==
global.get_active_workspace_index()) &&
                (!win.get_meta_window() ||
win.get_meta_window().get_monitor() == this.monitorIndex);
    },

which apparently works, but if I change workspace while in the overview the windows shown on the external monitor do not change. Keeping the example of Comment 1, I get: "Go to workspace 1 and hit the logo key. Main will show only main1, external will show only ext1. Click on the thumbnail on workspace 2, main will show main2, external will show ext1 (wrong!, should be ext2)".

How can I hook up a refresh of the external monitor when the workspace is changed while in the overview? Is this the right way to do it?

Cheers, Alessandro

(In reply to comment #3)
> How can I hook up a refresh of the external monitor when the workspace is
> changed while in the overview? Is this the right way to do it?

No. On the primary monitor, there is one workspace object per workspace (quite obvious ;-) - on secondary monitors, there is a single "extra" workspace per monitor. If workspaces-only-on-primary is false, you don't want those extra workspaces, but a list of workspaces just like on the primary.

Created attachment 202155 [details] [review]
workspaces-view: Don't create extra workspaces unconditionally

Extra workspaces are special, in that they collect windows from
all workspaces for a particular monitor. This matches the default
behavior, but we need more than a single workspace per monitor if
workspaces-only-on-primary is false, so don't create the extra
workspaces in that case.

Created attachment 202156 [details] [review]
workspaces-display: Implement workspaces on non-primary monitors

If workspaces-only-on-primary is false, workspaces should be shown
on each monitor; rather than letting the existing workspaces span
the entire screen, manage one workspacesView per monitor (similar
to the extra workspaces in WorkspacesView when the setting is true).

Review of attachment 202156 [details] [review]:

Why bother with the split between primary and extra? Why not just have one list of workspaces and workspace views, with the zeroth element being the primary monitor?

Attached patches should work reasonably well for a first shot, but there are at least the following issues:

 - toggling the setting on the fly is rather flaky; at least a part of
   the problem is on the mutter side

 - using swipe-scrolling to switch workspaces is broken if 
   workspaces-only-on-primary is false

 - I'm unsure what to do with the workspace switcher - it is odd to not show
   any workspaces on non-primary monitors, but stuffing previews for each
   monitor into the switcher doesn't really scale (it's probably OK-ish for
   two monitors, but gets crazy with more). Maybe each monitor should get
   its own switcher? But then, how do we indicate that the monitors are
   "linked"?

 - parts of the second patch feel a bit like black magic; might be worth to
   spend some time reorganizing how overview, workspacesDisplay and
   workspacesView interact

(In reply to comment #7)
> Why bother with the split between primary and extra? Why not just have one list
> of workspaces and workspace views, with the zeroth element being the primary
> monitor?

I've thought about using a single array, but I don't think it's cleaner unless the index matches the monitor index. In my opinion, that approach would require some cleanup of the overview/workspacesDisplay/workspacesView interaction (which probably is a good idea anyway, see previous comment).

Created attachment 202161 [details] [review]
workspaces-display: Make workspacesView private

WorkspacesDisplay was introduced to manage the workspace objects
and views; however, the overview still accesses the view held
by the workspacesDisplay directly, which is a bit odd.
Add some additional methods needed by the overview, and make the
view a private property.

Created attachment 202162 [details] [review]
workspaces-view: Don't create extra workspaces unconditionally

Reattaching to maintain patch order.

Created attachment 202163 [details] [review]
workspaces-display: Implement workspaces on non-primary monitors

Merge workspaces/extraWorkspaces and workspacesView/extraViews.

Review of attachment 202161 [details] [review]:

I like this.

Commit message nitpick: "workspaces-display" is an odd choice. I'd suggest "workspacesView", since that's the filename with the change.

Review of attachment 202162 [details] [review]:

::: js/ui/workspacesView.js
@@ +140,3 @@
+                           monitors[i].width, monitors[i].height);
+            global.overlay_group.add_actor(ws.actor);
+            this._extraWorkspaces[m++] = ws;

this._extraWorkspaces.push(ws); ?

Review of attachment 202163 [details] [review]:

Much better. Two minor cleanups.

::: js/ui/workspacesView.js
@@ +687,3 @@
+                continue;  // we are only interested in the primary monitor
+
+            this._workspaces[m] = [];

let monitorWorkspaces = [];
this._workspaces.push(monitorWorkspaces);

for (let w = 0; ...) {
    let metaWorkspace = ...;
    monitorWorkspaces.push(new Workspace(metaWorkspace, i));
}

this._workspaceViews.push(new WorkspacesView(monitorWorkspaces));

@@ +830,3 @@
+                this._workspacesViews[m].setGeometry(x, y, width, height,
+                                                     difference);
+                m++;

Put the m++; on the outside of the if statement.

Comment on attachment 202161 [details] [review]
workspaces-display: Make workspacesView private

(In reply to comment #13)
> I like this.

It's nice, but unfortunately too good to be true - patch breaks a couple of things, I'll come up with an update later.


> Commit message nitpick: "workspaces-display" is an odd choice. I'd suggest
> "workspacesView", since that's the filename with the change.

Hmm, "view: make view private" sounded odd to me, so I picked the "dominant class" rather than the filename.

Created attachment 202184 [details] [review]
workspaces-display: Make workspacesView private

Fixed breakage, but the cleanup is quite a bit less nice now :(

Created attachment 202185 [details] [review]
workspaces-view: Don't create extra workspaces unconditionally

(In reply to comment #14)
> Review of attachment 202162 [details] [review]:
> this._extraWorkspaces.push(ws); ?

Sure.

Created attachment 202186 [details] [review]
workspaces-display: Implement workspaces on non-primary monitors

(In reply to comment #15)
> @@ +830,3 @@
> +                this._workspacesViews[m].setGeometry(x, y, width, height,
> +                                                     difference);
> +                m++;
> 
> Put the m++; on the outside of the if statement.

No. This would require something along the lines of

if ()
  foo();
else if ()
  bar();
else
  m--;
m++;

which I consider quite a bit uglier than the existing code.

Review of attachment 202184 [details] [review]:

::: js/ui/workspace.js
@@ +386,3 @@
     _getWorkspaceActor : function() {
         let index = this.metaWindow.get_workspace().index();
+        return Main.overview.workspacesDisplay.getWorkspaceByIndex(index);

Couldn't you just pass the workspace actor in to the constructor from _addWindowClone?

Created attachment 202305 [details] [review]
workspaces-display: Make workspacesView private

(In reply to comment #20)
> Couldn't you just pass the workspace actor in to the constructor from
> _addWindowClone?

Not a big fan of reference cycles, but sure ...

Created attachment 202306 [details] [review]
workspaces-view: Handle swipe scolling in workspacesDisplay

If workspaces-only-on-primary is false, swipe scrolling is now
broken with multiple monitors. To fix, let workspacesDisplay
handle swipe scrolling for all views.

Attachment 202185 [details] pushed as 84dde8e - workspaces-view: Don't create extra workspaces unconditionally
Attachment 202186 [details] pushed as 26df6cf - workspaces-display: Implement workspaces on non-primary monitors
Attachment 202305 [details] pushed as f2c79be - workspaces-display: Make workspacesView private
Attachment 202306 [details] pushed as a634f25 - workspaces-view: Handle swipe scolling in workspacesDisplay

Patches were OK'ed on IRC, pushing. I'll leave the bug open for now, as the issue with the workspace switcher noted in comment #8 still applies.

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

Created attachment 215699 [details]
workspace switcher on additional monitors

Is this something that you would consider merging into gnome-shell, if I prepare patches for it?

You should get designer input on this. Quick notes:

 - I'm not sure we want a top bar on non-primary monitors
 - How would you place workspace switchers on three monitors?
   Or when the primary is on the right?

sorry meant to mention, ignore the top-bar. That is just part of my extension in which I have implemented this.

I think from a usability perspective, they would be best on the closest edge to the central monitor. However I guess that could get a little messy when monitors are setup in an L shape rather than horizontal configuration.

How do I go about getting designer input? have tried to ask about this a few times on #gnome-design but not got any response.

(In reply to comment #27)
> How do I go about getting designer input? have tried to ask about this a few
> times on #gnome-design but not got any response.

#gnome-design is definitively the correct place. Chances are best during European/US working hours, and when not interrupting an ongoing discussion. Also note that many designers are at the GNOME.Asia conference now, so they'll probably be less present on IRC (and likely at different times when they are)

Is there any chance of getting a setting along side the 'Workspaces only on primary monitor', that is the opposite for when in the overview screen?

I started using gnome-shell when this was classed as a bug, but I really enjoyed using it this way, and found it more productive. I could easily get an overview of ALL my applications on ANY workspace on the right hand monitor, and have only the applications open on the current workspace on the left hand monitor. 

Else can anyone point me to an extension, or even an API that I can use to create my own extension to do this?

Much appreciated.

Matt.

I believe that you can achieve what you want, provided that the windows on the second monitor are always shown together, not only in the activity view. This behaviour is toggled with the workspaces-only-on-primary.

I do not think that the old behaviour is accessible now without tweaking the shell with an extension, and I do not believe that such an extension exist at the moment.

Alessandro

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

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

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

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

Perhaps one universal design for the workspace preview cannot provide an optimal solution to the problem of previewing the contents of all the displays attached to the PC.

Is it sensible then to consider using two "rectangles" for two monitors side-by-side, and for anything greater than two monitors, using dedicating one entire display to rendering the workspace previews?

For single monitor, the current situation is fine. 

For two monitors, use two rectangles instead of just one to preview both screens.

For more than 2 monitors, use as many rectangles as needed, dedicate one screen to rendering previews. Make it possible to click to zoom in on a particular workspace so that you can more accurately pick out a window you want. An also useful feature would be to allow the ability to select a preferred screen for rendering the workspace preview, so that for instance, I can "pin" it to the screen closest to me.

I guess this sounds very complicated, but you guys are in the best position to determine if this is feasible (and sensible) or not.

Also, I think that at the very least, the (IMO) more common case of two monitors side-by-side can be fixed, to improve the situation for current users, pending when a more universal fix is found.

Renaming summary to reflect what's left.

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

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

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

I used to see all the monitors in a previous version of gnome-shell installed via ubuntu.  Just upgraded to latest and now I'm not.   So it is definitely fixable.

Screen dump appears to be able to work out multiple monitors regardless of their vertical/horizontal layout.  Can't you just take a thumbnail from the same source?

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

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

FWIW, I'd prefer to have a workspace previewer on each monitor showing only the workspaces from that monitor

(In reply to comment #44)
> FWIW, I'd prefer to have a workspace previewer on each monitor showing only the
> workspaces from that monitor

Any suggestions to make it clear that each switcher applies to all monitors rather than the one it's located on? This is a fairly old bug that has been blocked on design for years - code-wise there shouldn't be too much difficulties once there's an agreed design.

hi Florian, thanks for looking into this bug.

What I meant in comment #44 is to have in each switcher only the workspaces on that monitor; not to display all workspaces in each switcher.

(In reply to comment #46)
> What I meant in comment #44 is to have in each switcher only the workspaces on
> that monitor

That's basically the problem we haven't figured out yet - there is no such thing as "workspaces on that monitor". There is a single set of workspaces, with each workspace spanning all monitors - so if you have three workspaces, each of those covers the entire screen from the top-left corner of the top-leftest monitor to the bottom-right corner of the bottom-rightest monitor. What I think you are suggesting is showing a workspace switcher on each monitor, and only showing the part of each workspace that corresponds to the monitor (which is what the existing switcher does for the primary monitor) - not particularly hard to do, but I fear that most users would understand that UI as you describe it (which in my opinion happens to be a much more natural way of thinking about monitors/workspaces than the way it actually works :-( ). I did discuss this issue with the design team at guadec some years ago, and our conclusion was that we'd need a less confusing solution here. It obviously hasn't happened (neither on the code nor the design side), so if designers are now OK with one of the obvious fixes despite the drawbacks, I'm up to doing the coding work. But we do need designer buy-in first ...

> What I think you are suggesting is showing a workspace switcher on each
> monitor, and only showing the part of each workspace that corresponds to the
> monitor (which is what the existing switcher does for the primary monitor).

Yes, this is it. Thanks.

If we do this for the switcher on the primary monitor I don't see why it shouldn't apply to the additional monitors too; I'll try to see if anyone from design can spare some comments though.

(In reply to comment #45)
> 
> Any suggestions to make it clear that each switcher applies to all monitors
> rather than the one it's located on? This is a fairly old bug that has been
> blocked on design for years - code-wise there shouldn't be too much
> difficulties once there's an agreed design.

Yep. Currently the switcher places a gray border around the 'active' workspace, I'd make sure the border is visible on all monitors, and moves on all monitors when switching to another workspace.

There is an extension: https://extensions.gnome.org/extension/921/multi-monitors-add-on/

That does what is being described (as an option, anyway). I do think this should be the default, but almost anything would be better than what we have right now.

I'm using 3.16 and if I have a second monitor and set "workspaces only on primary display" to false, then there is no trace of the windows on that monitor in the workspace preview dock in the overview. It only shows the parts of the workspaces that are on the primary monitor, so I have no idea if there is a window open on the second monitor on a workspace other than the current one.

If it wouldn't have been for the link to the extension in the previous comment, I would have replaced the shell with an alternative that handles multiple monitors properly. Maybe you should also think about your processes if "design" blocks a fix for a bug for more than 5 Years.

What's the progress on this bug?

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.