How to do post-4.0 icon naming changes

Jakob Petsovits jpetso at
Tue Jan 15 03:25:09 GMT 2008

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!)

In case no such solution can be found, please tell me which of {a,b,c} you 
prefer, and how it fits in with your vision of doing things the KDE way.
(Or whatever.)


More information about the kde-core-devel mailing list