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

Bastian, Waldo waldo.bastian at
Fri Jun 30 18:26:14 EEST 2006

>On Thursday 29 June 2006 01:22, Bastian, Waldo wrote:
>> icons into a $XDG_DATA_DIRS location. It's ok to add these locations
>> the search path
>... aside from the performance penalty of having yet more paths to look
>already look at a rather large number of directories in the icon spec,

Yes, but KDE now looks in $KDEDIR/share/apps/icons and stuff. For KDE4
that could be dropped in favour of some other locations. In the common
case it wouldn't need to an actual increase in lookup locations.

Yes, dropping a few locations that were added for backwards compatility
wouldn't hurt. That said, after one stat you can drop things like
~/.icons if it doesn't exist, so it may be less bad as it seems on paper
(or not)

>> The search-list for app-specific icons should include
>> $XDG_DATA_DIRS/$appname/icons/$theme/... in addition to the other
>is $XDG_DATA_DIRS/$appname already in another spec, or does this
>new namespacing mechanism? if so, i'd suggest that having a whole ton
>dirs, one per app, in $XDG_DATA_DIRS/ drowns out the other non-app dirs
>as Trash, mimetype and applications. and heaven forbid anyone actually
>an app called Trash, mimetype, applications or any of the other special
>in there ;)
>i'd really suggest having $XDG_DATA_DIRS/<something>/$appname instead
>this reason.

I don't have a real opinion on that, you may be able to just add an
$appname subdir to the existing icon-spec directory hierarchy.

>> That said, I would like to see an icon-spec that conforms with
>> implementations and that can be referred to by LSB 3.2 (ideally "icon
>> spec 1.0") before new things get added that existing implementations
>> not yet support.
>agreed. do you have a list of outstanding items you'd recommend / like
>see for a 1.0?

Not yet, but I'll work on it.


More information about the xdg mailing list