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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
