"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

[Owen Taylor]

Post by 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."

If all you want to do is reduce the icon theme creator's work, you
should take a look at the icon-slicer tool:

http://www.freedesktop.org/Software/icon-slicer

Which handles icon aliases in a pretty convenient work. I think
generated symlinks work fine for that.

If you are trying to solve the problem that app authors are reusing
icons for their visual appearance rather than their meaning, I don't
really see how such a change helps - The KDE logout dialog's author
might be able to get the cystalsvg theme modified, the arbitrary app
author cannot, especially in a timely fashion.

Post by Frans Englich
Specifically, I am proposing extending the icon theme specification with
+ <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>

This is somewhat similar in intent to my WeakAlias proposal, see also:

https://www.redhat.com/archives/xdg-list/2003-June/msg00073.html

The WeakAlias proposal has the advantage that the specification goes
in a new file in the default theme - the file the app author has control
over - rather than than in an existing file that the app author
doesn't have control over. I think it's also a little easier to
implement efficiently.

Post by Frans Englich
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.

Not currently. It might be possible to extend it in some way to allow
that. The WeakAlias proposal also definitely has that problem.

Regards,
Owen