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 632369 - Panel applets not displaying in second x session
Panel applets not displaying in second x session
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.32.x
Other Linux
: Normal major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 649984 661245 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-10-17 16:22 UTC by s_stoakley
Modified: 2013-11-22 11:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
panel: Fix dbus applets to work in multiscreen environment (7.34 KB, patch)
2011-02-01 12:58 UTC, Vincent Untz
committed Details | Review
libpanel-applet: Use right GdkScreen for focus request and menu (1.42 KB, patch)
2011-02-01 14:56 UTC, Vincent Untz
reviewed Details | Review

Description s_stoakley 2010-10-17 16:22:15 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
Comment 1 ajs 2010-11-22 16:46:37 UTC
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
Comment 2 quadmon 2010-11-24 02:17:51 UTC
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.
Comment 3 quadmon 2010-11-26 01:23:53 UTC
A temporary workaround is to use alt-tab in the second x session, but this is still ugly.
Comment 4 mumblerit 2010-11-26 19:51:19 UTC
Same problem.
Comment 5 s_stoakley 2010-11-28 06:03:14 UTC
(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?!
Comment 6 Andy Campbell 2010-12-04 18:58:48 UTC
( 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.
Comment 7 Evan Hisey 2011-01-30 15:18:15 UTC
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.
Comment 8 Pacho Ramos 2011-01-30 18:11:04 UTC
There are instructions for trying to find in commit causing this in http://bugs.gentoo.org/show_bug.cgi?id=348253#c19
Comment 9 Andy Campbell 2011-02-01 07:15:04 UTC
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)
Comment 10 Vincent Untz 2011-02-01 12:24:29 UTC
(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.
Comment 11 Vincent Untz 2011-02-01 12:41:43 UTC
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.
Comment 12 Vincent Untz 2011-02-01 12:58:16 UTC
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.
Comment 13 Evan Hisey 2011-02-01 14:18:50 UTC
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.
Comment 14 Evan Hisey 2011-02-01 14:23:12 UTC
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.
Comment 15 Vincent Untz 2011-02-01 14:56:42 UTC
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.
Comment 16 Vladimir Kokarev 2011-02-01 18:28:30 UTC
(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.
Comment 17 Andy Campbell 2011-02-01 20:54:10 UTC
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.
Comment 18 Evan Hisey 2011-02-04 05:00:06 UTC
Applied second patch no change in behavior.
Comment 19 Evan Hisey 2011-02-05 05:49:15 UTC
Applied second patch no change in behavior.
Comment 20 Evan Hisey 2011-02-07 03:35:09 UTC
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 21 Vincent Untz 2011-02-17 12:01:05 UTC
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.
Comment 22 dwsbugzilla 2011-03-10 15:04:18 UTC
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.
Comment 23 mumblerit 2011-03-11 23:27:46 UTC
(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
Comment 24 Pacho Ramos 2011-03-12 11:02:51 UTC
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
Comment 25 Vincent Untz 2011-03-15 07:32:40 UTC
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.
Comment 26 John Dvoracek 2011-03-22 21:46:27 UTC
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...
Comment 27 Evan Hisey 2011-03-22 22:01:08 UTC
(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.
Comment 28 Evan Hisey 2011-03-22 22:02:54 UTC
(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.
Comment 29 John Dvoracek 2011-03-23 17:00:52 UTC
> 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.
Comment 30 Joseph Coffland 2011-05-02 18:29:58 UTC
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.
Comment 31 Joseph Coffland 2011-05-03 18:30:32 UTC
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.
Comment 32 Joseph Coffland 2011-05-03 18:31:56 UTC
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.
Comment 33 Joseph Coffland 2011-05-03 18:38:36 UTC
@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.
Comment 34 Vincent Untz 2011-05-23 21:55:57 UTC
*** Bug 649984 has been marked as a duplicate of this bug. ***
Comment 35 Vincent Untz 2011-05-23 21:57:23 UTC
(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...
Comment 36 Vincent Untz 2011-10-10 11:13:13 UTC
*** Bug 661245 has been marked as a duplicate of this bug. ***
Comment 37 Alberts Muktupāvels 2013-11-22 11:34:00 UTC
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.
Comment 38 Alberts Muktupāvels 2013-11-22 11:36:30 UTC
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.