The problem of icon names

[Ingo Klöcker]

On Thursday 15 July 2004 01:28, Frans Englich wrote:
> When we use icons in our applications, we look up one in the icon
> theme matching our intent, and load it by its name. For example, the
> restart button in the logout dialog uses Konqueror's reload icon
> because it looks like what we wants.
>
> This causes a problem: it breaks the modularized design. When
> Konqueror's reload button is decided to be updated, the new look does
> perhaps not fit the intent in the logout dialog(or any other place it
> is used). Not to think of when a whole icon theme is updated or
> switched.
>
> I think the solution to this problem is to add an optional mapping
> layer between the icons and the icon loading mechanism; the icon
> theme can specify "the icon X goes under the name X, as well as the
> pseudo icons named Z, Y and N." For example, the crystalsvg theme
> could specify "the restart icon maps to Konqueror's reload icon."

... and set an appropriate symlink.

> This has the following advantages:
>
> * It solves the modularity problem described above
>
> * It lowers the threshold of creating icon themes since one can cover
> all icons usages without having actual icons for them.
>
>
> In short, it significantly helps the problem of icon names being hard
> coded, and gives additional flexibility. For example, if icon names
> once becomes standardized, the icon names in the code can be changed,
> and icon themes easily keep up without having to create icons.
> However, "pseudo" icons would take a little longer to load(due to the
> mapping overhead) and a similar result can be achieved by simply
> copying the icons.
>
> Is it only me who sees this problem, or have I missed something
> crucial?

Which part of this can't be solved with symlinks?

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040715/c7eea913/attachment.sig>