Hello, Note first that this subject has been already discussed in the pass (Subject: session management problems, Date ~ 2001-03-15; fvwm running under a session manager):
> * There is an old known problem with swallowed windows, they multiply > on every start (started by e.g., FvwmButtons and the session manager. > The solution is not to use swallowing button bars, > or, maybe, to use session aware programs (xload and xclock are not) > and mark them "Restart never" if possible. > > Teoretically using Swallow(UseOld,NoClose) should help, but it does not > (probably because FvwmButtons starts before old xload/xclock). > It even produces walking windows before reswalowing on restart, > see other entries. They appear for 5 seconds and then are swallowed. > > I thought about a new Swallow(AllowOnlyOne) option especially for SM, > which kills all application instances except for one. No solution was found and this bug was "postponned". In fact there is a solution. From the XSMP spec: "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, the solution is to make FvwmButtons (and FvwmScript which may swallow some applications too) a "simple session manager". I've writing down in libs/ a "fsm" library which allows FvwmButtons to be a simple _dummy_ session manager. When a XSMP award application is started by FvwmButtons it contact FvwmButtons and not the top level session manager and so this application is not restarted by the session manager (we may even improve window swallowing by using sm, but this is for the future). Unfortunately, there is two problems (with solutions I hope). Any advice/comments is welcome. - As a session manager FvwmButtons should start applications with its own SESSION_MANGER env variable (network address). As it is fvwm which execute the swallow action a workaround should be found. What I do: FvwmButtons defines a function: DestroyFunc xxxFvwmButtonsExecuteSwallowActionXYZ AddToFunc xxxFvwmButtonsExecuteSwallowActionXYZ + I SetEnv SESSION_MANAGER FvwmButtons_SESSION_MANAGER + I $. + I SetEnv SESSION_MANAGER SESSION_MANAGER_orig where SESSION_MANAGER_orig is the value of "$SESSION_MANAGER" for fvwm (FvwmButtons has it because it is the value of "$SESSION_MANAGER" at FvwmButtons startup before its become a session manager). Then, a swallow button action is executed by sending to fvwm: xxxFvwmButtonsExecuteFunctionxxx action Can this cause problem? Should we have only one such function in the default fvwm config (for Buttons, Script and any module which can swallow window)? - smproxy and gnome-smproxy (a modified version of smproxy) break the XSMP protocol: they always contact the session manager which start it (most often the top level session manager). When a top level window is mapped the a proxies should compute the value of the SESSION_MANAGER ev on the application which maps the window and should either ignore this window if this value is not equal to the proxy SESSION_MANAGER ev (a one sm proxy only) or should contact the session manager identified by "$SESSION_MANAGER". smproxy and gnome-smproxy do not do that and this is *not* impossible to do. So with the current version of smproxy and gnome-smproxy applications which use the old session management protocol (e.g., xload but not xclock) are started by the session manager and FvwmButtons. One obvious solution is to do not run a sm proxy ... however I will try to convince XFree and GNOME developers to fix their sm proxies (yes I know I am optimist ...): A session manager (master or not) can set on a leader window (which use the old session manager protocol) a property SESSION_MANAGER(STRING) 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 session manager or to ignore this window if it works for only one sm (e.g., the master 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 its 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 belong 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?] I've already patched smproxy (and it will be easy to patch gnome-session) and FvwmButtons and this solve the problem. Regards, Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
