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.
--- Xinerama Support ------------
| (*) panel spans all screens
| ( ) panel only on screen ^v
Created attachment 7250 [details] [review]
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]
Created attachment 7981 [details] [review]
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]
Obsoleted by unified diff version.
Comment on attachment 8128 [details] [review]
yet another diff
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
------ | |
| | | |
| | ------
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
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
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).
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.