Re: gdk-pixbuf merge

[Havoc Pennington <hp redhat com>]

Federico Mena Quintero <federico@helixcode.com> writes: 
> 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 :-)
> 

This is the motivation for including gdk-pixbuf, I believe.  The new
tree widget, GtkImage, IconSet, etc. should use gdk-pixbuf instead of
pixmaps.

> 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.
>

Several people have requested it.

> >   - 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.
>

No one creates them, that's why I'm saying GtkImage should become "a
widget that displays images" instead of "a widget that displays
GdkImage."
 
However we'll need to support GdkImage for backward compatibility reasons.

> 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.
>

That's what an icon set is, have a look at gtkiconset.[hc] in my branch.
 
> Gdk-pixbuf, alas, is *not* finished.  Please see the gdk-pixbuf/TODO
> list.

Unfortunately we are releasing it in 2 weeks dude! Have you informed
Jacob (release coordinator) that it isn't finished? Or will it be
finished Real Soon?

>  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.

> 	- 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.
> 

I think this should be ignored for April GNOME. We can do it in the
GTK version, maybe using GException. Also I think it should be done
using _with_error() variants of the functions, both to avoid breaking
a bunch of apps, and to make things more convenient in the general
case where you don't want detailed error info.

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

Not a release-stopping issue, it can be added with binary/source
compat retained.

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

Owen said he's working on this.

> 	- 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). 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 :-)
> 

I'll do the last_unref stuff this weekend if you want (though it is
probably a 5-line patch you will rewrite anyway, so maybe you just
want to do it yourself), and Owen is on the pixops bugs. Other than
that we should postpone all these issues until post-April-GNOME IMHO.
None of them are very good reasons to delay the April GNOME release.

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).

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?

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.

Havoc