On Fri, Feb 24, 2012 at 05:56:51PM -0500, Chris Siebenmann wrote:
> Here are two thoughts on relatively self-contained potential FVWM GSoC
> projects:
>
> * a module that is the inverse of FvwmCommand; call it FvwmQuery.
> Where FvwmCommand allows shell scripts to send commands to FVWM,
> FvwmQuery would allow them to get information from it.
But FvwmCommand can already do this.
> The FVWM module interface and the Perl library for it allows you to
> ask for a lot of useful information from FVWM, but this isn't readily
> accessible outside of writing an actual module. Since the current
It's not readily available without redesigning and thinking about how to
store the information "thrown away" from commands in a FVWM config file, is
the *actual* problem here. It has nothing to do with modules being
selective about what it stores from Send_ConfigInfo in terms of what's
available to be displayed -- the simple answer is the useful information is
parsed into a structure where it's not in a human-readable format.
> module interface is mostly low level, there would be some amount of
> defining useful high-level things to ask for and maybe documenting
> the module interface (if this is considered desirable).
The module interface is documented.
> (Writing such a module and trying it out might lead to also adding
> more information to the module interface, if an FvwmQuery module
> alone would be too small for a GSoC project.)
See above. Please be very careful here again, it has *nothing* to do with
the module interface at all -- we can send whatever we like from FVWM. It
might mean a few additional packets, but going on Send_ConfigInfo for now, I
wouldn't have thought so.
What would be needed as a prerequisite though is something I planned to do
but haven't yet, and have FVWM listen on a socket for $DISPLAY -- this then
means FvwmConsole, FvwmCommand and this mythical FvwmQuery module disappear
all in to one invocation of the same thing -- anything that can listen on a
socket.
> * A Ruby and/or Python library for the FVWM module interface to go
> with the existing Perl library[*]. As above, this might also involve
> documenting the module interface.
>
> (The elaborate version of this would autogenerate all of the necessary
> low level constants and so on for all languages from the C headers, so
> that adding these additional languages didn't increase the maintenance
> efforts.)
Why?
We could just turn the module interface into a .so essentially and expose
that to the FFI for other languages -- such as .xs from perl.
That is a valid project, and not that difficult to do.
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
