GNOME Bugzilla – Bug 632369
Panel applets not displaying in second x session
Last modified: 2013-11-22 11:36:30 UTC
After upgrading to 2.32 there are problems with panel apps on my second X session. The Window List, Window Selector, Workspace Switcher and Show Desktop applications all do not work on the 2nd x session When they try to launch I get messages like: "Window List has quit unexpectedly." and options asking me to reload or dont reload. When i try to delete and re-add them to the 2nd sesson they pop up a window on the main x session. Gnome menu, force quit applets work fine on both sessions. Other people are having the same prob. https://bbs.archlinux.org/viewtopic.php?pid=841483#p841483
How do we get this bug changed to 'Assigned'? Or at least 'New'? There does not seem to be much attention being paid to the Bugzilla reports for gnome-panel (see https://bugzilla.gnome.org/browse.cgi?product=gnome-panel). Since there is not a straightforward workaround, could we increase the priority to 'High'? Since there is a major loss of functionality, could we raise the severity to 'Major'? (see https://bugzilla.gnome.org/page.cgi?id=fields.html#priority) For reference, there is also a Fedora bug report for this: https://bugzilla.redhat.com/show_bug.cgi?id=650638
I've got this bug too. I have a quad monitor setup running FreeBSD. This error affects two of the screens. I have tried deleting the panel, re-adding it, but still adding Window List (or probably, anything else) to it results in '"Window List" has quit unexpectedly If you reload a panel object, it will automatically be added back to the panel.'. Error. If you Reload, it fails and just brings up the same dialog box instantly. Very frustrating, as it makes the second set of monitors unusable, as if you minimize a window you can't access it again easily. If the priority could be upped, that would be good.
A temporary workaround is to use alt-tab in the second x session, but this is still ugly.
Same problem.
(In reply to comment #1) > How do we get this bug changed to 'Assigned'? Or at least 'New'? There does > not seem to be much attention being paid to the Bugzilla reports for > gnome-panel (see https://bugzilla.gnome.org/browse.cgi?product=gnome-panel). > > Since there is not a straightforward workaround, could we increase the priority > to 'High'? > > Since there is a major loss of functionality, could we raise the severity to > 'Major'? > > (see https://bugzilla.gnome.org/page.cgi?id=fields.html#priority) > > For reference, there is also a Fedora bug report for this: > https://bugzilla.redhat.com/show_bug.cgi?id=650638 Not sure how to get it assigned, when one of the maints. grabs it i guess, i agree about the severity though and have changed it to major. Lets see if anything happens?!
( N.b. I've add the following to the Fedora bug I raised as well. ) 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, it gets the top level widget in the widget linked list, gtk_widget_get_toplevel(), then calls gtk_widget_is_toplevel() to ensure it really has toplevel widget ( the widget has the flag GTK_TOPLEVEL set ) This isn't the case ( even if the applet is added to a panel on default screen ) so the function returns NULL 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.
Not so sure the problem is going to be in gtk+2.22. In both this bug reporthttp://bugs.gentoo.org/show_bug.cgi?id=348240 and my tests of a gnome-2.32 build for slackware the problem only occurs with the 2.32 series panel. If I swap back to the gnome-panel 2.30 it works as expected. I am thinking next best step may be to build and test panel release from 2.30 to 3.32 to see where it broke.
There are instructions for trying to find in commit causing this in http://bugs.gentoo.org/show_bug.cgi?id=348253#c19
I fairly sure the problem occurred with the change ... Version 2.31.92 * Stop using deprecated gdk_display/GDK_DISPLAY() (Vincent) (From the NEWS File)
(In reply to comment #9) > I fairly sure the problem occurred with the change ... > > Version 2.31.92 > * Stop using deprecated gdk_display/GDK_DISPLAY() (Vincent) > > (From the NEWS File) I doubt so. It's more likely that it's caused because the applets are now dbus-based instead of bonobo-based.
Quickly looking at the code: the issue is that when the applet is created, it's not in a widget hierarchy yet, so there's no way to find the right screen. It should be possible to tweak things to explicitly use the screen from the right panel, though.
Created attachment 179787 [details] [review] panel: Fix dbus applets to work in multiscreen environment Can you try this patch to see if it fixes the issue? When the applet is created, the frame itself is not yet added to a widget hierarchy, and is therefore not associated with any screen. So we always sent the default screen as the one to be used to the applet. We can simply use the screen of the PanelWidget that will contain the applet instead.
Test the patch. before work this morning. Built clean and gnome-panel with patch appears to be working as expected now in my "Zaphod Mode" dual Xorg server set up.
Correction. Almost works right. I went to change prefences on the my weather applet of the second display, which now loads, but the right click dropdown down menu appeared on the primary display instead. The application, places and system menu still worked correctly.
Created attachment 179797 [details] [review] libpanel-applet: Use right GdkScreen for focus request and menu Can you also apply this second patch? This might fix the menu issue you're seeing. Calling gtk_widget_get_screen() on a widget embedded in a plug doesn't necessarily return what you expect (because of gtk_widget_get_toplevel()). Instead, call gtk_window_get_screen() on the plug.
(In reply to comment #15) > Created an attachment (id=179797) [details] [review] > libpanel-applet: Use right GdkScreen for focus request and menu > > Can you also apply this second patch? This might fix the menu issue you're > seeing. I've tried both patches enabled, still the issue from comment 14 remains.
Same as Vladimir, I've applied both patches. The applets can now be added to panel, but the applet menus appear on the wrong screen.
Applied second patch no change in behavior.
This may not help any, but I am noticing with the Gnome 2.32 desktop in general it is having some issues with telling which desktop to open things on. As an example, if I open a copy of LibreOffice on desktop 2 and then try and open a copy on desktop 1, it just opens a second copy on desktop 2.
Comment on attachment 179787 [details] [review] panel: Fix dbus applets to work in multiscreen environment I'm committing this part, since it will make things a bit better, at least.
Is there any update on this bug? It is reported on the Red Hat bugzilla as well, but it does not appear that the partial fix is part of the Red Hat / Fedora update package yet. This is a serious, productivity-limiting bug. I would accept a downgrade of Gnome desktop to get the task bar and associated applets working again; I'm even considering a Fedora *downgrade* to recover those features.
(In reply to comment #22) > Is there any update on this bug? It is reported on the Red Hat bugzilla as > well, but it does not appear that the partial fix is part of the Red Hat / > Fedora update package yet. > > This is a serious, productivity-limiting bug. I would accept a downgrade of > Gnome desktop to get the task bar and associated applets working again; I'm > even considering a Fedora *downgrade* to recover those features. amen
Then, please ask your distribution to apply patches vuntz patches (like we are doing in Gentoo) as they improves this until a better fix arrives
And it'd help to have someone with an actual multiscreen setup debug this properly... I can't do better than bling guessing, and it's really time-consuming.
Is there a way to find a simple explanation on how to apply the above patches? Are the patches applied, then gnome recompiled? Maybe I just don't know enough and will have to wait to see if Fedora pushes a patch... I have the same bug in Fedora 14 - 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...
(In reply to comment #26) > Is there a way to find a simple explanation on how to apply the above patches? > Are the patches applied, then gnome recompiled? Maybe I just don't know enough > and will have to wait to see if Fedora pushes a patch... > > I have the same bug in Fedora 14 - 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... You should only need to apply the patches to gnome-panel and recompile that.
(In reply to comment #25) > And it'd help to have someone with an actual multiscreen setup debug this > properly... I can't do better than bling guessing, and it's really > time-consuming. I can be lab rat for you on this. Gnome-Panel is a bit out side my current skill scope. I can follow directions if this will help any.
> You should only need to apply the patches to gnome-panel and recompile that. If it's not too complicated, could you just sketch the steps involved, and I'll research the details? I've searched for directions on applying a patch and recompiling a Fedora RPM but not found much (that I can use). TIA if possible.
I applied the attached patches. This allowed me to add the problem applets on the second display. The only problem that I noticed was that when I right click on any of these applets the popup menu shows up on the first display instead of the second.
The patch 'libpanel-applet: Use right GdkScreen for focus request and menu' does not fix the problem with the context menu popuping up on the wrong screen for me. @John Dvoracek. I don't know about rebuilding the RPM but here are the commands for Debian: mkdir gnome-panel cd gnome-panel sudo apt-get build-dep gnome-panel sudo apt-get source gnome-panel wget https://bugzilla.gnome.org/attachment.cgi?id=179787 -Opanel-Fix-dbus-applets-to-work-in-multiscreen-envi.patch wget https://bugzilla.gnome.org/attachment.cgi?id=179797 -Olibpanel-applet-Use-right-GdkScreen-for-focus-requ.patch cd gnome-panel-2.32.1 patch -p1 <../panel-Fix-dbus-applets-to-work-in-multiscreen-envi.patch patch -p1 <../libpanel-applet-Use-right-GdkScreen-for-focus-requ.patch debuild -us -uc cd .. sudo dpkg -i *.deb For RPM you need to get the source RPM, apply the patches and build the binary RPM with the rpmbuild command.
Review of attachment 179797 [details] [review]: This did not work for me. Popup menus still appear on the primary display when right clicked on the secondary display.
@Vincent Untz, if you give me some pointers I might be able to debug this problem since I have a multi-display system and am building the package from source. How does the popup menu get activated? One thing that is interesting is that if I right click on the Desktop Switcher applet on the secondary display the popup menu appears on the primary display but when I select 'Preferences' from the menu the new windows flashes briefly on the primary display but then appears on the secondary display.
*** Bug 649984 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > @Vincent Untz, if you give me some pointers I might be able to debug this > problem since I have a multi-display system and am building the package from > source. How does the popup menu get activated? See the second patch. Putting some debug information around the code I changed would help know what's going on...
*** Bug 661245 has been marked as a duplicate of this bug. ***
I am settings this as FIXED, because: 1) Main problem (in report) is fixed long time ago. 2) Problem about popup menu appearing on primary display now is fixed in head.
Review of attachment 179797 [details] [review]: This patch did not fix problem. Settings status to reviewed so it does not show in unreviewed patches list.