Hi, On Fri, Aug 26, 2011 at 07:09:35AM -0700, msib...@crosswire.com wrote: > Not a problem so much as a feature. If I can read/write to FVWMs > environment space, I can use it for token passing between scripts.
You can -- although be extremely careful here. If you're using variables for state which have to be modified/queried *externally* from FVWM, because you have some idea that it's useful for something, you're already doing it wrong from the outset, to be honest. FVWM is not a database. It is not designed to act like one, nor will it ever be extended in that way. Yes, setting state via SetEnv from within FVWM, and then running FVWM-specific things (in say PipeRead, to access that state) is acceptable, because often that's a means to an end to achieve something in terms of window-placement, or reacting to certain events, etc. But note that the communication is always only ever one-sided in this example. > Essentially it gives me a place to cache IPC data, so that programs > don't have to be running symultaneously in order to communicate with > eachother. To achieve what? Can you give me a more concrete example of where two programs need to communicate, and why FVWM would possibly ever be responisble for maintaining that state? > Obviously the ultimate evolution of something like this would be an FVWM > Module that embeds an instance of SQLite into the window manager. But > for the moment, I don't need that much state. Absolutely not. The "ultimate evolution" would be FvwmSocket. To make FvwmCommand disappear, and to then have communication via a Socket to extract information which FVWM has. Yes, you might then be able to abuse this for your own nefarious purposes, but you've still not told me what it is you're really trying to do. > There are many potential applications for this: Network sychronization > for example, or embedding localized algorithms for window placement. > IMHO it just makes FVWM easier to extend. This is typically done in the form of language-bindings, which FVWM already has one of. > As I said before: I'd rather not have to wrap FvwmCommand. So if there > is a programatic way of getting access to FVWM's environment variables > without spending a week doing it, I'm all ears. At the moment there isn't -- and all FvwmCommand is doing is relaying your commands via its own FIFO to FVWM. If you can give more information about what it is you're doing, again, I'll be able to be more specific. -- Thomas Adam
