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

[Rodney Dawes]

On Thu, 2006-06-29 at 01:47 -0600, Aaron J. Seigo wrote:
> 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?

There would in fact, be exactly 0 performance penalty in KDE, given that
it already implements the proposed change in a KDE-specific manner.

> > 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 ;)

These directories are not globally special, and outside the scope of
freedesktop.org, would already create a conflict if someone wanted to
write an application called Trash, mime, or applications anyway. Just
the same as if someone wanted to write an app called apps. If any of
these needed to store private application data, the likelihood of a
conflict is already present. Granted, mime and applications should
probably be in /var anyway, given that they are registry databases, and
are not specific to a single application. And putting a directory called
Trash in /usr/share/ just seems bad to me to begin with.

> i'd really suggest having $XDG_DATA_DIRS/<something>/$appname instead for this 
> reason. i lean towards appdata myself (and wish that applications/ had been 
> named something else, but only so many tears can be shed for the past ;)

I don't see how the repetition of a sub-dir to contain the data that
should clearly be stored at the level of proposed sub-dir, as per the
FHS, actually solves anything. You still have a very large number of
directories below that. Also, this thread is about themable private
icons only, and has no bearing on other private application data.
However, I do believe other such data should be installed in accordance
with the FHS as appropriate.

> > 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?

This thread, and the other mails from Pascal de Vuyst and Oswald
Buddenhagen point out several confusing issues surrounding the Icon
Theme specification. I also don't think we should be calling it 1.0 yet,
especially without dependence on the Icon Naming spec, and it also being
at 1.0. There are way too many issues surrounding icon themes to just be
blindly calling the specs 1.0 and shoving them into the lsb.

-- dobey