GNOME Bugzilla – Bug 780078
Add support for top bars on all monitors to allow for multi-monitor support in primary extensions - apps-menu, places-menu, topbar, etc
Last modified: 2021-07-05 14:15:38 UTC
It would be nice if the primary included gnome-shell extensions, eg apps-menu and places-menu (and by extension the topbar) supported multi-monitor similar to how the bottom bar 'window-list' currently does. This was easy to achieve on Gnome 2 and now via MATE (out of the box) but there does not appear to be any way to do this with Gnome 3. This also leads to there not being a way to do this via 'Gnome Classic'. Even Windows finally (in W10) does this better out of the box than Gnome 3. BTW - Intel has supported IGP triple head since Ivy Bridge (2012) so it is very cheap to deploy a triple head system (~ $200 for 3 1080p monitors). AMD supports up to quad head in their IGPs. This has been blocking me from moving to Gnome 3 since its release and I finally decided to write a bug report about it. I have had all multi-monitor systems since prior to 2004.
Created attachment 347984 [details] Gnome 2
Created attachment 347985 [details] Windows 8
Created attachment 347986 [details] Windows 10
Created attachment 347988 [details] Mate 1.18.0
I'm sorry, but I don't understand this. (In reply to Chris Cheney from comment #0) > It would be nice if the primary included gnome-shell extensions, eg > apps-menu and places-menu (and by extension the topbar) What is "the primary"? > supported > multi-monitor similar to how the bottom bar 'window-list' currently does. Can you be more specific? What feature do you want, exactly?
(In reply to Allan Day from comment #5) > > supported > > multi-monitor similar to how the bottom bar 'window-list' currently does. > > Can you be more specific? What feature do you want, exactly? Probably something like https://extensions.gnome.org/extension/323/multiple-monitor-panels/
Presumably the extensions that Gnome itself ships as opposed to ones that 3rd parties supply on http://extensions.gnome.org/ , which would be the responsibility of those 3rd party developers. i.e. these: https://git.gnome.org/browse/gnome-shell-extensions/tree/extensions In particular apps-menu, and places-menu as window-list already properly supports multiple monitors. I would like to be able to replicate the look (at least more or less) of what is shown in the MATE 1.18.0 picture attached to this BZ. You can already do this with Gnome Classic for 1 screen, but not for more than 1. The previously mentioned 3rd party extension does work to replicate the 'Activities' button but does not replicate the others mentioned and would be better suited in the official set of extensions so that it does not break in the future as it has often in the past with new gnome releases.
Created attachment 348094 [details] Gnome 3
Compare the MATE 1.18.0 to Gnome 3 picture. It does not appear to be possible currently to make a Gnome 3 desktop look similar to the MATE 1.18.0 (Gnome 2) desktop for multiple monitors. However, it works fine for a single monitor.
(In reply to Florian Müllner from comment #6) ... > > Can you be more specific? What feature do you want, exactly? > > Probably something like > https://extensions.gnome.org/extension/323/multiple-monitor-panels/ Ah, right.
(In reply to Chris Cheney from comment #7) > Presumably the extensions that Gnome itself ships as opposed to ones that > 3rd parties supply on http://extensions.gnome.org/ No, you don't want that in the extensions. Each extension is separate, so what you are asking for here is that apps-menu and places-menu *both* add top bars to non-primary monitors. We are definitely not going to add two or more stacked panels at the top. What you probably want instead is an option in gnome-shell to put top bars on non-primary monitors, and the aforementioned extensions to handle that case.
(In reply to Florian Müllner from comment #11) > (In reply to Chris Cheney from comment #7) > > Presumably the extensions that Gnome itself ships as opposed to ones that > > 3rd parties supply on http://extensions.gnome.org/ > > No, you don't want that in the extensions. Each extension is separate, so > what you are asking for here is that apps-menu and places-menu *both* add > top bars to non-primary monitors. We are definitely not going to add two or > more stacked panels at the top. > > What you probably want instead is an option in gnome-shell to put top bars > on non-primary monitors, and the aforementioned extensions to handle that > case. That sounds like a great solution, I tried looking at it before but got lost on how to do it (I think) due to the explanation you just gave.
Is there anything else needed, I noticed the BZ is still set to NEEDINFO
(In reply to Chris Cheney from comment #13) > Is there anything else needed, I noticed the BZ is still set to NEEDINFO Well, we've established what you want, but that doesn't necessarily mean that we'll implement it. So far the reasoning seems to be: - you really want the feature - GNOME 2 / Windows has it Unlike the case of the window list, nothing in the top bar (except for the app menu to some extent) is tied to a particular monitor, so there's a much weaker case here IMHO. (I'll also note that this wouldn't be a "cheap" option, but require work on lots of details throughout the stack - we'd need to figure out the overview (only include the activities button on the primary monitor? or allow an overview on any monitor?), get API to control the brightness of a particular monitor (rather than the built-in one), don't use "the monitor with the top bar" as indicator for the primary monitor in Settings, ...)
Well, don't know if you are going to do that, but it would be nice to have to have this kind of thing.
"we'd need to figure out the overview (only include the activities button on the primary monitor? or allow an overview on any monitor?)" That's a good point and really should already be supported, I noticed you currently can't see what are on the other monitors in overview mode either. Some of this could hidden behind gnome-tweak-tool if it is deemed too complicated for regular users, as is done for some of the options already. "get API to control the brightness of a particular monitor (rather than the built-in one)" I'm not sure how monitors other than the ones I have access to work but usually only eDP monitors can control brightness via software, right? I know it doesn't appear to be adjustable via software on my current HDMI LCDs. If newer additional screens (eg hdmi/dp) can be adjusted through software that is probably something that should be supported as well. However, I have seen ads for some newer monitors that appear to possibly be only adjustable via software, I don't know if they do that over the HDMI/DP connection or via some other manner, eg USB.
Someone pointed out to me that Gnome Shell is actually the only major desktop environment that doesn't work well with multi monitor setup, so I took a look to see if that was actually true. The only one I found that doesn't is Budgie which is based on Gnome Shell and they are intending to fix the issue in their next release, with an open approved issue #436.
Created attachment 349543 [details] Cinnamon Desktop
Created attachment 349544 [details] KDE
Created attachment 349545 [details] LXDE
Created attachment 349546 [details] Ubuntu Unity
Created attachment 349547 [details] XFCE
Apparently Budgie is planning to fix #436 in part by dropping GTK/Gnome entirely and switching to Qt.
I second the need for this. Unity supports tracking the active monitor and shows notifications, opens apps and let me use the dash and HUD on the one currently active. Gnome however forces me to always move back to the primary which requires far more mouse motion.
I have been using dual monitor system for a while now, and I can hopefully add a few use cases that I think are missing from the Shell. 1. By default gnome-shell treats second monitor as external monitor. Which means, that I am limited to only one workspace on one monitor. This is sub-optimal as I rarely want to stare at the same workspace while I keep on switching workspace on other monitor. 2. Missing top panel makes the second screen look weird as maximized windows appear at different heights. 3. With more apps using application menu, we have to go across almost 2 entire screens just to open something like preference. (assuming primary display is on left) 4. If the primary display is on right, system settings is on the right most corner, which is again up to 2-screen wide sweep. 5. The task switcher (the popup when you keep alt pressed + tab) appears only on the primary screen. These are just few of the frustrating operations that make no sense on a multi-monitor setup. So far I have been using multi-monitor-addon (mentioned above) to solve most of these. But having to use a third-party addon to achieve basic desktop functionality is something that needs to be given second thought in my opinion.
I'd like to add that the idea for a top bar that clones to each monitor isn't a strange request. Using 2 large, widescreen, monitors means that without the ability to have the same bar on each monitor a user is switching focus more often than is necessary, add another monitor and you've got a huge amount of eye travel for some very basic tasks. The multi-monitor extension is an alright workaround but it's simply not ideal as you can't fully replicate the top bar on all monitors. From what I can tell, and this is only a cursory look, full replication isn't possible at present even writing an extension. This is a UX issue and the argument that people only want this because other OS/Desktops have it is tone deaf. It is a usability issue and a useful feature that is implemented in other OSs and many other Desktops. Expecting what quite a few people expect as basic desktop functionality isn't an illogical thing. I think this is something the Gnome Shell team needs to consider. I second pretty much everything PioneerAxon has said only add an entire other monitor to his complaints about mouse travel. The added eye movement and mouse travel are unnecessary and could be mitigated by implementing a feature that has been present in multiple desktops for many years.
Hi. I am really missing top-bar cloning on multiple monitor, because I am using dual-head setup as a separate & independent displays, mostly. There are two major use cases (IMO): 1. 1st display for work and a 2nd display as a preview ("Workspaces only on primary" enabled works great here, topbar is not required for 2nd screen). This is a Gnome3 default and it is ok. 2. Both displays are used for work. This mode is best known from the latest macOS, where user can just enable separate workspaces (topbar is cloned, workspaces are separate). It would be nice to have such possibility with Gnome3. And for the 2nd case the cloned top-bar is required. Users are going to achieve this by disabling "Workspaces only on primary" and top-bar cloning, that's why they're writing here. Same as me. I know that Gnome3 is not a macOS, but we're talking about most efficient work with DE. This proposal sounds very promising https://wiki.gnome.org/Projects/GnomeShell/DesignerPlayground/MultipleMonitors Any chances?
(In reply to marcin.j.nowak from comment #27) > 2. Both displays are used for work. This mode is best known from the latest > macOS, where user can just enable separate workspaces (topbar is cloned, > workspaces are separate). It would be nice to have such possibility with > Gnome3. Per-monitor workspaces would either require changes to the EWMH spec, or GNOME dropping compliance with the spec (see [0] and the _NET_CURRENT_DESKTOP/_NET_WM_DESKTOP properties) Now wayland does not expose those details to clients, so compositors are much less bound to a particular behavior (at the cost of cross-desktop docks/task switchers/etc.); I therefore wouldn't dismiss the second option altogether, but it's neither a small change nor something I'd expect in the near future. [0] https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200477421552 > And for the 2nd case the cloned top-bar is required. A real cloned top bar isn't in the cards - the best we can do is put a top bar on every monitor, and ask extension authors to consider "secondary" bars when adding items to the "primary" one.
Thank you for a reply. As a workaround I can use "Always on visible workspace" option for main window on the 1st display and switch (wide) workspaces. This will allow me to work on 2nd display, while 1st display will remain almost untouched. I am using Multi Monitors extension [0], but there is only one thing missing - a widget with sound/network/bluetooth/user properties. Almost everything else is already cloned somehow. I like Gnome3, because it is well integrated, it has awesome launcher/dash, it is extensible, it has hidpi support, and many, many more. It is not stable as XFCE yet and consumes too much RAM and battery, but I belive it will became a standard DE in the near future. Having a "better" multi-head support will make Gnome a winner, even comparing to macOS. I'd like to see such feature built in into Gnome, without any hacks and workarounds. Fingers crossed. I can't say anything about technical issues or EWMH spec. Don't get me wrong - I'm just sharing my thoughts as a regular user, not a developer. [0] https://extensions.gnome.org/extension/921/multi-monitors-add-on/
I think to be possible do that, is necessary: 1- Split extensions by categories (this will handled in a good way the interaction of an extension with all panels, as the extensions will extends for a control class that limited the possibility of the extensions making it more controllable). - General extensions. - Panel extensions. All panel extensions will have one and only one actor inside the panel, they can add more actors inside this actor and this one actor will be provided by gnome shell controlled class. Then it's easy move the actor between panels, as is one actor per extensions. 2- Allow the possibility of create more than one instance per extension. We the can have one extension in one panel and another in another panel or both running in the same panel. 3- Create a panel manager class with a list of available panels. To be possible set the actor of the extension in an specific panel. 4- Allow drag and drop the actor between panel and also set it in a panel position, to re-layout the desktop as a user request. 5- Finally, please considered take a look to the cinnamon implementation, where all this and more is possible. The only real way that this could be possible is if this come from gnome-shell. Non official extensions can not defined general desktop protocols. So, the desktop is who need to create the general abilities to organized functionalists that will not conflicted then all together.
(In reply to Lester Carballo from comment #30) > I think to be possible do that, is necessary: > > 1- Split extensions by categories (this will handled in a good way the > interaction of an extension with all panels, as the extensions will extends > for a control class that limited the possibility of the extensions making it > more controllable). > - General extensions. > - Panel extensions. > All panel extensions will have one and only one actor inside the panel, they > can add more actors inside this actor and this one actor will be provided by > gnome shell controlled class. > > Then it's easy move the actor between panels, as is one actor per extensions. > > 2- Allow the possibility of create more than one instance per extension. We > the can have one extension in one panel and another in another panel or both > running in the same panel. > > 3- Create a panel manager class with a list of available panels. To be > possible set the actor of the extension in an specific panel. > > 4- Allow drag and drop the actor between panel and also set it in a panel > position, to re-layout the desktop as a user request. > > 5- Finally, please considered take a look to the cinnamon implementation, > where all this and more is possible. > > The only real way that this could be possible is if this come from > gnome-shell. Non official extensions can not defined general desktop > protocols. So, the desktop is who need to create the general abilities to > organized functionalists that will not conflicted then all together. Actions of "Panel Extensions" are not panel specific so there no reason to make more than one instance, because both instances will do the same thing. Clone of the icon (actor) of the extension in all of panels connected to the same instance would be enough to give access to all of it's functionality without running the same code twice. Neither drag-and-drop support nor Panel manager are needed for this. Just every panel draws icons of all instanced extensions.
Nikita Goncharuk(In reply to Nikita Goncharuk from comment #31) I just mention how is implemented in cinnamon. This is one way that is proved. Is not the only one way. Drag and drop extension to some position as a user request just is mentions as one of the possibility that this way will provided. Clone the actors (is make another instance of the actor only). If you do not clone the extension on deep (and just you clone the actor), you sure will have a lot of problems. For example, where will be displayed the menu of the actor that only have one instances? You can not prevent all possibilities that a third-party extension could introduced. I just commented here, because as a user, won have the possibility of set the panels in all possible places and not have the possibility of set the actors inside the panels in all places of all panels, is the thing that i considered is more important, and the big missing pieces. This could be only possible if this come with the shell as a default option. Because this is exactly the type of thing that defined how flexible is a desktop from the user. Implement just one more possibility (panels in all monitors), is a good related start, but for same rason, panels in others positions are also important. Move the Actors to several positions inside the panel, is less important, but also very useful to avoid conflicts, because then non extensions will need to override another just to get his places. Anyway that's was my two cents, nothings more than that.
(In reply to Florian Müllner from comment #28) > Per-monitor workspaces would either require changes to the EWMH spec, or > GNOME dropping compliance with the spec (see [0] and the > _NET_CURRENT_DESKTOP/_NET_WM_DESKTOP properties) Could you elaborate on why you interpret the spec this way? From my reading the spec does not place this restriction. Perhaps you are talking about the statement that "only one [virtual desktop] can be shown on the screen at a time"? In the context of the earlier statement that "Most X servers have only a single screen" this seems to me to merely be a description of the case in which there is only one physical screen; to generalize this statement to "only one [virtual desktop] can be shown on a screen at a time" does not seem like too big of a stretch when considering the multi-screen usecase. Furthermore, I would like to express that as a multi-screen user, the UX in Gnome is very poor. I am not convinced of the merit of the concept of a static "primary" screen; the primary screen to me is whatever screen the focused window is occupying. Having to look at a different screen in order to be able to alt-tab properly, use the dash or search functions in the overview, or use the panel is quite cumbersome. To give an example of when Gnome doesn't work; I have a 2-monitor setup, in most cases I am using my big monitor to focus on, and have some chat applications and todolist open on my smaller monitor, so I want to have the big monitor as primary for purposes of using the search, alt-tab, panel, etc. However, sometimes I want to watch something in fullscreen; in that case, being able to seamlessly switch to using my secondary screen for actions that require the panel (monitoring chat notifications, pausing my music, changing my volume) is something that would really help.
This is going very off-topic from the per-monitor top bar request that this issue is about, but well ... (In reply to Kasper from comment #33) > (In reply to Florian Müllner from comment #28) > > Per-monitor workspaces would either require changes to the EWMH spec, or > > GNOME dropping compliance with the spec (see [0] and the > > _NET_CURRENT_DESKTOP/_NET_WM_DESKTOP properties) > > Could you elaborate on why you interpret the spec this way? From my reading > the spec does not place this restriction. Perhaps you are talking about the > statement that "only one [virtual desktop] can be shown on the screen at a > time"? In the context of the earlier statement that "Most X servers have > only a single screen" this seems to me to merely be a description of the > case in which there is only one physical screen; to generalize this > statement to "only one [virtual desktop] can be shown on a screen at a time" > does not seem like too big of a stretch when considering the multi-screen > usecase. First not that "screen" does *not* mean "monitor" - it is an X11 concept that abstracts a particular combination of display and input devices. Mutter (and therefore gnome-shell) doesn't support more than a single screen, so the multi-screen scenario is not relevant at all - we do support multiple *monitors* of course, but as I said, that's not directly tied to X11 screens. To answer your question: The spec specifies properties for the number of workspaces and the index of the active workspace, both are set on the (unique) root window - that is, it is impossible to express separate per-monitor properties while still complying with the spec. (Although as we are moving to wayland, compliance with EWMH is becoming less important than it used to be.)
Also tracking in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3091
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.