Re: gdk-pixbuf to GTK

[Federico Mena Quintero <federico helixcode com>]

>  At GUADEC we talked about moving gdk-pixbuf to be a GTK dependency, or
>  possibly included in the GTK+ package. This lets us use GdkPixbuf
>  instead of GdkPixmap for various GTK APIs (such as CList), and also
>  removes the need for GnomePixmap.

You would need to add a way to set a GtkPixmap to contain a GdkPixbuf,
and add support for the fancy color adjustments for
prelight/insensitive states.

Basically you would have to take the code from GnomePixmap in
gnome-libs HEAD and put it in GtkPixmap.  Which would be really nice,
since the current GtkPixmap is basically useless.

>  Basically to do this we need to remove the libart
>  dependency. gdk-pixbuf doesn't depend on libart in any real way (it
>  uses an enumeration or two, and the ArtPixbuf struct).
>  
>  So, the questions are:
>  
>   - any objections or comments on the general concept?
>  
>   - specifically how would we like to remove the libart dependency?
>  
>     my suggestion is a struct just like ArtPixbuf but with a 
>     different name that comes with gdk-pixbuf, thus we avoid breaking
>     current apps using gdk-pixbuf

I don't think removing the Libart dependency is the right thing to
do.  It creates gratuitous code duplication, and I would like to keep
track of Libart features as they appear (i.e. other color spaces or
bit depths, clipping images to vector paths or vice-versa, etc.).

In an ideal world, things would be like this:

	- ArtPixBuf would be called ArtPixbuf.  I don't like the Shift
          key, and I don't like studly caps either.

	- ArtPixbuf would have reference counting of its own, and
          struct GdkPixbuf would not exist.  To use technical
          language, Libart's memory management just blows.
          Potentially-shared structures such as vector paths and
          pixbufs are not refcounted.  Also, it defines art_alloc() as
          plain malloc(), but it never checks for NULL return values.

	- To keep Libart small and simple, we would provide a separate
          library with loaders for ArtPixbufs, with the whole
          GdkPixbufLoader progressive machinery and all that.  Libart
          would then just provide the basic ArtPixbuf structure with
          reference counting and some simple constructors similar to
          what GdkPixbuf has right now.  I guess the loaders could
          live inside GTK+, and it would also depend on
          lib{png,jpeg,tiff} and friends.

	- Owen's supercalifragilistic scaling/compositing functions
          would be in Libart.

	- The pixbuf->drawable and drawable->pixbuf functions would be
          in Gdk.  The former would still be nice wrappers for Raph's
          sexy-in-a-morbid-kind-of-way GdkRGB functions and the latter
          would be Michael's morbid-in-a-sexy-kind-of-way functions.

	- For bonus brownie points, GdkRGB would be able to render to
          whatever visual/colormap the given drawable happens to be in.

And GTK+/Gdk would simply depend on Libart, and Libart would be
distributed as a separate library (gnome-libs would also depend on it,
of course).  In the long run, we will want this anyways.

  Federico