I was thinking about a framework where you could start a module up at
init time, have it hang around long lived, and have fvwm send it
command strings based on user configuration. I'm sort of new to the
modules interface, but my take on it is that if you have a long lived
module, it will only ever get the initial arguments used when starting
the module. From then on, there's no way a users configuration could
instruct fvwm to talk directly to the module -- it would only get the
events outlined in the module API document.
That's fine. What I would do is add a new command to fvwm, that would
have the following interface:
SendToModule <module> <string>
This would generate a new packet type and send it only to the module
in question. Hmm, maybe there'd be a similar BroadcastToModules
command? The packet would contain header, 'the usual window ids',
then the variable length string.
What I'm thinking about is a long lived Python helper module which
would react to these commands, updating its state, sending new
commands back to fvwm, importing Python modules as needed, etc. I'm
not quite sure what I'd do with it, but I have a few modules now that
I use, and for one thing, I'd like to not have to fire up a Python
interpreter each time. I could easily accomplish this with this type
of framework.
Any thoughts?
-Barry
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Wed May 01 1996 - 11:03:08 BST