Multiple DeskTops, HiColor theme, standardized icon names, & menu icons
James Richard Tyrer
tyrerj at acm.org
Thu Jun 29 08:21:52 EEST 2006
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
> 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:
which would probably be better as:
> 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:
> 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
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
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
> 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.
More information about the xdg