Binary name in the desktop file

[Dominique Michel]

Le Fri, 27 Dec 2013 14:28:52 +0800,
Ma Xiaojun <damage3025 at gmail.com> a écrit :

> 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.)

The terminal cannot make a good coffee or tee.
But sure, you are right. It is why I like fvwm, it is not only a wm,
but also a tool-kit for the xlib, and the only useless eye candy it
will do is the ones you tell it to do.

> 
> 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.

In the real world, that's not that simple. The real winner is the one
that have the best management. Back in the eighties, the Amiga OS was
the best PC with an incredible OS for that time, but Commodore got in
bankrupt because its management was as bad its computers was good.

With GNU/Linux, we have the choice, and the 2 most used desktop,
Gnome and KDE, are the ones that have the best management. At the same
time, they are not even able to provide some kind of good focus policy.
If I am using the mouse, to be forced to search for a small button to
bring a window at the front or at the back layer is not what I call a
good focus policy, but a waste of buttons and time.

It is also another issue on GNU/Linux, it's the speed of the GUI. If I
install some linux hosted ICAROS/AROS distribution on my gentoo, a
software like the Gimp start around 5 times faster in its hosted x86
Aros version than the native Linux amd64 version optimized for my
machine. After it is started, the speed to apply a filter on a picture
is the same in both versions, because the calculation and the
processor are the same. That show tool-kits like GTK or QT are not
effective at all with the speed of their GUI.

Dominique
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg