Hello, Both smproxy and gnome-smproxy has a bug. I will describe this bug and propose solutions.
First I recall one paragraph of the X session manager protocol (XSMP) specification: "Some clients may wish to manage the programs they start. For example, a mail program could start a text editor for editing the text of a mail message. A client that does this is a session manager itself; it should supply the clients it starts with the appropriate connection information (i.e., the SESSION_MANAGER environment variable) that specifies a connection to itself instead of to the top level session manager." [end of section 3] So a "simple client" can be a session manager (sm for short) for a set of clients it starts itself. As the SESSION_MANAGER env variable is set to point on the "simple client", the top level sm does not manage the clients which are XSMP compliant (because they connect to the simple sm). Now if one of these clients uses the old session manager protocol (based on the WM_COMMAND, WM_SAVE_YOUR_SELF, ...etc properties, see the appendix C of the ICCCM2) and if either smproxy or gnome-smproxy run, then the top level sm will manage this client. More exactly want can happen is a competition between the simple and the top level sm (via sm proxies, if the simple sm has a proxy) for managing the client. That's the bug. The reason is clear. When a top level window is mapped the sm proxies should compute the value of the SESSION_MANAGER ev on the application which maps the window and should ignore this window if this value is not equal to the proxy SESSION_MANAGER ev (or should connect the correct sm). Both smproxy and gnome-smproxy do not do that ... a good reason is that it is _not_ possible to do that (in general). I see two solutions: 1. Remove smproxy from XFree and gnome-smproxy from GNOME with the hope that all alive applications which use the old sm protocol will switch to the new one. Probably a bad solution ...? By the way it seems that KDE does not have and do not run by default a sm proxy. 2. Add a simple protocol between sm proxies and sm by using a property SESSION_MANAGER(STRING) which can be set by a sm (top level or not) on a leader window: A session manager can set on a leader window (which use the old session manager protocol) a property SESSION_MANAGER(STRING) set to the value of its network address (i.e., the value of "its" SESSION_MANAGER environment variable). A sm proxy should use this property to contact the correct sm or to ignore this window if it works for only one sm (e.g., the top level one) and the value of this property is not the network address of its session manager. The proxy should monitor the SESSION_MANAGER property and update the sm connection(s) accordingly (typically a window will map without the SESSION_MANAGER property set, if SM_CLIENT_ID is not set a concerned sm can then set the SESSION_MANAGER property). [We can do a more safe stuff: add a SESSION_MANGER_CHECK_WINDOW(Window) property that should be also set by the sm on the top level window and gives the id of a window which belongs to the sm and have the property SESSION_MANGER_CHECK(STRING) set to the value of the SESSION_MANAGER property. This can be used by a sm to answer the question: does an other alive sm already set the SESSION_MANAGER property?] It will be simple to modify smproxy and gnome-smproxy to avoid the bug by using this protocol (just monitor the SESSION_MANAGER property and if it is not equal to the value of the SESSION_MANAGER ev variable of the proxy, ignore the window). I can provide a patch for smproxy (which will be easy to apply to gnome-smproxy). In the future, if needed, one can imagine a sm proxy which works for all the running (master and simple) sm. I am not an XFree developer neither a GNOME developer. If the maintainers of smproxy and gnome-smproxy can be agree on a method to solve the described bug (as the solution proposed or any others), then the first step will be to modify smproxy and gnome-smproxy (I am ready to provide patches). The second step is to document the solution (Of course the sources code can be considered as a good documentation). I suggest that this should not be discussed now as this is useless if both smproxy and gnome-smproxy maintainers do not want to fix the described bug. Regards, Olivier _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel