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

[Rodney Dawes]

On Thu, 2006-06-29 at 00:49 +0200, Thiago Macieira wrote:
> Sorry, I completely disagree.
> 
> Why should application A care about application B's private files? They 
> are *private* so they can:
> 
> a) disappear from one version to the next
> b) change names
> c) be in a completely different format

Nobody said that application A would care about application B's private
data, or even implied that it would. What application A does care about,
is that it doesn't conflict with application B's data, by installing a
file of the same name into the same location (hicolor). These icons need
to be themable, the same as the rest of the icons in an application.

> What I do agree is that an application should be reserved one directory 
> where it can store any kind of file it wants, in whatever layout it 
> wants. The FHS already describes two possibilities already:
> 
> /opt/$appname
> /usr/share/$appname
> 
> I think the second option is inefficient if we take into account the 
> number of applications that get installed. We confuse /usr/share/$concept 
> with /usr/share/$appname.

They are no more confused they they are now. You can't possibly tell me
that share/apps and share/applications isn't confusing. It is the very
definition of the word.

> PS: like Waldo said, KDE was meant to be installed in /opt/kde, 
> so /opt/kde/share does not follow FHS and should not appear 
> at /usr/share.

While KDE may not have been meant to be installed into /usr 8 years ago,
the option to do so, should not be disallowed. KDE is a lot of things it
wasn't meant to be, 8 years ago. KDE needs to become a fully integrated
piece of the desktop. We shouldn't be treating it specially because of
what someone wanted some piece of it to be like, 8 years ago. It should
be a part of the creation of specifications for all desktop
environments, and an example of implementation to them, as well.

-- dobey