Re: gdk-pixbuf merge

[Tim Janik <timj gtk org>]

On 28 Apr 2000, Havoc Pennington wrote:

> >  Some remaining issues are:
> > 
> > 	- The last_unref handler mechanism needs to be improved as per
> >           Tim's suggestions.  GdkPixbufAnimation needs to have the
> >           same mechanism.
> > 
> 
> This looks trivial.

no too trivial if you want to turn it into a GObject later.
i'd like to get feedback from owen on my last _unref mail,
i.e. if he prefers his get/put_cache versions (and in the
version i interpreted his suggestion) or no.
then i can review your implemenation of that and see how that
correlates with resurrectable GtkObjects (which we'll also have
for 1.4) and what functions we really want in GObject to support
this kind of functionality.

> > 	- Programmer's documentation is nonexistent.  The API
> >           reference is complete, though.  I do not want to release
> >           without the programmer's documentation.
> > 
> 
> We are not holding up April GNOME over this. We can add it after the
> release.
> 
> One thing missing from your list: GdkPixbuf needs user_data with
> destroy notification for language bindings (which means it might as
> well be a GObject).

user_data is always bad, if someone says "user_data" for objects,
i immediately think "they are eitehr doing something wrong, or they
want to use GData".
pixbuf already provides a destroy_fn destroy notification fucntion
in its API (gdk_pixbuf_new_from_data) which is inherently broken as
it is being called from pixbuf_finalize and actually passes the pixbuf
with a reference count of 1. so this is another, supposedly widely
used API point that'll have to change. i'm not sure delaying that
untill after APRIL GNOME is a good idea.

> However I would say it's OK to ignore this for
> April GNOME, and just make it a GObject subclass once it goes in GTK.
> 
> > Volunteers are very gladly accepted :-)
> > 

> Also, none of these issues are show-stoppers for merging gdk-pixbuf
> into the gtk+ tree soon. Since you're in favor of making gdk-pixbuf
> ship in the gtk+ tarball as a subdirectory, I do think that is the
> best route. The image loaders will still be a separate lib people can
> use without using GTK (people will whine about it being packaged with
> GTK, but they will get over it).

"...about the image loaders _not_ being packaged together with gtk"
you mean? just release the loader lib together with gtk and put it
into the same ftp directory, that reduces the burden to a reasonable
minimum.

> Do you want to include gdk-pixbuf in gtk+ as a virtual module, keeping
> gdk-pixbuf with its own AC_CONFIG_SUBDIR configure script, or do you
> want to just make it part of the gtk+ package in the same way gdk is?

especially since the image loaders are going to be a seperate library,
i don't see what having an extra pixbuf configure script would buy us.
so merging any remaining checks gdk-pixbuf's configure.in script makes
with gtk's configure.in is probably the best route.

> I want to do the gdk-pixbuf merge as soon as April GNOME goes out the
> door, as a rough timeframe estimate. So I'd like to have consensus
> among Owen/Tim/Federico on how to do it within a couple weeks, if
> possible. Otherwise we won't have time to do the work.

well, i at least seem to agree with federico on the major issues, so
let the omen^H^H^H^Howen speak! ;)

> 
> Havoc
> 

---
ciaoTJ