Re: Inlining pixbufs

[Tim Janik <timj gtk org>]

On 28 Jun 2000, Federico Mena Quintero wrote:

> Havoc Pennington <hp@redhat.com> writes:
> 
> > > Also, if you feel like playing with GdkPixbuf stuff, could you please
> > > implement Tim's idea for the last_unref handler?  We do need that
> > > before gdk-pixbuf can go 1.0, and Nautilus needs it.
> > 
> > Hmm, I think this would actually be implemented on GObject now, in GTK
> > head.
> 
> OK.  I just wonder if it is absolutely indispensable that we have the
> same last_unref functionality in the current GdkPixbuf.  I think what
> we have right now is enough for the icon cache in Nautilus, but I'm
> not sure.  Tim, what do you think?

GdkPixbuf inherits from GObject now right?
GObject doesn't have a literal "last_unref" function, instead GtkObject's
former ->shutdown() method got moved into it.
so i think the ideal thing to do is, as soon as GSignal is implemented,
GdkPixbuf should introduce a signal (say ::cache_notify) that will be
emitted from a static gdk_pixbuf_shutdown() implementation.
if people then want to cache certain pixbufs, they can connect a
handler there and re-reference the pixbuf to enter the cache.
at a later point, when they want to get rid of the cache contents,
they can unconnect the handler and unref the pixbuf.

for an object, this seems like the cleanest solution to me, and we
get rid of the current last_unref() API crack ;)

for the Gtk programmers reading this, forget about doing weird things in
->shutdown(), it's not a signal, and it is really meant as a private method
to be overriden by types _directly_ inheriting from GObject and not for
doing wierd puzzeling at GtkLabel or similar levels.

> (I'd prefer not to change the API yet again at this point, but whatever).

well, getting rid of it is changing i guess ;)

> 
>   Federico
> 

---
ciaoTJ