On Nov 15, 2007 10:34 PM, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]> wrote: > > Some background info about this project is found here: > > > > * http://www.mail-archive.com/gtk-devel-list@gnome.org/msg06472.html > > * http://live.gnome.org/GtkCairoIntegration > > * http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6 > > > > In short, GdkPixbuf has some big problems which are hard to solve, so > > we need a new image library which is more compatible with Cairo. > > CairoIO is my attempt at creating such a library. The library is not a > > reimplementation of GdkPixbuf, it only wraps it to provide a > > cairoified front end to all the image loading functionality. > > > > Currently it consists of nothing more than a executable specification > > written in Python and unit tests. The intention is to first create a > > rock-solid, future-proof interface that solves all architectural > > problems GdkPixbuf has. So lets have some nice discussion about it! > > The things I've found really bad with GdkPixbuf and which I think > > CairoIO can solve are listed in "Targeted GdkPixbuf Problems" in the > > /ref/cairoio.py file. In particular I was not happy with how > > PixbufAnimations work so I've tried to make them better. > > > > Checkout using: > > > > svn co svn.gnome.org/svn/cairoio/trunk cairoio > > > > The implementation is in /ref/cairoio.py which also contain lots of > > documentation. I know the name "CairoIO" might not be so nice, but it > > is only seven characters. Maybe someone can think of a better name? > > > > Feedback welcome! > > 1) I am wondering if it should integrate with the upcoming libgio? Ie, take > a GFile instead of a filename in function args..? Or maybe going entirely > G{Input,Output}Stream based? That would obsolete a few of the methods in the > API.
That may be a good idea. > 2) I see that you do not have any methods to match GdkPixbuf.get_has_alfa > and a handful other methods on GdkPixbuf. Is the reason documented somewhere > or am I missing something obvious? It is documented now. :) CairoIO merely (de)serializes images and doesn't concern itself with the pixel data. So: surface = cairoio.load('foobar.png') if surface.get_format() in (cairo.FORMAT_ARGB32,): is equivalent with: pixbuf = gdk.pixbuf_new_from_file('foobar.png') if pixbuf.get_has_alpha(): Cairo currently only supports one alpha format which is FORMAT_ARGB32 (FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in the future. > 3) Why is there a load_xpm()? This function is for loading inline xpm data and works exactly the same as gdk_pixbuf_new_from_xpm_data(). The name is now load_xpm_data() to make that clear. > 4) I gather that the load*() family functions replace the constructors of > GDkPixbuf. > 4.1) How exactly would you map the load_frames() method with the keyword > arguments? Not sure I understand? Do you mean the arguments with default values? > 4.2) Why do I have to call load_frames() to request the image size on > construction of the surface? Just load() would space me the linked list for > normal images. What do you mean? cairoio.load() only returns a single cairo.ImageSurface. cairoio.load_frames() is supposed to be the full-featured general purpose method that works in all situations, such as when you want to load thumbnails in Nautilus for example. > 4.3 (Assuming gio based) If we are in stream terminology s/load/read is > probably more in line > > 5) All load_*() family functions returns a SurfaceInfo, but load() returns a > Surface... A bit odd maybe. The reason is that cairoio.load() is the convenience function which covers 95% of the use cases. So that function should be as simple as possible because you are almost never interested in the image files options. > I am really exited about the idea about joggling cairo surfaces around over > G{In,Out}putStreams, but the idea may be bonkers, I have not read the GIO > api much, not do I understand the finer details of cairo surfaces. That's a really cool idea and I'll definitely look into it as soon as GIO becomes a little more stable. -- mvh Björn _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list