Subject: Re: image support (was Re: Core-dump during startup on AIX-4.3.2)
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 02 2000 - 15:05:12 CST
At 02:15 PM 3/2/00 -0600, Justin Bradford wrote:
>I recommend we use gdk-pixbuf as a model. Basically, we do the simple
>formats (ie. BMP) ourselves and link to libs for the hard ones (ie. JPEG).
>
>libjpeg, libungif, libtiff, etc, should be pretty portable. The ungif
>source might small enough to just copy, too...
>
>It's not much code and it avoids large lib dependencies.
Yeah, I like this approach, too:
- it's what we're doing already with libpng,
- it allows us to control the footprint of each library, and
- having worked with libjpeg in the past I know it's eminently portable.
>However, one other suggestion: can we make these image importers
>subclassable to platform specific implementations? For instance, with the
>gnome version, I'm certain we'd like to just swap this code out for the
>actual gdk-pixbuf implementation.
That's a very good idea, and should definitely be a design constraint for
whatever switching mechanism we come up with.
Essentially, we'd have an XP factory API which produces a converter which
can convert a blob of image data in some specific format to PNG. The source
trees we release would have XP implementations for every file format we
support, but somehow (hand wave, hand wave) each platform would be able to
override the factory to generate simpler stubs which just drive existing
platform-specific image conversion services. The makefiles for that
platform would decide which of the standard libraries to build and/or link,
as needed, to create a single full set of converters.
>I imagine there are similar services on
>other platforms. We don't have to do it right away, of course, but I'd
>like the ability to be there for later extension.
Yep. IIRC, BeOS has a plugin system for image handlers already, so that
version might be able to get by with stubs for all the converters.
bottom line
-----------
I like the direction this is heading, and would love to see some proposed
APIs for handling the switching mechanism, so we can hash out that design on
this list.
Once we know how these converters are:
- selected (mime types? suffixes? sniffers?),
- invoked (handed a file? pushed a buffer? allowed to pull data?), and
- used (from clipboard, importers, insert image dialog)
then the remaining work to start integrating code for individual converters
should be fairly straightforward.
Paul
This archive was generated by hypermail 2b25 : Thu Mar 02 2000 - 14:59:45 CST