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

[James Richard Tyrer]

Aaron J. Seigo wrote:
> On Wednesday 28 June 2006 16:10, James Richard Tyrer wrote:
>> Rodney Dawes wrote:
>>> The stuff in config, should probably actually be in /etc or such.
>> Since this is GUI configuration information and GNOME also puts it as a
>> subdirectory of 'share', I would keep it where it is and just change the
>> name of the subdirectory -- kde-3 in the current case.
> 
> it isn't just GUI configuration information. it can be any data or 
> configuration specific to an application.

All A is B does not imply that all B is A.

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.

> 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
	$HOME/.icons

> i also don't see the problem of having share/apps/appname/ because really if 
> all these apps live in /usr/bin/ anyways they all have unique names so the 
> dirs under share/apps will have unique names if named after the applications.

The problem lies with what a third party app is expected to do when it 
installs (in this case) icons.  There is one location for KDE and one 
generic location.  Should it install private icons in both:

	$PREFIX/share/<app_name>/icons
	$PREFIX/share/apps/<app_name>/icons

> and WHY do we need a common place for app-specific icons? answer: we don't. we 
> don't need it because it's not something shared between applications. or are 
> we thinking that one day KIconLoader will load GIMP's icons? *raises an 
> eyebrow* 

It isn't about the KIconLoader loading a GTK app's icons.  It is about 
the fact that if Portland is to succeed, it is about the current 
DeskTop's icon loader loading the third party app's icons.

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

> period. that's sort of the definition of "private". if those 
> files are not meant to be private then they are stored elsewhere. as is 
> covered in the icon specs for icons.

You are misunderstanding the definition of 'private' in this context to 
  reach an incorrect conclusion.  The terms 'global' and 'private' are 
used to describe two concepts.  It is those concepts that have meaning, 
not the words used to describe them.  Global icons are icons that are 
available to be used by all applications.  Private icons are icons that 
are available to be used by only the application that installed 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.

> sorry, this is just asking for us (KDE) to do a bunch of work for a nonsense 
> use-case with not real world benefit.

The future benefits of standardizing the ways that various DeskTops do 
things should be self evident.  I don't see KDE needing to do a bunch of 
work but standardization is going to require that everyone make a few 
changes to improve things.

-- 
JRT