GNOME Bugzilla – Bug 147691
Applet gets listed in the session file if the preferences dialog is open while saving session
Last modified: 2005-07-28 13:05:03 UTC
1. When the applet is added to panel, the applet is not listed in session properties. The session file also doesnot contain an entry for the applet after saving the session. 2. But as soon as the preferences dialog of the applet is opened, the applet gets listed in session properties and session file. Attached is the session file when the preferences dialog of the clock applet is opened. The side effect of this is that the splash screen gets stuck while logging in and a button press needs to be done to get rid of it. The same behaviour is seen for other applets too. Apparently I'm not aware at this point which base library could be causing this. Hence I've filed the bug against the applet I first noticed the problem with.
Created attachment 29572 [details] Session file
This may be the root cause of many of the gnome-session problem. Since the purge_delay has changed to 120 seconds by http://bugzilla.gnome.org/show_bug.cgi?id=94754 When user saved the session after one of the preference dialog has been opened, the bug will manifest itself. This seems to be design/architectural issues here. That is, the preference dialog belongs to the applet, but the applet is created using glade-2 as a TopLevel GtkDialog. There is no api in the Gtk to set the dialog to be non-session aware. So gnome-session simply register the preference dialog to belong to the applet e.g. /usr/libexec/clock-applet. So when gnome-session tries to restore the saved session, it tries to reload the applet, but that applet is obviously not going to response to the session even though the Preference dialog did. The reason why the applets do not response to session because they are turned off during the creation stage. One possible solution is to create these preference dialog by making them indepedent program that the applet spawns, but that it is really too much an overhead. Another possible hack is to black list these applets in gnome-session which is not to register any of these applets when gnome-session sees them, but that is a BAD, BAD hack. May be someone else has better knowledge of gtk+ can help here.
The hacking in gnome-session would not work because all the prefrence dialog created by other applets also caused the same problem. It is noway that this can be done. A more generic solution is required.
Its an smproxy issue - because we don't register with the session manager, we don't have a SM_CLIENT_ID property on the window and so smproxy thinks it needs to handle us. Something like that, don't have time atm to go back and figure out how all this works again. Section 5 of the ICCCM has details of SM_CLIENT_ID and Appendix C, Section 3 of the ICCCM has details on the WM_SAVE_YOURSELF protocol. That and the XSMP, SMlib, ICE and ICElib specs have all the details needed to figure it all out. We'll probably wind up doing something like gdk_set_sm_client_id ("go-away-smproxy"); as an ugly workaround hack, but we need to be sure that this won't cause any weird side effects (like the window manager getting confused). This is an issue for anything that calls sets GNOME_CLIENT_PARAM_SM_CONNECT to FALSE and then maps a window, I think. gnome-settings-daemon is another example. Moving to libgnomeui, 'cause the likely location for the hack will be in gnome-client.c
Thanks Mark! Adding Arvind onto the cc: list as he might be interested in this bug :) I think I will spend a little time try to under smproxy. The best thing to do now for Sun's release is to reduce the purge_timeout to 30/40 seconds instaed of 120 seconds as was done by http://bugzilla.gnome.org/show_bug.cgi?id=94754 At least making the user experience a bit more pleasant. I think the hardware speed between 2002 and now has improved some significantly, Darren's original problem would be generally a lesser problem.
I'm wondering if bug #133345 might be related to this...
*** Bug 133345 has been marked as a duplicate of this bug. ***
This is fixed now that we don't have gnome-smproxy