After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 73475 - panel doesn't span multiple monitors
panel doesn't span multiple monitors
Product: gnome-panel
Classification: Other
Component: panel
Other other
: Normal enhancement
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 70295 (view as bug list)
Depends on:
Blocks: randr-tracker
Reported: 2002-03-05 02:30 UTC by jonathankoren
Modified: 2020-11-07 12:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

panel patch (20.19 KB, patch)
2002-03-19 18:29 UTC, jonathankoren
none Details | Review
unified diff (39.21 KB, patch)
2002-04-27 05:46 UTC, jonathankoren
none Details | Review
unified diff (39.21 KB, patch)
2002-04-27 05:47 UTC, jonathankoren
none Details | Review
yet another diff (39.21 KB, patch)
2002-05-02 20:21 UTC, jonathankoren
none Details | Review

Description jonathankoren 2002-03-05 02:30:48 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 [0]^v
Comment 1 jonathankoren 2002-03-19 18:29:26 UTC
Created attachment 7250 [details] [review]
panel patch
Comment 2 jonathankoren 2002-03-19 18:31:29 UTC
The attached patch closes #73475 and #73476.  This patch will need
to be be migrated forwarded into the 1.5.x branch.
Comment 3 Kjartan Maraas 2002-03-20 18:53:01 UTC
Please use unified format when doing diffs. diff -u :)

Thanks a lot for the patch.
Comment 4 Kjartan Maraas 2002-04-27 00:20:16 UTC
Any chance of you resubmitting the patch with diff -u format?
Comment 5 jonathankoren 2002-04-27 05:46:55 UTC
Created attachment 7980 [details] [review]
unified diff
Comment 6 jonathankoren 2002-04-27 05:47:06 UTC
Created attachment 7981 [details] [review]
unified diff
Comment 7 Kjartan Maraas 2002-05-02 13:27:55 UTC
It looks like the patch is reversed. This actually removes the code :)

Rediff? diff -u gnome-core.original gnome-core.patched
Comment 8 Kjartan Maraas 2002-05-02 13:29:02 UTC
*** Bug 70295 has been marked as a duplicate of this bug. ***
Comment 9 jonathankoren 2002-05-02 20:21:47 UTC
Created attachment 8128 [details] [review]
yet another diff
Comment 10 George Lebl 2002-05-14 18:48:19 UTC
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.
Comment 11 jonathankoren 2002-05-15 01:52:11 UTC
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...
Comment 12 George Lebl 2002-05-16 09:21:16 UTC
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.
Comment 13 George Lebl 2002-05-16 09:39:16 UTC
*** Bug 70295 has been marked as a duplicate of this bug. ***
Comment 14 Kjartan Maraas 2002-10-13 13:26:05 UTC
Close this as fixed in 2.0.x? Or is it still not fixed there?
Comment 15 xavier.bestel 2002-10-13 17:38:19 UTC
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.
Comment 16 Luis Villa 2003-02-09 02:42:42 UTC
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...
Comment 17 Luis Villa 2003-02-09 02:53:13 UTC
Argh. Apologies for the double spam. Actually closing this time.
Comment 18 Mark McLoughlin 2004-02-23 09:08:12 UTC
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 19 Luis Villa 2004-04-28 04:37:42 UTC
Comment on attachment 7250 [details] [review]
panel patch

Obsoleted by unified diff version.
Comment 20 Luis Villa 2004-04-28 04:39:20 UTC
Comment on attachment 8128 [details] [review]
yet another diff

Against 1.4.
Comment 21 Jonathan Koren 2004-04-28 16:59:06 UTC
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...
Comment 22 xavier.bestel 2004-04-28 17:54:36 UTC
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.
Comment 23 lsof 2004-10-28 14:44:26 UTC
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).

Comment 24 Chris Rose 2007-02-28 17:12:44 UTC
Ubuntu bug about this:
Comment 25 me 2009-10-24 08:07:39 UTC
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"?
Comment 26 me 2009-10-24 08:34:20 UTC
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.
Comment 27 André Klapper 2020-11-07 12:16:09 UTC is being replaced by 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

Thank you for reporting this issue and we are sorry it could not be implemented.