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

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Wednesday 28 June 2006 23:21, James Richard Tyrer wrote:
>> Aaron J. Seigo wrote: There *is* KDE GUI configuration in 
>> $PREFIX/share/config/.  There may also be other information, but it
>>  is the GUI information that I am concerned with.
> 
> please realize that it's more than GUI information in there and 
> splitting things out hither and yon is not an improvement for the 
> users and sys admins who get to deal with this stuff.

No need to split things out.

IAC, all I find on my system's $KDEDIR/share/config" directory, other 
than a lot of *rc files, is:

	A subdirectory: "ui" that also contains *rc files.
	The: "colors' subdirectory.
	The: "kdm" subdirectory.
	The: "magic" subdirectory.

So, I don't see a lot of other stuff that would need to be changed.

> as someone who spends a lot of time with our users and sys admins 
> around the world i'll tell you definitively that it's the 
> straightforward nature of this design that wins many hearts.

You mean that having the directory for KDE's GUI configuration named
"config" rather than kde-<major_version> is an important feature.  It
appears to me (since it is more consistent with the way that other
software does it) that a name starting with 'kde' would be more
straightforward when looking for KDE stuff in 'share'.

>>> also note that if we make this change to $PREFIX, for kde is 
>>> makes no sense not to make this change globally and mimic it in 
>>> $HOME as well.

>> Yes, you have a point.  We have in for KDE:
>> 
>> SHOME/.kde/share/apps/<app_name> 
 >> $HOME/.kde/share/config
>> $HOME/.kde/share/icons
>> 
>> which would probably be better as:
>> 
>> $HOME/.<app_name> 
 >> $HOME/.kde-3
> 
> oh god no. things were put into $KDEHOME to avoid a $HOME filled with
>  hundreds of dot directories with a forest of them for people to pick
>  through.

Well, as I keep saying.  I already have a "forest" of dot directories in
my $HOME directory (dot files + dot directories = 142).

> it's like we're back in the 1990s all over again with this 
> discussion.

But, the point is that other apps install their dot files and dot
directories in $HOME.  I don't like this, but it is the way it is.

> not to mention we lose the very nice semantics of "system fs mimicked
>  1-to-1 by every waterfalling config prefix".

I don't see that the: ".kde" is needed (before 'share') for this.

It would be better if it were:

SHOME/.share/<app_name>
$HOME/.share/kde-3

Perhaps we could work towards that.  This would clean up the forest if
all apps would use it.

>> $HOME/.icons
> 
> that should be ~/.local/icons/ in true xdg style

That would be OK with me.  What is needed is a standard so that third
party apps don't have to install stuff (e.g. icons) in more than one place.

<SNIP>

> i don't think you understand how icon loading works. it's done 
> in-process by the app's toolkit. even if it spoke to an external icon
>  daemon, the loading from that daemon would still happen in-process 
> to the application.

I have been programing computers since you had to punch holes in those
damn cards, and you tell me that I don't know how calling a subroutine
works?  I see no need for a daemon, just a library call to load the icon.

> it wouldn't really make sense for Portland to take over installing an
>  app's own icons.

The only thing that matters here regarding installing icons is that they
get installed in only one place.

> there is an icon installer for Portland for -global-, and in 
> exactitude, the application's own icon. not  app-specific toolbar, 
> menu and dialog icons, which is what are stored in
> share/app/$APPNAME/
> 
> perhaps misunderstanding this is what has led you astray here?

What I am talking about is loading icons with a toolkit|DeskTop 
subroutine (IconLoader).  There is a subroutine (or class) in KDE 
called: "KIconLoader" and this (actually an instance of it) loads the 
icon.  I am presuming that if the KDE DeskTop is running that it would 
be possible for a non-kde app to use this indirectly by going through a 
Portland library call.  Am I in error here?

>>> as for the "third party application" concept it's equally absurd:
>>>  a third party app should not depend on the location of private 
>>> data files of another application.
>> This Herring is red. :-)  What this is about is a third party app 
>> not having to install things in multiple locations.
> 
> they don't have to today. that's kind of the point.

OpenOffice 1.x had to install its public icons in two places.  This 
subthread started when a GNOME programmer commented on where he was 
installing private icons for an app and it wasn't the same as where a 
KDE app should install them.

>> There is nothing it this concept of "private" icons that requires 
>> that the application be responsible for managing them and (as I am 
>> sure you know) with KDE apps, the app is not responsible for this 
>> -- the KIconLoader is.
> 
> right. and the KIconLoader is used by KDE apps to load their private 
> icons. so unless KIconLoader is meant to load GIMP's -private-, 
> -non-global- icons, this discussion is completely irrelevant.

This discussion is about the fact that there isn't an XDG standard place 
to install "private" icons.  The proposal is to use the KDE method 
except for this small detail of the 'apps' subdirectory.

-- 
JRT