Multiple DeskTops, HiColor theme, standardized icon names, & menu icons

[James Richard Tyrer]

Rodney Dawes wrote:
> GNOME is not the only thing that doesn't have automagical lookup of 
> app-specific icons in a private directory that mimics the layout of
> icon themes. GNOME simply implements the Icon Theme Specification,
> which clearly does not state any way to do this. KDE implements
> things which are above and beyond the specification, as well as
> things which make the transition to standardized names, so that we
> can actually share themes across the desktops, quite difficult.

Yes, KDE's icon names are a mess.  But, I don't know of anything that
can't be fixed by renaming them all.

> Any other piece of software which implements the specification, and
> doesn't add additional hackery to make it do special things, as KDE
> does, is going to have the same problems. So, with that, can we
> please try to avoid simply limiting the details to those that GNOME
> and KDE conflict on? This is supposed to be about the independence of
> desktop implementations, not simply the peaceful co-existence of the
> two major ones.

Yes, I should include Xfce, WINE, and third party apps using tool-kits 
that are not tied to DeskTops in the discussion.  The assumption is 
usually that if GNOME and KDE agree on a standard that others will go along.

> That said, $datadir/apps is not part of the FHS, and seems redundant
> to me, as well as adding implied conflict with $datadir/applications,
> which is part of an XDG spec already, as "apps" is mearly the short
> version of "applications." In fact, according to the FHS, it looks
> like the app's static arch-indep files should be in
> $datadir/<app_name>, unless there is a more specific sub-directory
> where data should be placed, such as in $datadir/games/<app_name>.
> The redundancy of the apps directory, and implied conflict with
> applications directory, along with the fact that the FHS doesn't
> specify app-specific data being in apps/<app_name> are my main
> concerns with your proposal. But, I have no issue with a similar 
> solution which doesn't conflict with other specifications, being 
> included in the Icon Theme Specification, along with very clear text 
> about how applications should install these icons.

I don't know why KDE chose: "apps" for the subdirectory when: "kde" 
would have been a better choice.

Third party apps appear to install their application information in 
$PREFIX/share/<app_name>.  My only problem with this is that there is a 
lot of stuff in the "share" subdirectory and my "share/apps" directory 
has 398 subdirectories.

So, some subdirectories would appear to be a good idea.  GNOME-2 already 
installs a directory: "gnome-2.0" (wouldn't just: "gnome-2" have been 
better?) which GNOME-2 based apps could use.

OTOH, "share/applications" never seemed like a good choice to me since 
it is really the menu rather than application stuff.

-- 
JRT