Mikhael Goikhman wrote: > ":0.1" and "unix:0.1" are different names for the same thing, so I see > nothing risky for X applications.
Right. The risk is to processes that are siblings of fvwm2 (other children of the session manager), who (a) are not X-based, (b) inherited $DISPLAY from the session manager, and (c) wish to talk to fvwm2 using FvwmCommand -f. When fvwm2 has a different notion of $DISPLAY than its siblings, FvwmCommand won't work if $DISPLAY is part of the FIFO's name. > If you want to use $DISPLAY as a part of > a file name you may handle this situation by stripping the leading "unix" > before using it in the file name. Understood. In fact, I went a step further - I've got a PipeRead script in my config that detects a leading "unix", strips it out, then resets (SetEnv) DISPLAY before running FvwmCommandS. > > I am running a two-headed display under Solaris 7's dtsession (not > > Xinerama). At login, twin instances of the default window manager are > > started. I bring up an xterm on the right screen (:0.1) and kill the > > right-side wm instance. In that same window, I start fvwm2 manually: > > > > % /<path>/fvwm2 -s -f /<path>/<config_file> > > Hmm, this is a bit strange way of starting fvwm. :) Yes it is, but it's only temporary while I'm experimenting with fvwm2. This setup allows me to do a side-by-side compare between fvwm2 and the other wm (which, BTW, is fvwm95). Eventually I'll be starting fvwm2 on both screens at login (using FAQ 2.2). > Especially if dtsession is a session manager. Is it? Yes (for CDE). > > I am able to recreate the problem with this minimalist <config_file>: > > > > ModulePath /<path>/modules:+ > > AddToFunc StartFunction > > + I Echo $[DISPLAY] > > + I FvwmTaskBar > > + I FvwmCommandS > > > > On startup, I always see in the xterm: > > > > [FVWM.1][Echo]: :0.1 > > > > I restart using fvwm2's built-in root menu on the right screen. Sometimes > > on the first restart, I see the "wrong" answer: > > > > [FVWM.1][Echo]: unix:0.1 > > > > Sometimes a few dozen restarts are required before I see it. With my > > "regular" (bigger) config file, only one or two restarts are required before > > the problem occurs. > > I can only try to explain what happens when you do "Restart" when inside a > session manager. This is different from what happens without a session > manager. FVWM asks a session manager to start-me-if-I-exit using a given > command line that has all original parameters plus -s -d. This logic is in > session.c. Then FVWM exits and dtsession "re-starts" it as requested. > > -d is constructed using XDisplayString(dpy), so the restarted instance > has -d parameter although the original one may not. This is needed for > your setup, so only the FVWM on the right screen is restarted although > the original command could be for all screens (i.e. no -s was specified). > > if you run long ps (ps -w -w -w or similar) which -d parameter do you see, > "unix:0.1" or ":0.1"? Running fvwm2 by hand as I am doing, a restarted fvwm2 shares the same PID and same argument list as when first started - no "-d" unless I started it that way. I'll make a note to check it again when fvwm2 is truly parented by dtsession. Thanks for your response. -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
