Re: gdk-pixbuf 0.11.0 changes

[Havoc Pennington <hp redhat com>]

"Terry 'Mongoose' Hendrix II" <darkskye mindspring com> writes: 
> 
> I have no plans to port this to GTK+ 2.0, until it's in debian.

Well it probably won't be in Debian until it's released, at which
point it will be too late. ;-)

Adding features to libraries requires some planning ahead, you can't
get instant gratification in the stable branch because stable libs get
locked down.

>  I'm
> writing this to manage textures in nautilus, so I guess I'll just hold
> onto it until it's been tested more. 

Don't worry about testing, the idea of getting it in the library is to
get testing. If we can get it in GTK 1.3.x then it will go through the
GTK beta cycle.

> I wonder how you're supposed to
> support headerless formats denoted by file extention?  It seems like gdk
> frowns on nonheadered formats - which I can understand, but you can to
> byte checks compared to fseek(END) to make sure your dims fit the data
> -- so at worse you see random data rendered as an image.

GTK 2 has gdk_pixbuf_loader_new_with_type() where you "force" a type
on the image. There's already one headerless format in gdk-pixbuf,
wbmp I think. To load these you have to force the type. An app might
get the type from the MIME system, especially Nautilus would do this.

It might be nice to autoguess the type from filename in
gdk_pixbuf_new_from_file(), the change there would go in
_gdk_pixbuf_get_module in gdk-pixbuf-io.c, if all the format_check
functions fail then fall back to filename extension. However this
semantic change can definitely only happen in the unstable (GTK 1.3.x)
version of gdk-pixbuf.

Havoc