How to control desktop files

[Brian Cameron <brian cameron oracle com>]

Many OpenSolaris users use GNOME in a terminal server environment, and
we notice some serious usability problems with running GNOME in this
way.  I was wondering if someone might be able to suggest some
recommended ways to address these problems.

Many of the problems relate to Desktop files.  In a terminal server
environment you often do not want users to be able to run programs
that require elevated privileges, so System Tools (e.g. package
managers, etc.) should not show up in the menus.  Developer tools
may not make sense to display in some environments.  Also, users in a
terminal server environment may not have access to certain devices
which may make some programs not useful (e.g. a power management or
battery status tool).

Similarly, some programs that are autostarted may not make sense in a
terminal server environment, such as power management/package manager
related user daemons.  Since the GNOME autostart mechanism also uses
Desktop files, this seems a related problem.

One crude way to resolve this problem would be to simply not install
(or uninstall) packages that introduce desktop files.  However, this is
not an ideal solution for many reasons.  It is especially a problem for
Oracle because Oracle's terminal server product, Sun Ray, runs on many
Linux distros (Fedora, Debian, Ubuntu, openSuse, Gentoo), so it would
be ideal if there were a solution that just worked nicely across
distros.  A sysadmin should be able to specify what desktop files to
ignore without requiring distro specific setup (such as uninstalling
packages or hand-editing desktop files).  It would be best if any
needed changes could just be installed with the Sun Ray product and
things would "just work".

I know that the Desktop Specification supports TryExec which does offer
some control over whether desktop files should be ignored.  However, it
does not seem that this is powerful enough to provide the flexibility
needed.

Desktop files also support a Category field.  Is it possible to tell
GNOME to ignore desktop files that have a particular values like
"System" and "Settings".  For example, on user session startup, GDM
(and most display managers) sources any files in the
/etc/X11/xinit/xinitrc.d directory, so perhaps this could be solved
by setting up an environment variable before session startup with a
list of categories or desktop file names to ignore.  This would work
well since it would allow the sysadmin to control what desktop files to 
ignore via the /etc/X11/xinit/xinitrc.d interface and without needing
to modify any GNOME packages or files.  Another possible solution might
be to store the list of categories or desktop files to ignore in a GConf
setting that gnome-session or GNOME Shell checks, and which the sysadmin
could setup as mandatory system-wide settings.

This seems a generally useful feature in a variety of contexts, not
just terminal servers.  Many projects may want to provide software on a
variety of platforms and have the ability to control on which platforms
desktop files should be used or not.

Or is there already a way to implement this sort of feature that I
do not know about?  If not, would it be acceptable to enhance
gnome-session and GNOME Shell to support this sort of feature, perhaps
with the sort of solution suggested above?  Since this feature is of
particular interest to Oracle, resources can be provided to do any work
needed to make this functionality work well assuming we can come up with
an acceptable design.

A similar problem is with panel applets.  Some applets do not make sense
to display and run in a terminal server environment, such as the
battery status applet.  What is the proper behavior for applets in this
situation?  For example, should an applet be written to be smart enough
to recognize that it is not needed and exit itself?  If so, is there an
example of a GNOME applet which does this sort of thing?  Or is there
some interface to control what applets should not be run in certain
environments?  Or would interfaces need to be added to support this
ability?

Thanks,

Brian