On 11 Apr 2002 18:42:06 -0600, Dameron, Gregg wrote:
>
> > > Perhaps a better question is this: Is it reasonable for a window
> > > manager to set DISPLAY if it subverts the value it inherits from the
> > > session manager?
> >
> > Probably yes. There are several cases, $DISPLAY is initially set or not,
> > -d is given or not. I think it is ok to set $DISPLAY to what X says after
> > all given input (if any) is processed.
>
> I'm not so sure. If the session manager parents fvwm2 with a legitimate
> $DISPLAY value already set (like :0.1), ignoring it and setting $DISPLAY
> anyway seems risky, especially since Xlib _may_ tell fvwm2 that display is
> "unix:0.1".
":0.1" and "unix:0.1" are different names for the same thing, so I see
nothing risky for X applications. 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.
> It seems to me _any_ window manager should attempt to use the
> display handed to it if possible (either inherited through $DISPLAY or
> hardwired via command line option), to keep the wm in sync with the session
> manager's other children.
I don't know why X returns different strings in your situation, sorry.
It may be a problem in our implementation of SM, but I don't see it.
> > Just for a curious, what is your setup?
> >
> > Real session manager and multi-screen display?
> >
> > How do you restart, using which command on which screen?
>
> 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. :)
Especially if dtsession is a session manager. Is it?
You may just use "save session" capability in dtsession and twin will not
be started on the next dtsession startup, instead FVWM will be started.
At least this is possible in xsm and gnome-session, I didn't use dtsession.
There may be problems because your setup is not trivial.
I don't know whether twin is session manager aware, i.e. supports XSMP.
> 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"?
In any case, you may just strip the leading "unix" in file names to solve
your problem.
Regards,
Mikhael.
--
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 Sun Apr 14 2002 - 16:10:48 BST