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

[Aaron J. Seigo]

On Friday 30 June 2006 8:43, you wrote:
> > 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. 

if the icon doesn't exist in a directory in the set of icon dirs to look in 
then it looks in the next one. it certainly does short circuit once one is 
found, but in the case the icon is not in this new dir it means more stats.

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

not at all ... because we could simply move $KDEDIRS/apps wholesale to 
$XDG_DATA_DIRS/appdata .. which would keep things together for us, prevent 
adding another dir to the search list and prevent application name polution 
in a general purpose directory ... 

> So using that as an argument against just putting
> the icons in $datadir/$appname/icons... doesn't really work.

actually i wasn't in the email you replied to arguing against this. i was 
commenting on the specific spec modification suggested without actually 
getting into whether putting icons there was a good idea or not. at least 
with the change as i suggested it would make it probably workable for kde.

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

as has been covered infinitely elsewhere, unless we are trying to solve 
the "problem" of third party icon sets being able to add to application's 
private icons, then this is a spurious conclusion.

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

we've already been doing the right thing here for years, and honestly it 
didn't take a spec it took applying common sense to how one deals with 
private icons in a themed environment.

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

something we've already accomplished for some years now without the need for a 
spec .. and now we're being asked to change our on disk layout? no thanks.

if this really must go into the spec (and i don't think it really must, but 
whatever) then a way to make it workable for kde is to do it in a way that 
allows us to keep our $datadir/apps/$appname structure.

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

*sigh* ~/.icons if for whole icon themes (and application menu icons), we're 
talking about application private icons which get stored elsewhere. and right 
now we don't put them in ~/.icons, we keep them with the apps in the 
kde-specific version of ~/.local (essentially); it would be a step in a 
different direction for us for no gain, in fact IMHO it's a degradation of 
the coherency of our on-disk layout for application private data in KDE.

note that people have already talked about dropping $KDEDIRS in favour of just 
$XDG_DATA_DIRS so we don't have to continue interleaving them for KDE4 (code 
simplification, easier for admins, etc), so this would allow a very natural 
migration path for KDE. essentially a zero change one, aside from the 
directory location used.

you want to define where private icons go, and i'm saying that we already have 
a place and where that would work for KDE if we do end up going down this 
route. not sure where the problem is.

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

we mimic the structure in $KDEHOME for what should be fairly obvious reasons 
if one stops to think about it.

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

again, this is not optimal for us. and seeing as it's unnecessary, it would be 
a non-optimal change for no reason.

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

good job. and what i'm saying is that we have directories in there that aren't 
the name of applications along with dirs that are named after apps. for 
desktop apps it really does make sense to put them all in a common subdir.

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

this doesn't particularly solve anything for us since we have cascading 
configuration directories which work quite nicely to provide the 
underpinnings of our Kiosk system.

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

trying (apparently unsuccessfully) to communicate that the issue is not the 
number of directories it's a namespacing issue.

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

if you'd start to keep up then maybe i'd be less prone to losing patience. 
this conversation is taking way more time than makes any sense.

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

ok, let's see if i use bullet points in one place to summarize what i've said 
a few times already if that helps:

 - our users and admins are used to how it currently works
 - these extra dirs potentially add another place for us to stat for icons 
unless it is brought into line with our existing, working and successful 
on-disk layout that has already solved this problem years ago
 - we rely on mimicing the layout in system dirs in home dirs because it 
allows a very easy to manage, understand and code system of cascading 
configuration sets so that's rather relevant
 - the whole app theming their own private icons issue is a moot point in the 
scope of this pec since it doesn't impact the world outside of the app 
itself, so asking for changes to address this topic is nonsensicle, 
particularly since we don't suffer from said problems

cost/benefit analysis says "no". my flex position on this is pretty simple:

 - if this *must* go into the spec, don't make it $datadir/$appname/icons but 
$datadir/appdata/$appname/icons/themename
 - don't mandate another place for application private icons other than that 
path (e.g. don't have a separate icons-only directory for apps)

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060630/7463c028/attachment.pgp