Re: Setting window icons

[Darin Adler <darin eazel com>]

on 2/21/01 6:47 PM, Havoc Pennington at hp redhat com wrote:

> I just really question the value of an undifferentiated list - if we
> have semantically distinct icons, should be multiple functions:
> 
>     set_icon() 
>     set_mini_icon()
>     set_accessible_icon()
> 
> or whatever. But it would be nice to set the mini icon automatically
> from the regular icon if it isn't explicitly set, and I'm not clear
> exactly how many kinds of accessible icon there might be (big?
> contrasty? no idea).

I tried to ignore this discussion, but it's too much like a rerun of design
issues we faced when I worked on Macintosh icon functions in 1988 for me to
stay entirely silent.

The Macintosh toolbox uses a concept of icon suites. When we invented icon
suites, they consisted of a 32x32 icon and a 16x16 icon (also a 12x12 icon,
but that was rarely used). At the time, issues of color depth were also
important, so the suites always included 1-bit versions, and optionally
included 8-bit or 4-bit ones. Later, Apple added the 32 and 16-bit icons, as
well as larger sizes. This icon suite data structure proved to be incredibly
useful, and was used for everything from the Finder icons to the application
icons that appeared in the top right of the screen and the icons in menu
items and titles.

The strength of the 16x16 icon was that it fit nicely in places like the
menu bar, window title bars, and anywhere that the height of the space was
determined by the height of standard-sized system text.

The strength of the 32x32 icon was that both was the standard "full size" in
the Finder at the time and that it fit nicely in roomier places like the
upper left corner of dialogs.

I imagine this was imitated on Windows, although I don't know the details of
what was done there (and I guess I don't really want to open that discussion
here). In Mac OS X, an expanded version of the icon suite idea (under a new
name) is being used more than ever due to an emphasis on resizable icons.

One lesson to learn from this is that such a suite of visually similar icons
at standard sizes is a useful item to treat as a unit for programmers and
even for file (or at least directory) formats. Doing things this way on
Macintosh meant that programs that could edit icons understood the
relationship between smaller and larger versions of the same icons, and more
importantly that programmers had an easy time slinging these things around.

In fact, there were icon drawing routines that select the appropriate icon
for a particular size, and also draw the various variations on the icons,
including what we would call the "insensitive" version, selected versions,
"open" versions, versions with "badges" (for locked files and links), and
colored versions (for the Macintosh Finder's "label" feature). Centralizing
this meant that icon suites could later be extended to give the icon
designer more control over how these images look when drawn in these variant
ways (if necessary). Most programs didn't ever "pick apart" the icon suites,
instead just loading them from files (actually resources on Macintosh) and
then drawing them without every cutting them open to get at the individual
images inside.

These icon sets are analogous to font "families" where you may have a few
specific sizes expressed as bitmaps along with a higher-resolution scalable
font, although there's a even more importance to having standard sizes for
icons. Separate calls to set each icon, while more clear semantically, would
have been harder for the average programmer to "use right".

I'm sure we can come up with something even better for GTK, but perhaps the
occasion of adding a call to set the window icon is not the right time.

    -- Darin