Subject: Session management and Swallowed apps

From: Olivier Chapuis <[email-masked]>
Date: Wed, 30 Jul 2003 15:11:27 +0200

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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 31 Jul 2003 10:05:47 +0300

> the default fvwm config (for Buttons, Script and any module which

I don't think the global function is the way to go. We have commands for
this. So you mat add a command "RunWithSM <sm-value> <fvwm-command>" or
a more generic:

  RunEnv [var=value ...] <fvwm-command>

that works like /usr/bin/env; sets variables, runs the supplied command
as is (without expansion) and restores modified variables.

Regards,
Mikhael.