GNOME Bugzilla – Bug 73475
panel doesn't span multiple monitors
Last modified: 2020-11-07 12:16:09 UTC
The panel used to span multiple monitors when using xinerama. Someone decided that this was a Bad Thing(tm) and decided to limit the panel to only one user configurable screen. Removing the ability to have the panel span multiple monitors is a Bad Thing(tm). The user should be able to enable the old behavior through the panel's configure dialog. example: --- Xinerama Support ------------ | (*) panel spans all screens | ( ) panel only on screen [0]^v -------------------------------------------
Created attachment 7250 [details] [review] panel patch
The attached patch closes #73475 and #73476. This patch will need to be be migrated forwarded into the 1.5.x branch.
Please use unified format when doing diffs. diff -u :) Thanks a lot for the patch.
Any chance of you resubmitting the patch with diff -u format?
Created attachment 7980 [details] [review] unified diff
Created attachment 7981 [details] [review] unified diff
It looks like the patch is reversed. This actually removes the code :) Rediff? diff -u gnome-core.original gnome-core.patched
*** Bug 70295 has been marked as a duplicate of this bug. ***
Created attachment 8128 [details] [review] yet another diff
I think we should wait with this kind of change till 2.0 since 1.4.1 is way behind and this is really an enhancement rather then a bugfix, so I don't think we want to risk destabilization. Can you guys port the patch to 2.0? I'll be happy to apply it there. For now I've added a check for an env var GNOME_PANEL_NO_XINERAMA, so if you set that the panel will ignore xinerama and will span screens. For 2.0 we can solve this the right way.
How is adding this code, which doen't effect anything else, any different than adding a check for an environment variable, except for the fact with the patch remedy is now both obvious and readily accessable to the user? Some could also argue that it's a fix to an incomplete feature...
Now we're getting into semantics, but realistically gnome2 will be out VERY SOON and this does add a LOT of code to the panel and it can potentially have bugs. Since 1.4 should pretty much be kept rock stable I don't think it should go in. The check for an env var is 2 lines of code which is very easily verified. Plus you can only set it as an env var thus then you know that you're turning of xinerama support and thus agree to deal with panels being offscreen potentially Hmmm I changed this to a GNOME2.x milestone.
Close this as fixed in 2.0.x? Or is it still not fixed there?
It is indeed fixed in 2.0.x - now there are other weird behaviors with Xinerama, but I think they're mostly WM-related, and hp said he was waiting for GTK+2.2 (which has better multihead support) to fix Metacity.
Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If y0u feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
Argh. Apologies for the double spam. Actually closing this time.
Re-opening this because what the reporter is actually requesting is that the panel *doesn't* do anything special for Xinerama and should span the entire screen (as opposed to monitor) width. See bug #73475. Jonathan: could you try and explain why you think this behaviour is useful? Personally, I think that spanning only a single monitor is most useful since most people I've seen use Xinerama for "multi-head which allows you drag stuff between screens". (And please, no rants this time :-)
Comment on attachment 7250 [details] [review] panel patch Obsoleted by unified diff version.
Comment on attachment 8128 [details] [review] yet another diff Against 1.4.
The main concern is when you have a profile shared between a multihead and a single head machine. There's no problem if the panel is set to display on head 0, since both machines have a head 0. The problem comes when you have multiple panel, each set to display on a different head. (Say two bottom edge panels.) They coexist fine on a multihead machine, but when you login to the single head machine they collide. The correct behavior (and easy from an implementation standpoint) is to simply allow the panel to stretch to span multiple heads. That way all applets/launchers/drawers are available whenever the user loses one or more heads. Finally, the panel should span multiple monitors for asthetics. Edge panels looked chopped off when not spanning. :) The source of my rant was twofold. First the the utter confusion of what xinerama actually is among the developers and testers, which lead directly to closing outstanding bugs as fixed when they weren't, and closing bugs as duplicates, when they weren't. The second source was appears to be a lack of input from real xinerama users when it came to the "keep on a single head" "feature". (See bug 92568.) There's a lot of xinerama users that like to access the panel from every head. (The fact that this bug is continuously refiled is proof enough of that.) Yes, everything gets squeezed together on the panel. Yes that makes the panel cramped, but when you lose >=50% of the screen space you're used to using you already feel cramped! :) I would repatch, but Debian has yet to package 2.6 and for some reason I couldn't get the entire Gnome system to compile last time I tried. (It complained about not being able to find libraries during linking, even though configure found them. Or something.) Perhaps I should try again...
I'd add a few words here. I have a Xinerama setup where the two screens don't have the same size. The panel is incredibly buggy in this mode (I can only put panels on the big screen, on the little one they just disappear and I can't delete them anymore, I think they are in the "invisible zone"). I didn't try to do too many experiments, but I believe setups with three screens like this are completely broken: ---- | | | | ---- ------ ------ | | | | | | | | ------ ------ Yes, that's three screens not the same size, not aligned. Xinerama permits this kind of weird arrangement, and depending on how is your (real) desk it may be actually useful. What happens here is that the virtual screen is rectangular and big enough to make all three real screens fit. That makes lots of "invisible zones", which current panel/metacity/wnck don't mark as invisible, and thus continue to wrongly exploit.
Hi. I reported a bug on Red Hat's bugzilla "Need option for panel to span multiple screens". I was asked to post my comments here. It would be good (as the reporter suggested) to have an option for both behaviours because there is a need for both setups. If you have two monitors next to each other, with no (or little) join between the two, then what you really have, in effect, is a single wide monitor. Spanning the entire screen is the right thing to do. If you have two monitors near each other, with a gap between them, then it makes more sense that the monitors are treated separately. Allowing a panel to be sized horizontally would fix this bug (a preference would be a nicer fix though). Ref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136787
Ubuntu bug about this: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/61479
No gentoo bug about this, but they'd just punt it upstream too. Allow me to save them the work. I've got two monitors side-by side, and while ati's crippled drivers allowed me to have one panel span one screen over two monitors. When I changed my video card to an nVidia with twinview, I now have to kludge a second panel onto monitor #2 to get coverage across both screens. It's liveable, but I'd like the panel applets to be able to expand over the middle gap. Maybe just a checkbox in panel properties to "Ignore Xinerama/twinview screen borders"?
I forgot to add, for the benefit of anyone who finds this, that a temporary work around does exist for nvidia users; Simply add: Option "NoTwinViewXineramaInfo" "True" to your "Screen" section in xorg.conf. The downside is that ALL your apps now maximize across two monitors.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.