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

[James Richard Tyrer]

Aaron J. Seigo wrote:
> 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.

I see that as an issue that needs to be addressed.  Cross platform icon
themes are going to need to supply icons for major applications.  I
thought that this was obvious.

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

As I have said many places, installing icons from other themes in 
HiColor does not make sense -- it runs counter to common sense.

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

Unless KDE (or any other DeskTop) expects that the new standard is going 
to be to do things their way, everybody is going to have to make some 
small adjustments to have a standard way of doing things.

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

If that were to be done, the subdirectory: "apps" would need to be 
changed.  I would suggest "kde-<major_release_version> or something 
starting with: "kde".

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

Actually the "xdg-icon" installer doesn't put them there. :-(  But, you 
are correct.

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

This isn't about KDE; it is about all DeskTops doing it the same way.

Private icons should go in:

	.local/share/<app_name>/icons/<theme>/<size>/<context>/

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

Yes, KDEDIRS should be deprecated and all DeskTops should use XDG_DATA_DIRS.

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

the problem is that all DeskTops need to do it the same way for it to be 
a standard.  Are you suggesting that the current KDE location should be 
adopted as the standard.  RD has already accepted my suggestion that the 
KDE method be used as the standard.  The only issue he has is with the 
subdirectory: "apps".

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

Yes, except that KDEHOME is going to become: "HOME/.local".  If we drop 
"apps" in the global structure, we need to drop it there as well.

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

The reason is to have a reasonable (and neutral) standard.

>> 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 think that that is needed either. "KDEDIR/share/config/" is a 
reasonable location except that it should really be:

	KDEDIR/share/kde-config/

to indicate that this is KDE configuration data.  Unless there is a 
reason that this data needs to be accessed by other DeskTops, I think 
that there isn't any reason to move it.  We do have a problem with 
non-static date being kept there, but I don't see it as a major issue.

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

Yes, this discussion is getting too fragmented.  I suggest starting a 
new thread with the proper subject and a summary of the issues.

-- 
JRT