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

[Aaron J. Seigo]

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.

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.

> > 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. it's 
like we're back in the 1990s all over again with this discussion.

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

> 	$HOME/.icons

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

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

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.

it wouldn't really make sense for Portland to take over installing an app's 
own icons. 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?

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

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

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

not all things, no. some things are irrelevant.

> I don't see KDE needing to do a bunch of work

erm. i do. and i'm going to guess i'm a bit more familiar with the code base?

> but standardization is going to require that everyone make a few
> changes to improve things.

for the sensible standardization case i have no argument with this.
this is not a sensible standardization case.

-- 
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/20060629/c5a29924/attachment.pgp