On Sat, Feb 25, 2012 at 08:47:12AM -0500, MK wrote:
> On Sat, 25 Feb 2012 11:16:58 +0000
> Thomas Adam <tho...@fvwm.org> wrote:
> > But until we decide to do it that way, it's a little moot, and it
> > would require some thought and design.
> >
> > Great for a project for GSoC I'd say, because thankfully I've plenty
> > of ideas on this. :P
>
> I like these ideas too, although I'll admit at this point I'm only
> dimly aware there is some potential perl interface, and have
> never investigated that or I've never looked at FwvmCommand.
Well, they exist.
> However, I started using the perl-C XS interface stuff last year for
> something, and one of the thoughts I had tooling around with that, and
> being a fvwm user appreciative of the style of the text file
> configuration, was writing a WM with a perl interface. Ie, the text
> configuration would be a perl script using some XS modules.
Having a lot of experience with XS myself, the point here is because the FFI
is in C, you've no choice really *but* to use XS, but that's a minor aspect
to this, as it is in any other language binding to this hyperthetical API
which libfvwmmodule [1] would provide.
> So, if there were to be a new fvwm lib intended in part for use in
> writing perl/python/whatever APIs with (I think this is a better idea
> than doing that directly), how feasible would it be to export
> initialization and configuration functions with that? This way, you
> could have perl/python/whatever scripts which launch and configure
> FWVM. :)
Well that's a side-issue entirely, when you have ModuleSynchronous to help
with this, but this has nothing to do with module APIs to expose the packets
FVWM sends to modules (we use the term "broadcast" for this) when events
happen. This is what we're referring to here, incidentally, with such an
interface.
> I'm presuming that the relationship between the proposed socket and
> the .so would be to blackbox the socket, as with X, so that users
> simply initialize with a C (or whatever) API call like XOpenDisplay()
> and go from there, and the .so takes care of actual communication
> via socket (or, possibly, initializing it at start-up). Do I have that
> right?
That the socket is initialised at startup time by FVWM is orthogonal to how
it is used. It's *just* a socket which FVWM is listening on at one end, and
clients are free to connect to it and send FVWM requests. This is somewhat
multiplexed by what happens at the moment, where FVWM sets up a pair of
listening pipes for read/write comms for each module it is told to load.
The point here though is that the listening socket probably *shouldn't* be a
domain socket. But yes, this API would have to wrap around the use of the
socket, just like the module API in FVWM currently handles listening on the
read/write pair of pipes.
So to take a specific example here, in the case of FvwmConsole, that
disappears entirely, because all it is is some form of FvwmCommand running
directly inside a terminal [2] -- where it will then just do socket
manipulations for us. Nothing complicated.
You would still need the Module command in FVWM to work as it does now --
that is, force FVWM to start modules, and die if, say, FvwmButtons was run
from outside of FVWM. Again, nothing in FvwmButtons needs to change, save
for the existing API it, and other modules, use to communicate/receive
information from FVWM. See libs/Module.c for more information.
But do not get ahead of yourself -- I've not fully decided the scope of
this, so we should discuss it some more.
-- Thomas Adam
[1] A good a name as any I suppose.
[2] Extra points for it being some kind of REPL as well. :P
--
"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.)
