Re: gdk-pixbuf merge

[Federico Mena Quintero <federico helixcode com>]

>  One approach is to keep gdk-pixbuf basically as-is, and make GTK but
>  not GDK depend on it. Another is to make GDK depend on the gdk-pixbuf
>  base, and move the render_to_drawable code from gdk-pixbuf in to GDK.

Does it matter?

If you choose the latter, I guess the question just turns into whether
you want to make GdkPixbuf *the* representation for images in GTK+.  I
wouldn't mind that :-)

If you build a separate little library that only contains the
loading/scaling code, you could also create applications that
manipulate images but that do not depend on Gdk.  This may be useful
to some people.

>   - Logistical problem: we have to maintain the current gdk-pixbuf 
>     with the render functions included for some time. How do 
>     we organize the code to permit this? If only GTK depends on 
>     gdk-pixbuf, but gdk-pixbuf depends on GDK, how do we organize the 
>     source trees and releases?

I would like to have

	gtk+ - Main tree
		doc - Documentation [1]
		gdk-pixbuf - Loading and scaling functions
		gdk - pixbuf->drawable and drawable->pixbuf functions
			X - X-specific stuff for Gdk
			Win32 - Windows-specific stuff
			...
		gtk - Widgets

[1] The programmer's and API reference documentation should go here
and be distributed in the same tarball as the rest of GTK+.  It is
ridiculous to have a separate, unfinished documentation package.  The
gdk-pixbuf docs should go here as well.

>   - We need a widget to display a pixbuf. I think an option worth 
>     considering is to mutate GtkImage so that it can display a 
>     GdkImage, GdkPixmap, GdkPixbuf, or GtkIconSet. Then we have 
>     a single image-display widget, with the proper name, and 
>     it's even backward compatible (not that many people use GtkImage
>     anyway). GtkPixmap and GnomePixmap would become deprecated.

Who on earth creates GdkImages by hand and then wants to display them?
I think they should be hidden from the programmer.

Having a single widget to display pixbufs, pixmaps and icon sets could
be nice.  In any case, an icon set should be a collection of pixbufs
or pixmaps.

>  This will take some time to implement, so these decisions need to be
>  made _soon_.

Gdk-pixbuf, alas, is *not* finished.  Please see the gdk-pixbuf/TODO
list.  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.

	- The loaders really really *really* need better error
          reporting.  gdk_pixbuf_new_from_file() will happily return
          NULL if anything happens; this is useless for all but the
          most trivial programs.  And the progressive loaders happily
          g_error() out if they cannot allocate memory.

	  The progressive loaders should be able to recover from and
	  report the following conditions:  unknown data format
	  (i.e. a too-weird image format), invalid data (i.e. a
	  corrupted-but-known file), premature end of data, out of
	  memory, and maybe something else.

	  gdk_pixbuf_new_from_file() should report all of the above
	  plus a subset of the standard errno values for files.

	- The pixops scaling/compositing functions need better
          preconditions and sanity checks.

	- There are some remaining bugs in the pixops functions; I
          already reported the known issues to Owen.

	- Programmer's documentation is nonexistent.  The API
          reference is complete, though.  I do not want to release
          without the programmer's documentation.

Volunteers are very gladly accepted :-)

  Federico