"pseudo icon" mechanism to the icon theme specification
frans.englich at telia.com
Thu Jul 22 01:17:33 EEST 2004
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:
+ 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.
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
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 -
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.
More information about the xdg