Re: gtk_window_set_icons

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp redhat com> writes:

> Owen Taylor <otaylor redhat com> writes: 
> > getters and setters and properties all need to give back what was set.
> > If you go with a list (see below), then the behavior is obvious,
> > though limitations of our current set of types probably make the
> > property uninteresting.
> 
> Do we have any way to have a "list of pixbufs" property?

Nothing worth using:

 G_TYPE_POINTER
 G_TYPE_VALUE_ARRAY 
 
Are both far too generic to be useful. The best choice would probably
be to use a custom boxed type ... GTK_TYPE_ICON_SET actually is pretty
close, but doesn't exactly make a convenient interface either.

 g_type_register_array (GDK_TYPE_PIXBUF);

Is something we may want have in the future.
  
> > Ugh. What an awful interface. Look how much text it took you took explain
> > it in the docs!
> > 
> > "Pick 1,2, or 3 icons, of sizes close to the sizes of the parameter names,
> > then match them up with the parameters" is just too painful.
> > 
> > I think a list + a recommendation in the docs: "a good choice for the sizes
> > to include is 16x16 and 48x48" would be much nicer. 
> 
> I am not that fond of the interface, but I hate the list too.  It
> continues the "make up some sizes" pattern currently seen in X. Plus
> GList interfaces are annoying to use and not very self-documenting.

Unfortunately, in light of changing resolutions and lots of different
use cases, it's hard to get away from the "make up some sizes" idea.
(Multiple-master SVG icons? ...)
 
I agree the GList is moderately annoying. It's possible a GdkPixbuf **
would be less annoying, though I'm not so sure. Since you already
have to worry about loading the icons, dealing with errors, unref'ing them 
afterwards, I think it isn't an unbearable addition of annoyance. 

> Admittedly, in the light of day my attempts to avoid the list didn't
> work out so well. Suggestion below.

> > > I wasn't sure what size to use for the WM_NORMAL_HINTS pixmap
> > > though.
> 
> We do need to do our own scaling here. There should be a standard size
> for the pixmap, WM's can't really scale it unless they are the kind of
> WM that will prefer _NET_WM_ICON anyhow.

Well, I'd say, the heuristic should be -- if there isn't a provided
size between 44 and 56 pixels, then scale the closest icon to 48
pixels, otherwise use the closest size.  
 
> OK, if we do the list, I think we should have:
> 
>  gtk_window_set_icon_list (GtkWindow, GList)
> 
> but also simply:
> 
>  gtk_window_set_icon (GtkWindow, GdkPixbuf)

This seems fine to me. Except for those blessed with a ready-to-hand
graphic artist, most people will be lucky to have one icon anyways.
 
> The docs for the list are "set whatever natural sizes you have" and
> the docs for set_icon are "set the largest natural size you have which
> isn't larger than 48x48 or so"

I think I'd just tell people to set the largest natural size they have.
Resolutions are increasing, and if I was drawing icon art, I'd make the
masters at least 96x96 and maybe 128x128. 

(And interesting point here is that if you have multiple hand drawn
versions of an icon, it's frequently right to pick the best one not
by pixel size, but by physical size. I might want the "less detail"
version not only at 16 pixels on a 72 dpi display, but also at 48 pixels
on a 200 DPI display. This probably can be ignored for now.)
 
> I think we need gtk_window_set_icon(). Otherwise I know I will get
> annoyed every time I have to build the list.

I think including gtk_window_set_icon() is fine. 
 
> Opinions on:
> 
>  gtk_window_set_default_icon(_list?) 
> 
> and the transients-inherit-from-parent behavior?

The default icon idea sounds like a good one. The nice thing about
transients-inherit-from-parents is that it is behind-the-scenes,
but I'm not sure it will provide more actual functionality beyond
the default-icon. 

Regards,
                                        Owen