Add support for top bars on all monitors to allow for multi-monitor support in primary extensions - apps-menu, places-menu, topbar, etc

[Chris Cheney]

This issue will effectively be a regression in desktop usage once Ubuntu switches from Unity to Gnome Shell. Gnome Shell does not work well with multiple monitors unlike every other desktop environment except Budgie, which is switching away from GTK/Gnome to Qt with Budgie 11 due out in the next month or two.

I reported it upstream last month but it does not appear to have much traction at the moment.

https://bugzilla.gnome.org/show_bug.cgi?id=780078

"
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.
"

And see comments #11 and #14 from Florian.

"
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.
"

"
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, ...)
"

[Ccheney-8 (ccheney-8)]

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.

[Ccheney-8 (ccheney-8)]

Created attachment 347984
Gnome 2

[Ccheney-8 (ccheney-8)]

Created attachment 347985
Windows 8

[Ccheney-8 (ccheney-8)]

Created attachment 347986
Windows 10

[Ccheney-8 (ccheney-8)]

Created attachment 347988
Mate 1.18.0

[Allan Day (allanday)]

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?

[Florian-muellner (florian-muellner)]

(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/

[Ccheney-8 (ccheney-8)]

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.

[Ccheney-8 (ccheney-8)]

Created attachment 348094
Gnome 3

[Ccheney-8 (ccheney-8)]

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.

[Allan Day (allanday)]

(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.

[Florian-muellner (florian-muellner)]

(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.

[Ccheney-8 (ccheney-8)]

(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.

[Ccheney-8 (ccheney-8)]

Is there anything else needed, I noticed the BZ is still set to NEEDINFO

[Florian-muellner (florian-muellner)]

(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, ...)

[Renan-biegel (renan-biegel)]

Well, don't know if you are going to do that, but it would be nice to have to have this kind of thing.

[Ccheney-8 (ccheney-8)]

"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.

[Ccheney-8 (ccheney-8)]

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.

[Ccheney-8 (ccheney-8)]

Created attachment 349543
Cinnamon Desktop

[Ccheney-8 (ccheney-8)]

Created attachment 349544
KDE

[Ccheney-8 (ccheney-8)]

Created attachment 349545
LXDE

[Ccheney-8 (ccheney-8)]

Created attachment 349546
Ubuntu Unity

[Ccheney-8 (ccheney-8)]

Created attachment 349547
XFCE

[Ccheney-8 (ccheney-8)]

Apparently Budgie is planning to fix #436 in part by dropping GTK/Gnome entirely and switching to Qt.

[Rasmus Eneman (pie-or-paj)]

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.

[Tim Lunn (darkxst)]

I think in general GNOME3 does quite well on multiple monitors, atleast in GNOME shell (don't think I have ever run Classic on my 3 monitor setup). I know a lot of work has gone into the mechanics of supporting multiple monitors over the years. Overview shows your windows grouped on the monitor that they are on. you can move windows between monitors with keyboard shortcuts (or context-menu) etc and lots of other little details have been worked on, like configuration etc.

I originally wrote the multiple monitor panels extension as an experiment with the hope of getting some of the bits upstreamed, but it probably raised more questions than it answered, I wasnt particularly happy with the result because it just didn't scale well past 2 monitors. And then I moved onto more important things like working on Ubuntu integration in upstream gnome.

I agree with Florian that it doesnt make sense to duplicate things across monitors, if
 they are not relevant to that specific monitor. This leaves two main items:
- the app-menus (application specific ones), although I really hope these go away eventually, with CSD decorations they would make more sense in the headerbar (which is actually what happens in classic and other GNOME based DE's I believe)
- the workspace thumbnail switchers

The latter are tricky when I duplicated the switchers across monitors in my extension, they only show ed the content of the monitor they were on. Straight away everyone wanted to be able change independent monitors to different workspaces ;( Doing a single switcher with a panorama view of all monitors just doesnt scale well if you have say 3-4 monitors. There is a reason these haven't been fixed yet, its very hard to come up with a design to works for everyone. This perhaps raises the bigger question of linux workspaces in the traditional sense perhaps dont scale well to multiple monitors in some senses!

Anyway back to your top panel question, having a hidden option to simply duplicate the top panel across monitors would be technically fairly easy to do (either as extension or as core code). However its not something I or the upstream devs are likely to work on.

[PioneerAxon (arth-svnit)]

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.

[Mark L. Potter (romeosidvicious)]

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.

[Aaron Peromsik (aperomsik)]

Users switching from Unity to GNOME... or from almost any other environment to GNOME... are going to find the current panel arrangement inconvenient. I am not used to moving the mouse all the way to the far edge of the other monitor when I want to log out, or suspend, or adjust volume... and I shouldn't have to.

[Marcin-j-nowak (marcin-j-nowak)]

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?

[Florian-muellner (florian-muellner)]

(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.

[Marcin-j-nowak (marcin-j-nowak)]

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/

[Lester Carballo Pérez (lestcape)]

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.

[Nmg921 (nmg921)]

(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.

[Lester Carballo Pérez (lestcape)]

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.

[Andreas Vinsander (andreas-vinsander)]

I agree with comment #2. Just upgraded to Ubuntu 17.10 from 17.04 and the new behavior drives me crazy. Is it upstream that needs to do something or can it be fixed by Ubuntu devs?

[Vlad Svitlichniy (vsv-dev)]

What keeps me bothering: why should a desktop environment distinguish between "primary" and "additional" monitors at all? In Unity land, all the monitors are first-class citizens, and this approach works perfectly.

[Kaspermv+gnomebugzilla (kaspermv+gnomebugzilla)]

(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.

[Florian-muellner (florian-muellner)]

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.)

[Chris Billington (cjbil1)]

Agreed. Distinguishing between monitors serves no purpose. Like everyone else I have strong muscle memory to look to the top right of my screen when I want to see status indicators, or to look to the top to see the time, or to move my mouse to the top right to change the volume. This muscle memory has no concept of whether I am looking at my 'primary' monitor or not, and feels a half second of confusion each time I try to do one of these things on a second monitor, which is the hallmark of bad interface design. I think I'm subconsciously adapting to just not use the second monitor much, and that's a stupid outcome too.

Of course indicators have nothing to do with the specific monitor they're on, but they have nothing to do with the primary monitor either, so why are they there? They're there to give quick visual and interactive access to certain frequently accessed information and functionality, quick enough that you apparently don't want to have to hit a few keypresses to get them. By the same logic you shouldn't have to drag your mouse over increasingly large screen real estate.

Unity had it right in this regard. There should be just monitors, no primary or secondary. It's a pointless distinction, and whilst I accept it might be technically difficult to achieve given the current architecture of gnome-shell, to insist on it as a design decision is silly.

[Timothée Jeannin (timojeajea)]

I switched from unity to gnome with Ubuntu 18.04, it's quite annoying to have to go to the other monitor just to adjust the audio volume. I think all monitors should have the top bar by default. I agree that login out of the session is not very frequent but adjusting the volume is a very frequent action on the other hand ...

[Che (che-fisher)]

I second the notion that adding support for multiple top bars would be a step in the right direction for multi-monitor support.

Also in regards to the comment that it would be non-trivial to implement this, in particular the part about: "[can't] use the monitor with the top bar as indicator for the primary monitor in Settings" - that sounds strictly like a code improvement, and a good reason to do this.

The primary monitor should have a unique attribute that designates it this way - other features tied to or built on top of it should not act as the method for determining which monitor is the primary one in the first place - we're breaking the single utility principle here no? It certainly would feel wrong to me if I tweaked my own Linux system and moved the top bar to a secondary display and suddenly the Ubuntu OS started treating that one as my primary display.

This refactoring would also make changes like this in the future much easier to achieve, since the stack doesn't have un-intuitive relationship to monitor components (it instead relates directly to the monitor class/module/object). Just my 2c.

[Josef Vrba (czjvic)]

I have same issue as Timothée Jeannin describes. Did you every try to works with 3+ monitors? You want same behavior on all monitors. Yo do not want primary monitor. Primary monitor is history...

[Donald E. Lund (drdlund)]

I would like to see this implemented too.

[Stefan H (ubuntut654)]

I have upgraded from 16.04 to 18.04 and I am missing the top bar on multiple monitors.
I would like to have this feature by default.

[Timothée Jeannin (timojeajea)]

Any update on this?

[Daniel van Vugt (vanvugt)]

Also tracking in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3091

[WHK (yan-uniko-102)]

I would like to see the time in the top bar or my notifications while playing full screen on the primary screen from steam. Is it too much to ask?

[Sun-Zhihao (aypollo9)]

When I am in the full-screen on the primary monitor, the top bar is blocked, so it is necessary for me to show the top bar in another monitor. It is truely a bug to be fixed, but the Linux seems not to be aware of it.

[Sun-Zhihao (aypollo9)]

actually, the shell extension(in ubuntu software) Multi Monitors Add-On works, although it is not perfect

[Fred Koschara (fke-internet)]

I depend on having the clock displayed on *every* monitor I'm working with, so not having the top bar on secondary displays is a major no-no, IMHO.

[Gnome-sysadmin (gnome-sysadmin)]

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.

[Stefan (boldos)]

Yes, this is a very required feature.
When working with (or presenting to) external displays, it is necessary to:
- see time
- have access to calendar
- Some apps are missing top bars.

Very appreciated.

[Daniel van Vugt (vanvugt)]

This is an upstream gnome-shell feature request so it should be discussed there:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4603