Re: gdk-pixbuf to GTK
- From: dg50 daimlerchrysler com
- To: "Shawn T . Amundson" <amundson eventloop com>
- Cc: gtk-devel-list redhat com
- Subject: Re: gdk-pixbuf to GTK
- Date: Thu, 23 Mar 2000 19:26:24 -0500
On Thu, Mar 23, 2000 at 05:43:35PM -0500, dg50@daimlerchrysler.com wrote:
>> Having just gone through the pain of helping a friend build Enlightement
>> for Solaris (which required IMlib, which in turn required 5 bazillion
>> twisty little image libraries, all with different build procedures)
might I
>> suggest bringing in the required tiff/jpeg/png code into the main GTK
>> codebase somehow?
>>
>> As in grabbing the main GTK tarball should include this code, and the
main
>> GTK configure should configure it.
> We shouldn't have to maintain tiff/jpeg/png code - someone else already
> does this.
*shouldn't* have to, no argument there. But you cannot depend on having
either:
1) The appropriate libraries/headers, (especially on embedded systems) or
2) The appropriate _versions_ of the libraries/headers
available on a given machine.
Not to mention that I'd bet dollars to donuts that the interfaces to what
amounts to the same kind of data (pixmaps) are completely different in all
three libraries. You're going to have to encapsulate them anyway.
> We also shouldn't muck around installing things from the GTK+
> tarball that don't belong there.
If by this you mean including the current lib[foo] tarballs in with the GTK
tarballs, you're absolutely correct. Trying to interface the GTK
configure/make process with these alien libraries would not only be
painful, but would be difficult to make reliable across multiple platforms
and multiple compilers/cross compilers.
That's not what I meant. Instead, I'm talking about extracting the relevent
code from the image format libraries, and writing native GTK functions that
implement them.
Yes, that means every time one of these libs changes that someone has to
roll the changes into GTK code - but these libraries don't change all that
often. And the convienince of grabbing GTK and knowing all the appropriate
bits are included is a big win.
> Most people who compile from source probably already have these things
installed
> because other things do use them.
You cannot assume that - I've just been through that experience on Solaris.
And what about Win32 or embedded systems where the libraries don't exist or
won't compile cleanly as provided by the library maintainers?
DG
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]