Desktop Icon Theme Unification

[Alexander Larsson]

On Mon, 2004-05-31 at 19:37, Rodney Dawes wrote:
> On Hën , 2004-05-31 at 08:15 +0200, Alexander Larsson wrote:
> > On Sun, 2004-05-30 at 02:03, Rodney Dawes wrote:
> > > On Sht , 2004-05-22 at 17:03 +0200, Daniel Taylor wrote:
> > > > I don't really follow, but it sounds interesting.
> > > 
> > > The Icon Theme Spec was basically designed for theming the icons in the
> > > "Programs" or "Applications" menus, and not so much really for theming
> > > everything else. Or at least, this is what I got out of it when I read
> > > it through.
> > 
> > How do you mean? Its based on the KDE icon themes, and that is used for
> > all sorts of icons in KDE. The primary need to standardize them is
> > application icons (since they are visible in the common desktop file
> > spec), but thats by no means the only use.
> 
> The bits about having other people install random files into the hicolor
> theme, and expecting "hicolor" to be a reasonable fallback for
> everything, having it be the root node of the theme tree. This will also
> become much more of a problem once we can start getting things moved to
> using a standardized set of icon names. Having random themes and apps,
> from multiple desktop environments, with conflicting default styles, is
> just asking to have a big mess on our hands. As more and more
> applications get written, and need more icons, and want to use the icon
> theme spec to handle their icons, the risk of file conflicts, and over-
> writing icons from other applications, and desktops, increases greatly.

Without a common place to install icons, where would you tell third
party ISVs to install icons though? And anyway, the icons installed
*need* to not conflict anyway. Its not like its an insolvable problem,
debian ship a bazillion packages, and yet there is no /usr/bin filename
conflicts.

> Standardizing on icon names, cleaning up the spec to remove the
> dependency on a central fallback location, and requiring the
> implementations to provide API to add fallbacks to the tree, would
> help tremendously with the potential problems we currently have, I
> think. Then, apps like evolution, for example, can install a theme like
> "evolution-fallback" that is hidden, and tell the theme API to fallback
> to that. And, the various desktops and toolkits can provide their own
> fallback themes that get inserted appropriately in the tree, and avoid
> possibly conflicting with the themes of other desktops. Doing things
> like this just seems The Right Way (TM) to me, but I am open to more
> discussion and suggestions for what to do here.

The way KDE does this is that each app gets a private directory in
/usr/share/kde/$appname/ or something like that. The icons subdir of
that is then automatically appended to the icon theme search path (same
happens with other system paths). Then the app can ship both its own
hicolor subdir with default icons plus icons matching any specific theme
it wants.

However, this is not a solution for the "hidden icons" problem! If an
app installs hidden icons with a name that conflicts with another app,
then you can't create a theme that properly themes both those icons. You
just can't have name conflicts and still support theming.

Also, the kind of "changing the default fallback" munging you describe
won't work for e.g. libraries or components that has themed icons.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a shy flyboy card sharp with nothing left to lose. She's an orphaned 
foul-mouthed femme fatale from the wrong side of the tracks. They fight crime!