Bug 650638 - Unable to add any applets to panel on second screen.
Unable to add any applets to panel on second screen.
Product: Fedora
Classification: Fedora
Component: gnome-panel (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-11-07 09:43 EST by Andy Campbell
Modified: 2012-08-16 16:17 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-16 16:17:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andy Campbell 2010-11-07 09:43:07 EST
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):

How reproducible:

See Above.
Comment 1 Andy Campbell 2010-11-07 14:43:50 EST
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

Comment 2 Andy Campbell 2010-11-09 06:13:17 EST
Found a someone else reporting the issue on an ArchLinux forum.  They have raised a Gnome bug ...

Comment 3 Van de Bugger 2010-11-22 06:54:30 EST
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.
Comment 4 Andy Campbell 2010-12-04 13:55:27 EST
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-

In   gnome-panel/libpanel-applet-private/panel-applet-container.c

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.

 7598 GdkScreen*
 7599 gtk_widget_get_screen (GtkWidget *widget)
 7600 {
 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;
 7609   else
 7610     {
 7618       return gdk_screen_get_default ();
 7619     }
 7620 }

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)
 7565 {
 7566   GtkWidget *toplevel;
 7568   toplevel = gtk_widget_get_toplevel (widget);
 7570   if (gtk_widget_is_toplevel (toplevel))
 7571     {
 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;
 7576     }
 7578   return NULL;
 7579 }

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().
Comment 5 Need Real Name 2010-12-31 23:54:12 EST
me too ... 

This makes the Fedora14 gnome desktop unusable for me.
Comment 6 DirkReiners 2011-01-27 19:11:03 EST
Me too... This is a serious issue, and it makes my second monitor (which I use a lot) totally useless... :(
Comment 7 Daniel Siderius 2011-02-22 11:34:42 EST
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.
Comment 8 Andy Campbell 2011-02-22 14:44:02 EST
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.
Comment 9 Daniel Siderius 2011-02-22 17:30:20 EST
Anything we can do to prod this along would be much appreciated. I now realize how important the clock applet is....
Comment 10 Jase Whipp 2011-03-03 15:10:16 EST
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.
Comment 11 Daniel Siderius 2011-03-14 10:30:29 EDT
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?
Comment 12 Daniel Siderius 2011-03-14 10:44:35 EDT
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:

Comment 13 Jase Whipp 2011-03-14 13:25:23 EDT
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.
Comment 14 Paul Paukstelis 2011-03-14 14:09:53 EDT
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?
Comment 15 Paul Paukstelis 2011-03-15 13:24:58 EDT
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.
Comment 16 Paul Paukstelis 2011-03-15 13:49:01 EDT
I should point out that those are RPMS in the archive.
Comment 17 John Dvoracek 2011-03-22 17:31:42 EDT
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.
Comment 18 Daniel Siderius 2011-04-07 08:44:49 EDT
Does anyone know if this bug is present in the upcoming GNOME 3?
Comment 19 Fedora End Of Life 2012-08-16 16:17:25 EDT
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: 

Note You need to log in before you can comment on or make changes to this bug.