Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
thiago at kde.org
Thu Jun 29 01:49:18 EEST 2006
James Richard Tyrer wrote:
>> I agree that icon loader implementations should be able to load
>> application-specific icons on-the-fly, but I don't agree that the
>> method should be part of the icon theme specification, or where those
>> applications should keep their files.
>> For example, applications could decide to keep the icons in the
>> executables themselves, or keep it in a large .zip file or any other
>We have KDE apps that don't store their icons in the standard location.
> This isn't good. But, the point is that for different DeskTops to
>become more interoperatable, they need to do things in the same way.
>This is a first step that may not have any immediate benefits, but it is
>still needed for future benefits. So, the location where apps should
>install their private themed icons is a relevant part of the spec.
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
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
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
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech ASA
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | NO-0402
966C 33F5 F005 6EF4 5358 | Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060629/265d0249/attachment.pgp
More information about the xdg