To me the issue is a very very simple. How to alter the environment before executing a GUI program. The requirement is do it in per-user, per-app basis.
Currently there are two working solutions: 1. Use env FOO=bar /path/to/real/program 2. Use /path/to/wrapper.sh ( The script contains export FOO=bar or whatever) Both approaches obfuscate the real program/binary and someone think this is a problem. To me, the sole ugliness of the two methods is already a problem. Using env hack or wrapper script doesn't seem to fit the philosophy behind ini-like syntax of .desktop files. Let's also check what MS Windows does. http://msdn.microsoft.com/en-us/library/windows/desktop/bb774950.aspx IIUC, the only changeable environment is working directory. This is arguably a good design, as a *real* GUI program shouldn’t use environment variables, right? I don't know whether it is possible to change working directory using .desktop. What I do know is that changing environment is still useful on GUI programs for Linux. My example is changing UI language on a per app base, this can be done by changing LANGUAGE or LC_* currently. ( If some asshole is going to argue the usefulness of changing UI language, I'd remind you that desktop is a completely useless eye candy while terminal can do everything imaginable.) It is easy to argue that it is some esoteric programs like wine not behaving correctly rather .desktop is not flexible enough. But the reality is that every major program, no matter open source or proprietary has zillions of bugs and these bugs just won't disappear. Keep in mind that the real winner in desktop arena so far is the most forgiving one. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
