How to do post-4.0 icon naming changes
faure at kde.org
Tue Jan 15 12:15:05 GMT 2008
On Tuesday 15 January 2008, Jakob Petsovits wrote:
> Heya core-devels and artists,
> KDE 4.0 follows the fd.o icon naming spec where reasonable and doesn't break
> seriously - even if both icon theme switching and non-Oxygen fallback icons
> are a mess in 4.0.0, but that's fixable in a straightforward and binary
> compatible way. The recent mail on the kmail icon and comments by Jonathan
> Riddell (and probably more) make it clear that, while I'm quite satisfied
> with how the release worked out, we're not fully done.
> Now that 4.0 is out and the names are supposedly frozen, I'd appreciate input
> on how to proceed if something needs to be changed - for example, if icons
> still change in the naming spec, or if it is determined that I made an error
> in renaming stuff. Also, while I managed to make icon names not clash with
> other themes, there's still a whole lot of icons that would like to be named
> more clearly or more use case centric (arrow-* anyone?).
> The question for me is whether to
> a) stick with 4.0 names for existing icons, or to
> b) copy those to better names and still keep the old versions, or to
> c) somehow get rid of old (previous 4.x) icons while not breaking apps.
> (a) has the advantage of not breaking or complicating anything, but will
> result in more applications using icons that are not supposed to be used by
> that name, and is unflexible if we want to standardize on names that haven't
> been right at first try.
> (b) doesn't break anything and makes it possible for apps to use better icon
> names as well as to standardize on names that haven't been right at first
> try, but increases complexity for developers and artists as multiple versions
> of the same icons will by lying around, plus developers will still use
> deprecated icons because they find those in their icon theme directory.
> It also gets harder for theme creators because they need to do multiple names
> for the same icon, which we wanted to avoid with KDE 4 icon naming.
> (c), if performed as pure renaming without further measures to be taken, will
> break icons that work fine in 4.0. Which is probably not a good idea in terms
> of backwards compatibility. Apart from that, benefits galore.
> My personal preference would be (c) with some smart mechanism that shows icons
> when they are requested but not in the icon dialog or among valid icons in
> the theme folder... that would need some smart-ass code solution, though.
> (Ideas on how to do that are highly appreciated!)
It doesn't need to be "smart-ass" :), but a simple mapping file could be read by
KIconLoader in order to keep behavior compatibility indeed.
Just a file with
and a QHash<QString,QString> in the code.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel