GNOME Bugzilla – Bug 645581
Accommodate symmetric/linked monitor configurations?
Last modified: 2021-07-05 14:36:13 UTC
I have installed Ubuntu 11.04 alpha 3, and downloaded the latest build of gnome-shell from GIT. I have 2 monitors different resolutions, setup from nVidia settings to twinview. I noticed that when hitting the "activities" button the workplaces that are drawn only show the windows on the primary monitor. Thus, if a window is open in the second screen, changing the workplace wont make the window disappear.. so the second monitor is like separate workplace that is always visible. trendkiller@trendkiller-desktop:~$ gnome-session --version gnome-session 2.32.1 (version 2.32.x is not included in the options:P)
Created attachment 184143 [details] first workplace
Created attachment 184144 [details] third workplace Here you can see that i have changed workplace but amarok is still present in the second screen.
*** Bug 645900 has been marked as a duplicate of this bug. ***
This is by design, see bug 609258. You should be able to change it flipping the workspaces_only_on_primary gsettings key.
The workspaces_only_on_primary gsettings key does not work. According to the design of gnome-shell ( https://live.gnome.org/GnomeShell/DesignerPlayground/MultipleMonitors ) there are two-cases to be supported in the multi-monitor case, linked and unlinked monitors. I clearly uses the linked monitors workflow as described in the document. The current implementation seems to only handle the unlinked case where the secondary monitor is fixed, breaking all workflows related to the linked monitor use cases. An interesting note is that everybody that has developed a workflow around xinerama will have their workflows broken. I really hope that the lack of a link/unlink monitors option will be treated as a blocker, since it will break the workflow for a lot of people.
And setting this to WONTFIX is just ignorant and show that you clearly havent even bothered to read the design document.
(In reply to comment #6) > And setting this to WONTFIX is just ignorant and show that you clearly havent > even bothered to read the design document. It looks like you are confusing the playground (= place to go wild with ideas) with designs that have been agreed on and are intended to be implemented.
(In reply to comment #6) > And setting this to WONTFIX is just ignorant and show that you clearly havent > even bothered to read the design document. Yeah, I shouldn't have marked WONTFIX. Instead I filed a new bug requesting UI design input. *** This bug has been marked as a duplicate of bug 646260 ***
A) Florian is accurate that notes in DesignerPlayground don't necessarily reflect our current plans. B) As you've no doubt noticed in other ways, we're more concerned about creating good workflows than preserving existing workflows, and there are quite a few other ways we've broken existing workflows - like by automatically removing empty workspaces. The fact that someone has to learn a new workflow isn't necessarily a bug, and I'd certainly encourage people to try things out the way we ship them for a while, and see how it works. (Think about it like switching to a new operating system or buying a new device. Some things will carry over, some things won't) Still, I'd like to keep this open, because it will avoid new duplicates coming in, and because it's an interesting point to consider - are there cases where it does make sense for workspaces to span both monitors (or where both monitors should have - I think this would mostly in cases where you have two basically identical or very similar monitors permanently connected to a desktop workstation. (The extreme case of this is the case where the monitors are physically linked and have reduced or no bevelling between them - a display wall or similar.) And I don't consider turning on the workspaces_only_on_primary GConf key to be something I'd generally recommend - it sort of works, but also leaves bugs in the UI - like the fact that there's no way to see the windows on other monitors in other workspaces in the overview.
Sorry Rui - we're stepping on each other here - I'm going to reverse the duplicate marking because I want a bug open but don't want to presume a particular UI solution .
*** Bug 646260 has been marked as a duplicate of this bug. ***
Thans for reopening the bug. To be more constructive than my previous post (sorry for being a little rude) I can provide with my setup where I think it make sense for having a workspace span both monitors. I use two monitors for my daily work. I have my workspaces setup something like this: 1. Messaging (IM on monitor one, Mail on monitor two). 2. Web + development (Web monitor one, Terminals for doing web development monitor two). 3. Client apps development (Client apps/VNC/Virtualbox + Terminals related to this). As you see I have one primary monitor and on the second one I always have related windows. I would be happy to have my monitors unlinked if both monitors had workspaces, and possibly just a keyboard shortcut to switch workspaces on both monitors. But having one monitor with no workspaces just doesn't work for this kind of setup.
(In reply to comment #9) While somebody may benefit from the new forkflow, I believe it is just minor part of Gnome users. It is degrading my display to something like status display. It is useless. I was very happy with the previous version of workspaces and now they are gone :( Yes, there were some minor quirks but it would need just some polishing, not whole overhaul. I was used to have one workspace with firefox on my laptop screen, on second screen console. The other workspace was for Irc and Email. May be you should improve automatic opening of windows on correct workspace then inventing another new workflows.
*** Bug 646894 has been marked as a duplicate of this bug. ***
Changing the mentioned gconf key above helped me getting back the "old" behavior, so linking both monitors, forming one workspace.
I tested workspaces_only_on_primary again and I can confirm that it works in that it will link your workspace so I actually can use latest gnome-shell. However, the overview will not show anything from the secondary monitor, not the windows or the workspace.
When I say that the overview doesn't show the windows, I mean that they are not shown in the overview on the primary monitor and in the workspace switcher. All windows from any workspace on the secondary monitor are shown on as an exposé like view on the secondary monitor... but it gets a little strange.
*** Bug 647789 has been marked as a duplicate of this bug. ***
Is there something that people interested in this use case can do to help out? I'd be happy to describe my current workflow/use cases for multiple monitors, if that would be useful.
*** Bug 648465 has been marked as a duplicate of this bug. ***
*** Bug 649175 has been marked as a duplicate of this bug. ***
as stated in the dublicate "bug" report, it feels very unnatural this way.. i think the best way to go about this is to set a small "chain" icon somewhere in the screen that lets you link/unlink the screens.. since now they are unlinked and on the old version of Gnome Shell they where linked just fine, it should be possible to make that happen.. so the workplaces would be more like N rolls of workspaces (where N the number of monitors). _ _ _ _ _ _ _ _ _ | WS1 | |WS1 | | WS1 | example: here you have 3 monitors with the screens | |== | | ==| | linked, so if select a window in the ----- ----- ----- second workspace of the second screen you 1 2 3 will get: _ _ _ _ _ _ _ _ _ | WS2 | |WS2 | | WS2 | | |== | | ==| | ----- ----- ----- 1 2 3 _ _ _ _ _ _ _ _ _ | WS1 | |WS2 | | WS1 | same scenario with unlinked screens. | |=/=| |=/=| | monitor 2 goes to WorkSpace 2 while the ----- ----- ----- other 2 monitors stay on the current WS. 1 2 3 also they should be able to be locked the way they are managed now. so if we link them now and go on the next WS on monitor No.1 we would get: _ _ _ _ _ _ _ _ _ | WS2 | |WS3 | | WS2 | (or in case there are only 2 workspaces screen No2 | |== | | ==| | goes to WS 1--acting like a circle) ----- ----- ----- 1 2 3 I hope this is something that interests you, coz i think that it covers both workflows AND it offers more flexibility. Gnome shell is amazing with so much potential. while i understand that developing something like this is definitely not easy, i believe this would be a step in the right direction. i would like to hear some opinions on this! thanks to the developers and everyone who contributes to the project for their great work so far! cheers!
Same bug here as in comments #16 and #17. Any news about it?
*** Bug 651988 has been marked as a duplicate of this bug. ***
Wrt comment #9 "I think this would mostly in cases where you have two basically identical or very similar monitors permanently connected to a desktop workstation" That's EXACTLY the use case for about 80% of the ~20 desktops where I work. It's also the abstraction I'd like to strive for usually with my laptop + external monitor, even if they displays are different sizes. So to me the "monitors are a single big screen" abstraction on https://live.gnome.org/GnomeShell/DesignerPlayground/MultipleMonitors is critical. I'm glad workspaces_only_on_primary = false gets part of this use case, although there remain lots of little bugs (e.g., bug 652580).
There seems to be extension which fixes one aspect of this issue: https://extensions.gnome.org/extension/323/multiple-monitor-panels/
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.