Re: [Tcllib-devel] FamFam icon sets as packages - Tklib candidate - Requesting Review

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:

> Joe English wrote:
> > The fd.o spec
>
> Googling for this ... This is the "freedesktop.org" specification ? Is there
> particular sub-spec I should look at ?

That would be the freedesktop.org "Icon Theme Specification",
see previous message:

| [1] http://freedesktop.org/wiki/Specifications/icon-theme-spec
| [2] http://freedesktop.org/wiki/Specifications/basedir-spec
| [3] http://freedesktop.org/wiki/Specifications/icon-naming-spec

... which looks like it got delivered out of order,
see *next* message :-)

>  > classifies icons by size (12x12, 16x16, 32x32, 36x36, etc...);
> > there can be multiple versions of a single icon at different sizes.
>
> > I find it more useful to classify them by "context", i.e.,
> > icons for menus, for buttons, for toolbars, for dialog boxes, etc., ...
> > (This fits in nicely with Oakley's "Actions").
>
> Hm. Not sure if I understand this correctly ... different icons for the same
> action but in different contexts ?

Yes: you might want a 12x12 icon for use in menus,
a 24x24 icon for command button -images, and a 48x48 icon
for toolbar button -images.  I find it more convenient to say
"Gimme an icon that will fit in a menuitem -image" than have
to remember that menuitem images are 12x12.  The appropriate
size icon for a particular context can also vary by platform
and/or user and application preferences.  In some cases the
content of the icon itself varies by platform (e.g., dialog
icons for error/info/question/warning on OSX should be the
application icon, with the error/info/question symbol as
an overlay).

> > I've also found it useful to have variants based on state;
>
> Right ... Did not think of that, should have, we have stuff like that in the
> Tcl Dev Kit applications. although not everywhere I believe, there may parts
> managing it automatically ...
>
>  > for instance
> > a toolbar icon might have a grayscale variant for when it's disabled
> > and a brighter variant for when it's active.  (AIUI, Qt and Gtk+
> > manage this programmatically.  Tk can do this to a certain degree --
> > autostippling images when disabled, f'rinstance
>
> This is something the package could handle internally ... Look for state
> specific icons first, and auto-stipple/brighten if no physical icon is found
> for the requested variant ... Question is, should we ?

I'd say initially no, YAGNI.  It's just something that I've found
useful myself occasionally, thought it was worth mentioning.


--Joe English