[Some brief comments now, more considered ones later.]
| > 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.
So it can indeed (although it looks like the information from
'send_windowlist' omits information about the States that a window is
in). This shows me up for not reading the manpage carefully and will
be useful in the future.
(I have to apologise; I should have checked all of this stuff before
sending my email. Bad me.)
| > * 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.
[...]
|
| 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.
The simple answer is that a good Pythonic or Perl-oid or Ruby-oid
library will expose a different sort of interface than a C-level FFI.
Often it will want to extract information, reassemble it into native
objects and data structures, and then immediately release C-level
resources so that the language's native garbage collection can be used
instead of forcing callers to deal with lifetime issues and so on.
A C FFI as a .so is a starting point for such a module but not the
end result you want for fluent native programming.
(There are some old Python XML interface modules that are C-FFI style
and are infamous for leaking memory if you don't remember to do
everything right, by hand, in a rather non-Pythonic manner.)
- cks
