On Thu, Jul 31, 2003 at 10:05:47AM +0300, Mikhael Goikhman wrote: > On 30 Jul 2003 15:11:27 +0200, Olivier Chapuis wrote: > > > > 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)? > > 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>"
Yes why not, but I do not like to much to add (and write) an internal only cmd that can be easily simulated by a complex function (why we have complex function?). So, I think that first I will use a complex function in ConfigFvwmDefdault. I you want and there are no objection you may add a "RunWithSM" cmd. > 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. > Outch, I do not want to write the necessary parsing ... 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]
