"pseudo icon" mechanism to the icon theme specification

[Frans Englich]

Hello all,

When developers use icons in their applications, they usually look one up in 
the icon theme matching their intent, and then uses the name in the code. For 
example, KDE's logout dialog uses Konqueror's reload button for its restart 
action. This causes a modularization problem; when the reload button is 
changed, or even the whole icon theme switched, the new icons may not match 
the various uses.

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 
that "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."

Specifically, I am proposing extending the icon theme specification with 
adding this desktop file directive for the icon data file:

+           <entry>IsAlso</entry>
+           <entry>
+             A string list, as per the desktop file specification,
+             of icon names which the icon also corresponds to. Its usage
+             resembles a symbolic link or mapping, which allows multiple
+             icon names to refer to one actual icon.
+           </entry>
+           <entry>strings</entry>
+           <entry>NO</entry>

If I have interpreted the spec correctly, the icon data file applies on a 
per-size basis. Is it somehow possible to make one icon data file cover all 
sizes? This would be of interest for the IsAlso, and potentially the other 
directives.


This "pseudo icon" mechanism has the following advantages:

* It solves the modularization problem described above(developers have 
flexibility without causing trouble)

* It's a method to provide backwards compatibility when a standardized icon 
naming scheme is adopted in the icon theme, for example

* Lowers the threshold for icon theme writers since a small numbers of actual 
icons can cover several usages

As far as I can tell, this mechanism can be implemented in two ways:
1. Making the icon loader aware, which then can optimize icon loading, effect 
transformations, and memory management since it knows which ones are "fake" 
icons. If an icon theme(rather theme.index and icon data files) tailored for 
performance is used, such optimizations could make a difference(no numbers - 
pure speculation).
2. Making the install mechanism create symbolic links according to the icon 
data files. This is how it's thought to be implemented in KDE. In one way this 
solution pushes the implementation on the icon theme author.

Clarifications, corrections and suggestions are appreciated.


Cheers,
Frans Englich
KDE developer