Re: GIcon thoughts

["Matthias Clasen" <matthias clasen gmail com>]

On Jan 10, 2008 5:16 AM, Alexander Larsson <alexl redhat com> wrote:
>
> > GdkPixbuf *
> > gtk_icon_info_load_at_size (GtkIconInfo *info,
> >                             gint         pixel_size);
> >
>
> Since this does I/O it would be nice if it took a GCancellable argument.
> However, that might be slightly weird, given that
> gtk_icon_info_load_icon() doesn't. It should have a GError arg too.

Fair enough. So we make it

GdkPixbuf *
gtk_icon_info_load_at_size (GtkIconInfo      *info,
                                            gint                    pixel_size,
                                            GCancellable   *cancellable,
                                            GError             **error)

And then we probably want to allow passing -1 to get the behaviour
of gtk_icon_info_load() to avoid adding gtk_icon_info_load_with_cancellable()

> > We can't implement the cache using toggle references for 2 reasons:
> > a) GtkIconSize is a boxed, not an object
> > b) toggle references only work for a single user, thus they have
> >    to be reserved for bindings, at least bindable objects.
> > I propose to instead turn GtkIconInfo into a refcounted boxed object,
> > and then implement the caching logic for the case that the refcount
> > drops to one.
>
> I'm not sure this is enought, cache-wise. In many cases you'd get a
> GtkIconInfo, then get the pixbuf for that, save the pixbuf (e.g. in a
> widget) and unref the info. In fact, it seems unlikely that apps would
> keep the GtkIconInfo alive for long periods of time. It would be nice if
> we could get the GtkIconInfo cached until the last ref is dropped to the
> pixbuf.
>
> Of course, this is slightly harder, as GdkPixbuf is a public GObject
> where we can't use toggle references. We could however implement this
> with some help from the GdkPixbuf implementation. For instance, if we
> add a resurrect signal to GdkPixbuf and have the dispose()
> implementation emit this then the cache could connect to this and grab a
> ref (for some time) before finalization. (The dispose call must also
> detect that the object is ressurected and avoid chaining to dispose.)
>