Hello, So I've recently been doing a bunch of FVWM things off-list with a few people who've asked for my help, and in doing so I've finally scratched an itch which I've long-since been bemoaning but not really suggested a better alternative for, until now...
I don't like SetEnv -- or rather, I do like it, but don't like how it's abused by almost all users of FVWM. Currently, SetEnv's use-case seems to be a generic store of pieces of information, rather than setting information in the environment for other processes to make use of. Indeed, whilst it's a perfectly UNIX-y thing to do for environment variables to be used to propagate information between processes, I can't say I've ever liked this, and certainly don't like it in FVWM's case, where people really do use it to persist information during the lifetime of FVWM. But people are forever asking me *why*, and it's because shoving information in the environment is global to processes created from FVWM within the same process group. Hence, that information is both publicly viewable and potentially modifiable, which in some cases might be what's wanted, but more than likely it isn't, and in that case, what you're after then is some other means which can do the same thing as SetEnv, but which is internal to FVWM, but still accessible from things like functions [1]. This is why I wrote the InfoStore command. See: https://github.com/ThomasAdam/fvwm/tree/ta/metainfo I've not added anything to the docs yet, I've yet to psych myself up enough to attempt that without injuring myself. But needless to say it's a very simple linked-list implementation with two single entries -- a key, and its value. Here's some examples: InfoStore key1 value1 InfoStore key2 value2 To get the value for a given key, you must go through the FVWM expand mechanism, as in: Echo $[infostore.key1] To delete a given entry, you currently have to do this: InfoStore -d key2 Although I suspect I'll change this syntax to be a separate command, perhaps even changing InfoStore itself to be "InfoStoreAdd" and its equivalent "InfoStoreDelete", or something. The downside to "-d" is that it now cannot be used as a legitimate key, unless I check for its repeat, but that gets ugly, and also it's nothing like any other FVWM command we currently have. So it's actually very simple to use, and doesn't pollute the surrounding environment, but still allows people to store all the little things they like, such as mplayer commands (the mind boggles, it really does.) Note that this all originally came up when I was asked if there was a way of tracking information per-page/desk. There isn't a way that doesn't involve grouping which implies some sort of window-context. And my original implementation of this did do just that; but now I'll let anyone using the InfoStore to decide what the key should be to represent that value. And no -- there won't be multiple entries per key. Ever. Note that it doesn't do any clever alphabetical insertion based on key, or any ordering. This means that insertion time is O(1), but search time for a given key is at best O(n). This should be sufficient for most people, but obviously the retrieval time will increase with the more entries which exist. This trade-off should be OK, but should someone find a case where it isn't, I would restructure the insertion to then allow for a bsearch() to happen for retrieval. This is as close to a database as FVWM will ever have. This won't have anymore work done to it, nor will I ever expand it to be more than it currently is. It does the job of all of the above points I've made, and allows for finally stopping the abuse of SetEnv and the polluting of the environment. The only downside to it now is watching how many people use this *as* a database, but if you do that, you get what you deserve. I'll let this float around for a few weeks, and expect me to sort out the name of the command as the whole "-d" issue beforehand. I'll be merging this in to FVWM in the New Year sometime. -- Thomas Adam [1] And no, that such things are technically still possible to change via FvwmCommand, should that be installed, is still a lot less fool-proof to change than an environment variable, as that's a conscious act -- and there's nothing to say a process might not overwrite its local copy of something already set with SetEnv, for the duration of that process. -- "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.)
