Lack of FvwmCommand can break existing configuration

[domichel]

FvwmPrompt replace FvwmCommand. Please provide a FvwmCommand wrapper script to keep the compatibility.

[ThomasAdam]

Hi @domichel

Indeed. I think it's easier to start a fvwm-convert-3.0 script which builds on fvwm-convert-2.6.

I will close this for now, until that script appears. I might look at it later on.

[NsCDE]

Hi

I will like to propose solution here, based on my views.

FvwmMFL basically replaced FvwmCommandS and it is building more functionality than old message command system has. This is good.

I think Dominique has right here. FvwmCommand was compiled binary in FVWM2. Removing it without providing a wrapper can be annoying for users while migrating. By it's nature, FvwmCommand is/was often not called within FVWM_USERDIR, this can be called from scripts run by user in ~/bin, from cron, various launcers ... many possibilities here.

I personally, don't have this problem. I have made nscde_fvwmclnt which talks with FvwmMFL and made it retroactive wrapper for FvwmCommand if FVWM2 is detected, so one unified interface is used to send commands to FVWM, regardless of major version. Dominique can build on this too possibly, but I see problems for users who are not using hybrid DEs like NsCE or Crystal, who has scripts which expects that something with name "FvwmCommand" exists. Some wrapper in Python or Perl if Go is not supported (and often it is still problematic) would be nice to make life easier to existing user base.

My two cents just .... :-)

[ThomasAdam]

Hi,

So why don't I include nscde_fvwmclnt in Fvwm3 as FvwmCommand? Eventually, this will just be a symlink to FvwmPrompt when I'm able to do that.

@NsCDE -- feel free to submit a PR to achieve this if you have the time. I would put this wrapper in bin/FvwmPrompt and allow it to install to the same place as FvwmPrompt does. We will need a mention of this in FvwmPrompt's man page entry as well.

[NsCDE]

Ok. I will look at it later and clean it from NsCDE-isms for general use.

[ThomasAdam]

I had originally suggested using;

#!/bin/sh

echo "$@" | nc -q1 -U "$FVWMMFL_SOCKET"

... but this relies on the version of nc being BSD-compatible which not every Linux distro will use.

Happy for this to be in python3 instead (inline with the version of python we check for in fvwm3 already) if that's more portable.

[NsCDE]

Yes, entity "nc" can accept different options depending of it's origin and version.

BTW, how do you prefer FvwmMFL client based on nscde_fvwmclnt delivered? As FvwmCommand or as some other name and then symlinked to FvwmCommand?

[ThomasAdam]

Hi @NsCDE

You can call the client FvwmCommand, that's fine.