I recently installed Fvwm3 for the first time.
I let it install into /usr/local (the default) where I already had
First thing I noticed is that it replaced the FvwmCommand binary.
So, while under Fvwm3 I tried to use FvwmCommand.
I get the message:
Cannot find FvwmMFL socket None.
Please start FvwmMFL module from your fvwm configuration.
So, I put this in my .fvwm2rc:
AddToFunc StartFunction I Module FvwmMFL
and took out:
AddToFunc StartFunction I Module FvwmCommandS
restarted fvwm3 and got the same message.
So, then I looked at the FvwmMFL man page, no help.
Then I looked for the FvwmCommand man page, it’s missing.
What I would like to see are instructions on how to make FvwmCommand
work and ideally instructions on how to set up my Fvwm config file
to have FvwmCommand work with either fvwm2 or fvwm3.
Also I’d like some guidance on the best way to have a setup that works
with both Fvwm versions. It looks like I need to put one of the Fvwm
versions somewhere other than /usr/local since there are conflicts.
It looks like FvwmMFL does a lot more than FvwmCommandS does, but
if FvwmMFL was named FvwmCommandS, the transition would be transparent.
Yes – having fvwm2 and fvwm3 side-by-side can be a problem if the prefix (in your case
/usr/local) is the same. Downstream packagers have various means of working around this. I don’t have the best suggestion right now for how best to fix this. Ultimately it comes down to how I decide to version things for the future so that things don’t clash so much.
Your instructions about
AddToFunc StartFunction I Module FvwmMFL seem correct. I wonder why it’s not running? If you leave that line in your config, and run:
pgrep -l FvwmMFL do you see anything out of the process table? If not, then there’s a more fundamental problem – presumably it’s either not loading because
FvwmMFL is not in
ModulePath or crashed. You could check
~/.xsession-errors and/or enable fvwm3’s internal logging (
pkill -USR2 fvwm3) and check
~/.fvwm/fvwm3-output.log having tried to start
FvwmCommand is just a wrapper around communicating with
FvwmMFL. It is similar to what
FvwmCommandS once did – although now provides a generic interface for modules instead. You do raise an interesting point though – I could maintain a backwards compatible symlink (as we do for
FvwmRearrange) such that
FvwmCommandS points to
This would allow you to keep the same config-file around for both versions without too many changes.
That being said, when running under
fvwm3, there will always be the
FVWM_IS_FVWM3 environment variable injected by
fvwm3, hence you can do:
Test (EnvIsSet FVWM_IS_FVWM3) RunThis
But in the case of what you’re wanting to do, if I provided a compat symlink to make
FvwmCommandS point to
FvwmMFL then you wouldn’t need to make any modifications to your config at all – in either case, under
fvwm2, the module path would load up the old version, and in
fvwm3 it would use
I’ll do this in a moment so that it’s in the git version.
Hope that’s useful.
Please see: https://github.com/fvwmorg/fvwm3/pull/392
As for the missing man page, I’ll write one later.
I installed the latest version of Fvwm3. Now FvwmCommand works.
I managed to deal with the path to the separate version of Fvwn3 like this:
AddToFunc ItsFvwm3 I SetEnv PATH /home/dane/fvwm3/bin:$[PATH]
AddToFunc ItsFvwm3 I SetEnv MANPATH /home/dane/fvwm3/man:$[MANPATH]
Test (EnvIsSet FVWM_IS_FVWM3) ItsFvwm3
So now I can switch back and forth reasonably well. Thanks.