After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652580 - workspace switcher only shows workspaces on primary monitor (ignores workspaces_only_on_primary==false)
workspace switcher only shows workspaces on primary monitor (ignores workspac...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 647443 652093 665840 680591 685260 687797 708558 712808 728172 734434 (view as bug list)
Depends on:
Blocks: 646912 665840
 
 
Reported: 2011-06-14 16:15 UTC by John Heidemann
Modified: 2021-07-05 14:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
workspaces-view: Don't create extra workspaces unconditionally (6.69 KB, patch)
2011-11-25 22:19 UTC, Florian Müllner
none Details | Review
workspaces-display: Implement workspaces on non-primary monitors (9.02 KB, patch)
2011-11-25 22:19 UTC, Florian Müllner
none Details | Review
workspaces-display: Make workspacesView private (7.72 KB, patch)
2011-11-26 00:29 UTC, Florian Müllner
needs-work Details | Review
workspaces-view: Don't create extra workspaces unconditionally (6.69 KB, patch)
2011-11-26 00:30 UTC, Florian Müllner
accepted-commit_now Details | Review
workspaces-display: Implement workspaces on non-primary monitors (12.52 KB, patch)
2011-11-26 00:32 UTC, Florian Müllner
accepted-commit_now Details | Review
workspaces-display: Make workspacesView private (13.01 KB, patch)
2011-11-26 15:16 UTC, Florian Müllner
reviewed Details | Review
workspaces-view: Don't create extra workspaces unconditionally (6.67 KB, patch)
2011-11-26 15:24 UTC, Florian Müllner
committed Details | Review
workspaces-display: Implement workspaces on non-primary monitors (13.19 KB, patch)
2011-11-26 15:28 UTC, Florian Müllner
committed Details | Review
workspaces-display: Make workspacesView private (13.38 KB, patch)
2011-11-28 17:22 UTC, Florian Müllner
committed Details | Review
workspaces-view: Handle swipe scolling in workspacesDisplay (9.76 KB, patch)
2011-11-28 17:23 UTC, Florian Müllner
committed Details | Review
workspace switcher on additional monitors (870.37 KB, image/png)
2012-06-06 00:03 UTC, darkxst
  Details

Description John Heidemann 2011-06-14 16:15:50 UTC
With the /desktop/gnome/shell/windows/workspaces_only_on_primary set to false,
the second monitor should be part of the workspace.  This setting generally works (thank goodness!).

Observed behavior: Actvities overview (got by pressing the logo key), however, handles the two monitors differently:  for the primary monitor, it exposes only windows on the current workspace, but for the external monitor, it always shows all windows on all workspaces.

Expected behavior: when /desktop/gnome/shell/windows/workspaces_only_on_primary is false, both monitors should behave the same, and both should show only windows on the current workspace.

To reproduce: start a new session with two monitors, main and external. 

gconftool-2 -s /desktop/gnome/shell/windows/workspaces_only_on_primary -t bool false

Put windows main1, main2, ext1, ext2 on two workspaces.   Go to workspace 1 and hit the logo key.  Main will show only main1, but external will show ext1 AND ext2.  Sadness ensues.

(I'm actually doing this with gnome-shell-extensions-native-window-placement installed.  Platform is fedora 15, with gnome-shell 3.0.2.)
Comment 1 alejandro.perez.mendez 2011-10-20 16:37:21 UTC
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.
Comment 2 Age Bosma (IRC: Forage) 2011-11-18 13:27:50 UTC
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.
Comment 3 Alessandro Crismani 2011-11-24 20:49:05 UTC
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
Comment 4 Florian Müllner 2011-11-25 22:19:08 UTC
(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.
Comment 5 Florian Müllner 2011-11-25 22:19:37 UTC
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.
Comment 6 Florian Müllner 2011-11-25 22:19:46 UTC
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).
Comment 7 Jasper St. Pierre (not reading bugmail) 2011-11-25 22:25:25 UTC
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?
Comment 8 Florian Müllner 2011-11-25 22:32:07 UTC
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
Comment 9 Florian Müllner 2011-11-25 22:39:21 UTC
(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).
Comment 10 Florian Müllner 2011-11-26 00:29:56 UTC
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.
Comment 11 Florian Müllner 2011-11-26 00:30:27 UTC
Created attachment 202162 [details] [review]
workspaces-view: Don't create extra workspaces unconditionally

Reattaching to maintain patch order.
Comment 12 Florian Müllner 2011-11-26 00:32:35 UTC
Created attachment 202163 [details] [review]
workspaces-display: Implement workspaces on non-primary monitors

Merge workspaces/extraWorkspaces and workspacesView/extraViews.
Comment 13 Jasper St. Pierre (not reading bugmail) 2011-11-26 00:56:07 UTC
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.
Comment 14 Jasper St. Pierre (not reading bugmail) 2011-11-26 01:01:48 UTC
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); ?
Comment 15 Jasper St. Pierre (not reading bugmail) 2011-11-26 01:07:12 UTC
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 16 Florian Müllner 2011-11-26 10:46:18 UTC
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.
Comment 17 Florian Müllner 2011-11-26 15:16:42 UTC
Created attachment 202184 [details] [review]
workspaces-display: Make workspacesView private

Fixed breakage, but the cleanup is quite a bit less nice now :(
Comment 18 Florian Müllner 2011-11-26 15:24:04 UTC
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.
Comment 19 Florian Müllner 2011-11-26 15:28:59 UTC
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.
Comment 20 Jasper St. Pierre (not reading bugmail) 2011-11-26 20:01:20 UTC
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?
Comment 21 Florian Müllner 2011-11-28 17:22:11 UTC
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 ...
Comment 22 Florian Müllner 2011-11-28 17:23:13 UTC
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.
Comment 23 Florian Müllner 2011-12-01 16:59:04 UTC
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.
Comment 24 Florian Müllner 2012-01-10 16:37:54 UTC
*** Bug 665840 has been marked as a duplicate of this bug. ***
Comment 25 darkxst 2012-06-06 00:03:55 UTC
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?
Comment 26 Florian Müllner 2012-06-06 05:56:09 UTC
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?
Comment 27 darkxst 2012-06-06 06:20:50 UTC
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.
Comment 28 Florian Müllner 2012-06-06 09:57:19 UTC
(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)
Comment 29 mattzerah 2012-06-19 04:21:48 UTC
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.
Comment 30 Alessandro Crismani 2012-06-19 07:21:43 UTC
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
Comment 31 Florian Müllner 2012-07-13 12:01:47 UTC
*** Bug 652093 has been marked as a duplicate of this bug. ***
Comment 32 Florian Müllner 2012-07-25 17:54:07 UTC
*** Bug 680591 has been marked as a duplicate of this bug. ***
Comment 33 Florian Müllner 2012-10-10 21:19:29 UTC
*** Bug 685260 has been marked as a duplicate of this bug. ***
Comment 34 Florian Müllner 2012-11-06 19:43:26 UTC
*** Bug 687797 has been marked as a duplicate of this bug. ***
Comment 35 Fanen Ahua 2012-11-07 18:36:55 UTC
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.
Comment 36 Fanen Ahua 2012-11-07 18:40:02 UTC
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.
Comment 37 Florian Müllner 2013-09-22 08:32:50 UTC
Renaming summary to reflect what's left.
Comment 38 Florian Müllner 2013-09-22 08:33:05 UTC
*** Bug 708558 has been marked as a duplicate of this bug. ***
Comment 39 Florian Müllner 2013-11-21 13:52:50 UTC
*** Bug 712808 has been marked as a duplicate of this bug. ***
Comment 40 Florian Müllner 2014-04-15 13:42:49 UTC
*** Bug 728172 has been marked as a duplicate of this bug. ***
Comment 41 gregw@wiltel.org 2014-05-27 14:03:09 UTC
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?
Comment 42 Florian Müllner 2014-08-01 09:06:14 UTC
*** Bug 647443 has been marked as a duplicate of this bug. ***
Comment 43 Florian Müllner 2014-08-07 15:30:13 UTC
*** Bug 734434 has been marked as a duplicate of this bug. ***
Comment 44 Giulio Fidente 2014-08-07 15:39:20 UTC
FWIW, I'd prefer to have a workspace previewer on each monitor showing only the workspaces from that monitor
Comment 45 Florian Müllner 2014-08-07 15:47:36 UTC
(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.
Comment 46 Giulio Fidente 2014-08-07 15:53:36 UTC
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.
Comment 47 Florian Müllner 2014-08-07 16:31:07 UTC
(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 ...
Comment 48 Giulio Fidente 2014-08-07 17:14:25 UTC
> 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.
Comment 49 Giulio Fidente 2014-08-07 17:23:22 UTC
(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.
Comment 50 ragnese 2015-08-13 11:18:20 UTC
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.
Comment 51 andi.wenger 2017-10-24 12:24:16 UTC
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.
Comment 52 Account Disabled 2018-11-07 23:23:47 UTC
What's the progress on this bug?
Comment 53 GNOME Infrastructure Team 2021-07-05 14:22:21 UTC
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.