Re: breakage caused by removed icons from gnome-icon-theme

[Rodney Dawes <dobey novell com>]

On Mon, 2006-02-06 at 11:15 -0600, Federico Mena Quintero wrote:
> On Sun, 2006-02-05 at 11:00 -0500, Rodney Dawes wrote:
> 
> > Someone should file some bugs then. Just complaining that /some/
> > icons /may/ be missing isn't going to get it fixed. And, fwiw, the
> > ABI stability guarantee doesn't seem to apply to the desktop, but
> > only the developer platform. And gnome-icon-theme is part of the
> > desktop, not the developer platform. Also, gnome-icon-theme was
> > never guaranteed to be in the fallback icon path. It has only ever
> > been the /default/ icon theme, in very informal informal and ugly
> > ways. But I've also improved that for 2.14, and while the settings
> > daemon is running, with gtk+ 2.8.10 or later, the "gnome" theme will
> > always be searched for icons, before hicolor.
> 
> We should make one of the icon themes part of the platform.  In
> particular, gtk+ depends on hicolor, but that fact is not listed in our
> jhbuild moduleset.

I don't disagree about making them part of the platform. However, I
think we should have a stable documented API for them before they are
considered to be stable and an API. This is what the Icon Naming Spec is
for, although it is not yet complete. However, by GNOME 2.16, I hope to
be able to call the base spec complete and 1.0, and guarantee API/ABI
stability with it. The current situation is not an API. It is a
clusterbomb of random icons that were named a certain way, because a
developer wrote a feature, and decided it needed an icon, and picked a
name at random, or used an icon already in the set, that doesn't really
make sense for the item they associated with it. However, all the work
I've been doing with the spec and cleaning up gnome-icon-theme is to
get all this fixed, so we can actually do things The Right Way.

> Two questions:
> 
> 1. Can we get this mess fixed (either by fixing apps, or by providing
> fallbacks/symlinks/whatever) before the 2.14 release?

I see no problems with getting things patched to use new icons, and
adding symlinks/fallbacks where appropriate by 2.14. I don't know if
Alex's work for the MIME fallback stuff will be available by 2.14, but
we can work assuming that it won't be, and still solve the issues. The
problems are not hard to solve, but it seems to me that people would
rather argue about them, than get them solved.

> 2. As soon as 2.14 is released, can gnome-icon-theme commit to the same
> ABI stability rules as the rest of the platform?  Icon names *are* part
> of the ABI, since that's what apps use.

I am not willing to call the set of icons that will be in 2.14.0 a
stable ABI. However, if we want to move the icon theme into the stable
developer platform as part of 2.16, and guarantee stability by the 2.16
scheduled API/ABI/feature freeze, I am willing to work to meet that
goal. I think that's a reasonable timeframe to call the naming spec 1.0,
and have GNOME migrated to using the spec, and using sane fallbacks, as
well as dropping the symlink compat bits, so that we can have a nice,
small, generic set of base icons as the default, and have the ability
for -extras themes that provide more specific icons for MIME types. This
would clearly solve the issue of not having the [JPG] and other labels
in the icons, for people that want them, and keep the default nice and
simple for the people who just odn't care if a file is a jpeg, gif, or
whatever. A lot of the icons also should just really be moved into the
apps themselves, and some of those that are now used, were put into the
theme quite hastily, I think, in an attempt to satisfy that period where
everyone was all hyped up about having generic items in the applications
menu. The timeframe for 2.16 freeze, I think and hope, would let us
work out all of these smaller issues, and make the whole icon theme
thing really kick ass in our desktop.

-- dobey