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

[Shaun McCance]

On Fri, 2006-06-30 at 15:02 -0700, James Richard Tyrer wrote:
> Aaron J. Seigo wrote:
> > On Friday 30 June 2006 13:24, James Richard Tyrer wrote:
> >> I proceed on the valid theory that the lack of standards also
> imposes a
> >> price on third party applications.  Such applications have to
> install
> >> their icons somewhere.  In some cases they must install them in
> multiple
> >> locations to try to comply with the methods of multiple
> >> DeskTops/ToolKits.
> > 
> > which app uses multiple toolkits to load icons today?
> 
> I believe that the purpose of Portland and XDG standards is for
> *future* 
> cross DeskTop/ToolKit compatibility.  Obviously, there may be nothing 
> _today_ because the standards which would make it possible don't exist
> yet.
> 
> > which kind of app would want to use multiple toolkits to load icons?
> 
> Obviously, a third party app which did not use either KDE or GNOME
> for 
> its ToolKit and used Portland to access functions to load icons would 
> need a standard location to install such icons.  IIC, the Portland 
> manifesto advocates a common interface for third party apps to access 
> such functions which would not be dependent on the DeskTop that it
> was 
> being run with.
> 
> So, the answer is: a third party application that loaded icons by 
> accessing the DeskTop's ToolKit through Portland library functions
> (IIUC 
> a wrapper of sorts).

KDE and GNOME aren't toolkits, per se.  QT is a toolkit.  GTK+ is
a toolkit.  When we strive for desktop interoperability, we want
you to be able to use QT or GTK+ without tying yourself to KDE
or GNOME.  It's a very important issue.

What is *not* an important issue, and what we should not be wasting
our time on, is the ability to have program that don't depend on
the toolkit it uses.  As an application developer, you choose your
toolkit (and the rest of your development platform) and you work
within it.  Specifically, in this context, you use its icon loader,
if it provides one.  If it doesn't, you use the icon loader from
some other library.  Or you roll your own, if you have too much
free time.

End of the day, you are using one icon loader.  If Portland ever
provided an icon loader, and projects used that, they wouldn't
be using some sort of neutral non icon loader.  They would be
using Portland's icon loader.  It would have its API and its
set of rules, and you'd work with those.

Where you install your application-private files is really not
interesting, from an interoperability point of view.  I'm sure
it's interesting from other points of view, such as not giving
systems administrators migraines.  But it doesn't affect the
ability of a GTK+ program to run seamlessly under KDE.

There are so many real problems that need to be solved with
icon theme interoperability.  Can we please solve them?

--
Shaun