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

[Rodney Dawes]

On Mon, 2006-06-26 at 08:41 -0700, James Richard Tyrer wrote:
> Yes, KDE's icon names are a mess.  But, I don't know of anything that
> can't be fixed by renaming them all.

The names aren't really the problem. Names are easily solved with
symlinks and trivial patches to apps. The main issue is that KDE's
implementation hardcodes a list of acceptable Contexts.

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

We should all include them in thoughts about standards we wish to create
and have them use. Simply assuming that the solution that works well for
GNOME and KDE both, will also work for other toolkits/platforms, just
won't do. A lot of the statements you've made in this thread are of the
"Well, that's GNOME's problem, not KDE's" variety. It's everyone's
problem. We need specifications that not only GNOME and KDE use, but
that will get hackers at Microsoft, Apple, or on other projects at other
companies, to look at the specs and say to themselves, and their
managers, "Hey. Maybe we should look at implementing this in our code."

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

What does it matter if we move everything KDE currently puts into
share/apps into just share? How is moving everything from just share/
into share/apps any different than that? The latter just means you have
an extra level of hierarchy to deal with. I'd rather avoid a new
sub-directory that we're going to add all these sub-directories to,
unless we are going to get the directory added to the FHS, and have
specs for various sub-directories inside the app_name sub-directories,
and not only icons.

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

But what about things that aren't GNOME or KDE based and want to use
specs? Having multiple sub-directories to which you add more
sub-directories, based on what underlying libraries your application is
linked to, only compounds the amount of confusion in the spec. 

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

It is the application registry. Data specifying where applications show
up in the menus, and what MIME types they can handle, are in here. The
name "applications" makes sense for the directory to me.

-- dobey