Re: Updated menu proposal (v1.1)
- From: "Guillermo S. Romero / Familia Romero" <famrom infernal-iceberg com>
- To: usability gnome org
- Subject: Re: Updated menu proposal (v1.1)
- Date: Wed, 6 Jun 2001 18:31:17 +0200
jirka 5z com (2001-06-05 at 1741.20 -0700):
> The reason for an envarimental variable: Some people have expressed concerns
> that env vars are hard to change in a consistent manner, however this env var
> is not intended to be changed by the users themselves (unless a user installs
> applications in his/her own prefix, in which case he/she has to already modify
> PATH, so it would make sense to modify DESKTOP_FILE_PATH at the same
> instance). The env var is to be set up by the system integrator, that is the
> operating system vendor, according to their layout on disk. There needs not
> be any GUI or a standard way to modify this path and it can be setup in the
> same way as other global env vars are set up on this system.
I forgot the other day: what is the purpose of the Config Tools?
Provide a common interface, without caring of the lower layer. Those
that are against the env var have to find another excuse, and a good
way to set the config via PAM (yeah, I know, home users do not care
about it either, but when you admin machines, you want to be able to
do things like not showing something if you are in untrusted machines
so the user sees this is not a admin machine, ie).
> This way third party developers can easily install their .desktops in a
> standard location and not have to worry about this or that desktop finding
> their application.
And at the same time admins can do nice tricks with .desktops (like if
user is root or similar, it has /sbin/ as PATH by default). Or tricks
based in login machine or time of login, or based in what NFS mounts
do you have avaliable (if machine foo is not up, use machine bar, but
do not use both).
If they keep on wanting a file, I hope they find a way to allow that
kind of flexibility.
] [Thread Prev