"pseudo icon" mechanism to the icon theme specification

[Owen Taylor]

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:

 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.

> 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:

 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.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040724/78cd7543/attachment.pgp