"pseudo icon" mechanism to the icon theme specification
otaylor at redhat.com
Sat Jul 24 23:19:07 EEST 2004
On Wed, 2004-07-21 at 18:17, Frans Englich wrote:
> 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:
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.
> 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>
This is somewhat similar in intent to my WeakAlias proposal, see also:
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
> 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
Not currently. It might be possible to extend it in some way to allow
that. The WeakAlias proposal also definitely has that problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040724/78cd7543/attachment.pgp
More information about the xdg