GNOME Bugzilla – Bug 309506
gnome-panel twice in session
Last modified: 2015-03-24 13:00:52 UTC
Version details: 2.10.2 and 2.11.4 Distribution/Version: paldo testing gnome-panel 2.10.2 and 2.11.4 insert themselves twice in the current session. Once with sm-config-prefix and restart style and once without arguments and normal style. This results in the error message that gnome-panel already sees an other instance running on all following logins. Trying to remove one or the other gnome-panel entry from the session results in no panel at all. Manually removing one entry from the session file helps, but only for one login as it automatically inserts the second entry again. This problem didn't occur in 2.10.1 and 2.11.3. I assume it's caused by the fix of https://bugzilla.redhat.com/160439
I can confirm it. both stable and devel g-panels are affected. Reverting Mark's changes: 2005-06-27 Mark McLoughlin <mark@skynet.ie> Fix for: https://bugzilla.redhat.com/160439 Basically, the WM was restoring the saved window position of the panel which we don't want it to do. * main.c: (main): call panel_session_init() before creating any toplevels. * panel-session.c: (panel_session_init): unset the SM_CLIENT_ID property. solves the problem for me
same issue described by https://bugzilla.ubuntu.com/show_bug.cgi?id=12404 (Ubuntu has 2.11.4)
*** Bug 309539 has been marked as a duplicate of this bug. ***
Setting priorities.
*** Bug 310390 has been marked as a duplicate of this bug. ***
*** Bug 310482 has been marked as a duplicate of this bug. ***
*** Bug 310675 has been marked as a duplicate of this bug. ***
Okay, seb128 hsa just confirmed that removing gnome-smproxy from the default session fixes this. So its something like: http://bugzilla.gnome.org/show_bug.cgi?id=118063#c25
Okay, writing down what's going on 'cause it feels like the 100th time I've had to figure it out: --- - Most applications that support session management support the XSMP[1] protocol. When they connect to the session manager they get a client ID from the SM and set SM_CLIENT_ID[2] with that value on their client leader window. - However, there is an obsolete X property based session management protocol which is defined in the ICCCM[3] commonly known as the WM_SAVE_YOURSELF protocol[4] where programs define properties like WM_COMMAND and WM_MACHINE in order for the window manager to save them when the session is saved. - So, what smproxy does is: 1) Locate toplevels windows by looking for the WM_STATE[5] property - the property is merely used as an indication that the window is a (window) managed toplevel window 2) It then locates the the client leader window by looking at the WM_CLIENT_LEADER property. If the property isn't set it just uses the toplevel itself as the client leader. 3) It then looks for the SM_CLIENT_ID property, and if that isn't set it assumes the app doesn't have XSMP support. 4) Next it looks for the WM_NAME, WM_COMMAND, WM_CLASS and WM_CLIENT_MACHINE properties. If those properties are set, it creates acts as an XSMP proxy for the app with the session manager. References: [1] - X Session Management Protocol specification (xc/doc/hardcopy/SM/xsmp.ps.gz) [2] - Section 5 of the ICCCM, Session Management and Additional Inter-Client Exchanges [3] - Inter-Client Communications Conventions specification (xc/doc/hardcopy/ICCCM/icccm.ps.pgz) [4] - Apendix C of the ICCCM, Obsolete Session Manager Conventions [5] - Section 4.1.3.1 of the ICCCM, WM_STATE Property --- The problem is that the panel now unsets the SM_CLIENT_ID property so that the window manager won't save its window state and smproxy then thinks it needs to act as an XSMP proxy for the panel.
Okay, there's a few approaches we could take: - Find some other method of telling the window manager to not save the panel's window geometry: - set SM_CLIENT_ID to some random value which changes every time we re-start - add a new property to the wm-spec which indicates that we don't want our geometry saved - Find some way to convince smproxy that we don't need it to proxy for us: - unset something like WM_COMMAND - add a _GNOME_SMPROXY_WOULD_YOU_EVER_FSCK_OFF_AND_LEAVE_ME_ALONE property to the panel's toplevel and add a patch to gnome-smproxy to make it not proxy if that property is set on the window. Hmm. Oh yeah, and we should get rid of gnome-smproxy in the next release too.
Havoc, Elijah: any insights to this panel/metacity/smproxy house of horrors?
Oh, this of course used to work fine in the panel. What we used to do is delete the WM_CLIENT_LEADER property, but in order to fix bug #303570 (you couldn't raise windows above panel dialogs) we made each panel be its own group leader and as part of that fix also removed the code to delete the WM_CLIENT_LEADER property. Of course, that meant that the window manager could discover get to the SM_CLIENT_ID property on the client leader and started saving the panel's window state so we unset the SM_CLIENT_ID property and now smproxy is fucking with us. So, perhaps we should just go back to deleting WM_CLIENT_LEADER again?
Okay, fixed now by removing gnome-smproxy. See: http://mail.gnome.org/archives/desktop-devel-list/2005-July/thread.html#00527
*** Bug 311878 has been marked as a duplicate of this bug. ***
Just wanted to say thanks for the hard work guys! I was working at this for a few hours before I stumbled across this board. Killing smproxy in the Desktop->Preferences->sessions menu, and then saving my session seems to be a usable work-around for those not on 2.14. Thought I was just retarded until I came across this... but btw I'm running gnome 2.10.1, and it still happened (some comments seem to lead otherwise) Sorry if this is viewed as an unecessary comment, but just wanted to put in a work around for the noobs like me.. (and say thanks)
*** Bug 314028 has been marked as a duplicate of this bug. ***