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.
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
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).
(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.)
* 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.)
Alternately, maybe people feel that either or both of the ideas here
are undesirable for FVWM in general.
- cks
[*: I've picked Ruby and Python on the grounds that (along with Perl)
they seem to be the common high level Unix scripting languages at
the moment.]
