Thomas Adam <tho...@fvwm.org> writes: > On 25 July 2012 18:38, Thomas Funk <t.f...@web.de> wrote: >>> Dan Espen wrote: >>> Thomas Adam made some comments about using FvwmPerl. Is that resolved? > > No -- and as such, until it starts to use perllib and/or FvwmPerl, > it's not ready. There is *no* reason why we wouldn't dog-food our own > implementation of interfacing to FVWM, other than the individual > developer concerned didn't understand it. We _have_ a framework to do > all of the functionality the code currently uses; it's high-time we > use it. > >> I've fixed all what Thomas suggested except the part to do the complete >> stuff with the perllib framework. That needs a little bit more time. > > But that's the entirety of this file, as far as I am concerned. A > pretty important part, too. > >> I hope it is ok for Thomas that you want to commit it because it's only >> an interim solution. > > Until this is fixed, I would rather this wasn't put in CVS at all. As > I've mentioned my time is limited, but if I have to roll up my sleeves > and take responsibility for this, I don't mind. I'd rather not > though, but either way, someone should let me know if I have to.
Okay having read the FvwmPerl man page I see that "TF" has followed the usage pattern in the tests/perl/xmessage.fpl example. It looks like the only interaction this module needs with Fvwm is to send the completed FvwmForm to Fvwm for execution. The module does this using the FvwmPerl "::command" interface. What's wrong with that? It looks like it could have been written as a script in /bin and been invoked with Piperead to get the same effect. -- Dan Espen
