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

[Bastian, Waldo]

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

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
introduce
>a
>new namespacing mechanism? if so, i'd suggest that having a whole ton
of
>dirs, one per app, in $XDG_DATA_DIRS/ drowns out the other non-app dirs
>such
>as Trash, mimetype and applications. and heaven forbid anyone actually
make
>an app called Trash, mimetype, applications or any of the other special
>dirs
>in there ;)
>
>i'd really suggest having $XDG_DATA_DIRS/<something>/$appname instead
for
>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
existing
>> implementations and that can be referred to by LSB 3.2 (ideally "icon
>> spec 1.0") before new things get added that existing implementations
do
>> not yet support.
>
>agreed. do you have a list of outstanding items you'd recommend / like
to
>see for a 1.0?

Not yet, but I'll work on it.

Cheers,
Waldo