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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Apr 16 2002 - 15:00:21 BST