Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
dobey at novell.com
Thu Jun 29 02:50:38 EEST 2006
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:
> 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.
More information about the xdg