Red Hat Bugzilla – Bug 650638
Unable to add any applets to panel on second screen.
Last modified: 2012-08-16 16:17:25 EDT
Description of problem:
+ Fresh install in Fedora 14.
+ Closed source NVidia dirvers ( need Dual-Link DVI support for 30" monitor )
+ Dual monitors, each monitor running as separate X server.
Attempts to add anything to panels on the second screen result in the error
"...." has quit unexpectedly, tried "Clock", "Workspace Switcher", ...
No issues with Prior Fedora releases F10,11,12,13.
I've tried creating new panels - no joy
I've deleted all panels from he 2nd screen, then relogged in. New panels are
created and default applets are added, but they all die immediately.
Version-Release number of selected component (if applicable):
If I try restarting gnome-panel with ...
gnome-panel --replace --display=:0.0
gnome-panel --replace --display=:0.1
The display where I run the command from will successfully start its applets, the other one errors - so it appears to be a regression with managing multiple X-displays
Found a someone else reporting the issue on an ArchLinux forum. They have raised a Gnome bug ...
I have the same problem: Fresh Fedora 14 installation, NVidia videocard with drivers installed from RPMFusion, monitors are configured as separate X servers, all the installed packages are updated to current versions, most of applets cannot be added to a panel on the second display.
BTW, I noticed: When I try to add an applet (such as clock) to a panel on the second display, very small window is appearing on the first display. I am able to enlarge that window. The window content is empty, title is "clock-applet". "Window list" on the first display shows the button for this window. If I close the window, error message is appearing on the second display: ""Clock" has quit unexpectedly. ..."
BTW, some applets do work. For example, "Connect to Server", "Dictionary look up", "Drawer", "Dwell Click", "Force Quit", "Invest", "Man Menu", "Menu Bar", while some most important applets do not. "Clock", "Window List", "Window Selector", "Workspace Switcher" do NOT work.
This is obviously a regression, because I am working with dual head configuration for years.
Ok to try and get this moving I've spent a few hours with a debugger
stepping through the code.
I can see what looks to be wrong, only my C is too rusty to work out
how to fix it. - Hopefully with following info a developer can
take it and work out the fix.
This is based on the code from gnome-panel-22.214.171.124
The function panel_applet_container_get_applet() works out what screen the applet should be
on with the following call...
482 screen = gdk_screen_get_number (gtk_widget_get_screen (container->priv->socket));
( in the debugger I screen was assigned "1" if I altered it to "2" in the debugger the applet would
start correctly on the second X-Display )
So looking in ./gtk+-2.22.0/gtk/gtkwidget.c you have ( edited a little for clarity )...
gtk_widget_get_screen() tries to get the screen based on widget. If screen is NOT set it returns the default screen - this is what is happening.
7599 gtk_widget_get_screen (GtkWidget *widget)
7601 GdkScreen *screen;
7603 g_return_val_if_fail (GTK_IS_WIDGET (widget), NULL);
7605 screen = gtk_widget_get_screen_unchecked (widget);
7607 if (screen)
7608 return screen;
7618 return gdk_screen_get_default ();
So checking gtk_widget_get_screen_unchecked() from the same file,
1. It gets the top level widget with , gtk_widget_get_toplevel().
This is works fine - I'm assuming this is the Panel itself ??
2. Then we call gtk_widget_is_toplevel() to ensure it really has
toplevel widget ( the function check if the flag GTK_TOPLEVEL is set )
3. The flag IS NOT SET so the function returns FLASE ( even if the applet
is added to a panel on default screen ) so his function returns NULL,
which is why the above code returns the default screen - which is
fine for applets added to a panel on the default screen.
7563 static GdkScreen *
7564 gtk_widget_get_screen_unchecked (GtkWidget *widget)
7566 GtkWidget *toplevel;
7568 toplevel = gtk_widget_get_toplevel (widget);
7570 if (gtk_widget_is_toplevel (toplevel))
7572 if (GTK_IS_WINDOW (toplevel))
7573 return GTK_WINDOW (toplevel)->screen;
7574 else if (GTK_IS_INVISIBLE (toplevel))
7575 return GTK_INVISIBLE (widget)->screen;
7578 return NULL;
According to the comments in ./gtk+-2.22.0/gtk/gtkwidget.c
"only #GtkWindow and #GtkInvisible are toplevel widgets",
which a gnome-panel doesn't seem to be.
I tired altering panel-widget.c to call _gtk_widget_set_is_toplevel() anyway but I couldn't get it to link as it couldn't resolve _gtk_widget_set_is_toplevel().
me too ...
This makes the Fedora14 gnome desktop unusable for me.
Me too... This is a serious issue, and it makes my second monitor (which I use a lot) totally useless... :(
I see this issue as well in my installation of Fedora 14. It appeared after I upgraded my Dell laptop from F13 to F14. In F13, I was able to add applets to any and all panels on the second X screen. The first time I loaded F14/gnome with the second X screen, all applets crashed. If, for example, I try to add a clock applet to the panel on the top of the screen, I get a pop up window saying:
"Clock has quit unexpectedly"
If you reload a panel object, it will automatically be added back to the panel.
If I click "Reload" the window reappears.
There has been a partial fix submitted under the gnome bug ...
Applications not start, just a problem with their menus appearing on the wrong screen.
Anything we can do to prod this along would be much appreciated. I now realize how important the clock applet is....
I'm seeing this as well; I switched over to this configuration today to make working with 2X easier.
I have 2 video cards and 2 monitors...On the second screen, any applet added to the panel just returns: "<applet name>" has quit unexpectedly". No errors are appearing in ~/.xsession-errors to report.
I did this exact same configuration in Fedora 13 last year with out a problem.
I've tried adding a new panel, adding applets to both top and bottom, nothing, just errors out.
How can we get the partial bug fix noted in https://bugzilla.gnome.org/show_bug.cgi?id=632369 comment #21 to be added to the Fedora updates?
Alternatively, has anyone tried downgrading to gnome-panel 2.30? I have not been able to locate a fc14 rpm for version 2.30, but the fc13 rpm is still out there:
Normally, that's a really unclean solution since your downgrading a core piece of a much bigger overall package that's going to cause dependency issues. I think we've mostly established that it's a regression anyhoo.
Bump to getting this rolled into a patch for F14.
I've tried to build the x86_64 package using the patches in message 8. Unfortunately, I'm not that adept at such things and I am running into issues building the clock help documentation (some kind of xml issue). Anyone else successfully built this?
I hacked my way through and I have what appears to be a working x86_64 patch for anyone that is interested. I couldn't compile the help directory for some unknown reason.
Here is a link: http://vespa.chem.umd.edu/~paul/gnome-panel-patch_x86_64.tar
No guarantees. Use it at your own risk.
I should point out that those are RPMS in the archive.
I have the same/similar bug - when I boot up, many applets on the second panel report having "quit unexpectedly" - Clock, Trash, Workspace Switcher, Notification Area, Window List, and I get the message: 'The panel encountered a problem while loading "OAFIID:GNOME_FastUserSwitchApplet" '. If I select the reload option for any of these, I immediately get another "quit unexpectedly" message. Windows I open on this second display panel are all missing what I would call the title bar, the one that lets you click to expand, close, etc.
Setup here is:
Fedora 14 Kernel 2.6.35-11-83.fc14.x86_64 GNOME 2.32.0
Nvidia GTX 460 card with Nvidia driver via akmod-nvidia
This makes second display basically useless...
Thanks in advance for any bug fixes.
Does anyone know if this bug is present in the upcoming GNOME 3?
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: