Bug 650638

If I try restarting gnome-panel with ...

  gnome-panel --replace --display=:0.0
or
  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

Andy

Found a someone else reporting the issue on an ArchLinux forum.  They have raised a Gnome bug ...

https://bugzilla.gnome.org/show_bug.cgi?id=632369

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-2.32.0.2


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;
 7602 
 7603   g_return_val_if_fail (GTK_IS_WIDGET (widget), NULL);
 7604 
 7605   screen = gtk_widget_get_screen_unchecked (widget);
 7606 
 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;
 7567 
 7568   toplevel = gtk_widget_get_toplevel (widget);
 7569 
 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     }
 7577 
 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().

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 ...

https://bugzilla.gnome.org/show_bug.cgi?id=632369

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:

http://pkgs.org/fedora-13/fedora-updates-x86_64/gnome-panel-2.30.0-4.fc13.x86_64.rpm.html

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping