I let it install into /usr/local (the default) where I already had
Fvwm2.
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.
I think.
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 FvwmMFL again.
In fvwm3, 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 FvwmTile for FvwmRearrange) such that FvwmCommandS points to FvwmMFL.
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 FvwmMFL.
I’ll do this in a moment so that it’s in the git version.