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

[Rodney Dawes]

On Thu, 2006-06-29 at 11:44 -0600, Aaron J. Seigo wrote:
> On Thursday 29 June 2006 09:09, you wrote:
> > 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.
> 
> i assumed this was in addition to, not instead of.

Given that all possible directories aren't going to exist, you are still
going to end up with no more additional directories causing hits to the
disk, than you have now. Or shouldn't anyway. I don't know the code. It
could be badly written, and hit the disk for every possible directory
during every icon lookup. But that's a bug anyway and should be fixed.
Even if we do as you suggested in another mail, and put the icons in
$datadir/appdata/$appname/icons... you still end up with the same need
for fallback in KDE. So using that as an argument against just putting
the icons in $datadir/$appname/icons... doesn't really work.

> > > > 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.
> 
> no conflict would occur if they were inside a subdir specifically set aside 
> for application directories. there is method to our madness.

This still needs to be in a spec somewhere, no matter what directory
these icons end up in. Currently, the specification implies that *all*
icons that an application wishes to be themeable, should be installed to
hicolor. This is very bad, and also not the actual intention of the
spec. The intention of the consensus that James and I reached to put
these icons in $datadir/$appname/icons as a method for applications to
provide their own fallback icons without any extra programatic work for
the app developers, was to resolve this confusion, and add to the spec
where it so direly needs addition.

> > 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.
> 
> ah .. i think we're perhaps talking about slightly different things, and my 
> use of the env vars literally probably didn't help the confusion. sorry.
> 
> you are focussing on the system-wide directories, while i'm pondering not only 
> that but also the additional impacts to ~/.local and ~/.config which reflect 
> the same structure and are used for single-user modifications and 
> installations. they are the "user's" XDG_DATA and XDG_CONFIG dir, so to 
> speak.

We're probably certainly talking about different things. Given that you
already pointed out that kde stores data in ~/.kde/<something>, this new
argument about .local and .config is irrelevant. The Icon Theme
specification clearly defines ~/.icons as the home search path. This new
proposal in no way affects that, nor does it need to alter the behavior
for ~/.kde which is outside the scope of the specification anyway.

> i do think that putting application dirs in the same dir as non-application 
> dirs (as we do in /usr/share) is utter insanity; i'm not the only one and 
> that is why KDE doesn't do that. it would be nice if we didn't let this 
> disease spread into user's home directories as well. it would be -awesome- if 
> we could fix it in $XDG_DATA_DIRS as well, and the fix is pretty trivial: 
> move desktop app data dirs into a directory specifically set aside for app 
> data ... or move everything else that isn't app-specific data somewhere else, 
> though that probably makes less sense. but one or the other.

I don't disagree that non-application dirs that are not part of the FHS
specification, don't belong in /usr/share. User's home directories are
not at issue here. The change to ~/.kde to match the change to the
system directory changes would be minor, and as it sounds, falling back
to the old stuff would be inherent in the code anyway. What you
continually fail to realize is that /usr/share is specifically set aside
for static architecture-indepedent application data, and so you keep
saying that we need a new directory for that, but we already have one.
And I will agree that the stuff that isn't static
architecture-independent app-specific data, should be moved elsewhere.
As it stands, the proper location for $datadir/applications is most
likely somewhere in /var. I think moving that, and mime, to
say, /var/xdg/{applications,mime,$potential_other_db_stuff} would be a
good move on our part.

> > > 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.
> 
> all of which are namespaced by definition (the binaries they are named after 
> have to co-reside in $PATH)

What does this statement have at all to do with the one that I made?

> > Also, this thread is about themable private 
> > icons only, and has no bearing on other private application data.
> 
> this is certainly an implication when it comes to KDE. it may not affect Gtk+ 
> apps, but it certainly does have an effect here for KDE. that's where the 'x' 
> in 'xdg' comes into play.

Yes, thank you for the condesendence. I know exactly what the X in XDG
means. And you still haven't pointed out what said implication is. From
what I can tell, it's maybe 2-3 lines more code in kdelibs, and
migrating icons over to a different directory, in the application build
systems, but that can be a slower drawn-out change. And quite frankly,
yes, the exact same implications exist for GTK+/GNOME/whatever other
toolkit apps there are.

> > However, I do believe other such data should be installed in accordance
> > with the FHS as appropriate.
> 
> the FHS is often largely inappropriate for desktop needs. great for the 
> server, crappy for the desktop.

Perhaps. But this is not one of those instances. If you feel it is,
please point out how. If you're going to debate, you need something to
actually debate with. Simply saying "I say it's bad," isn't going to cut
it. 

> > > > 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.
> 
> thanks but i was asking Waldo, actually.

You asked a question on a public mailing list. You should expect to get
public answers if appropriate. Given that neither yours, nor Waldo's,
names appear anywhere in the Icon Theme or Icon Naming specifications,
neither of you probably have the best grip or idea on where it is in
terms of reaching 1.0 status. It seems to me like Alex L. and myself are
the best to answer that question. Which reminds me that it also needs to
define a style for the hicolor theme. It's not really all that much of a
standard, if everything in it is a different perspective/palette/etc...
All of this needs to be fixed before we can call it 1.0.

-- dobey