How to do post-4.0 icon naming changes
Jakob Petsovits
jpetso at gmx.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.)
Regards,
Jakob
More information about the kde-core-devel
mailing list