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

[Andreas K. <and...@ac...>]

Joe English wrote:
> 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 :-)

Correct.

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

Ok, this definitely makes the picture regarding the handling of size clearer.
Not something the application code specifies directly, but indirectly through 
the context. Explicit sizes should not appear in the highlevel API.

 > 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).

Oh. Computed icons ... Or precomputed and put somewhere ... Although computed 
is likely more correct because I am guessing that the e/i/q-symbols are 
provided by OS X itself, in a std location.

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

YAGNI ... Ah, you aren't gonna need it.

Opposite view to JeffH's.

Andreas.