At 07:46 PM 4/21/01 +0200, Paolo Molaro wrote:
>On 04/19/01 Paul Rohr wrote:
>> >Gdk-Pixbuf depends only on GLib (talking about version 2.0 here)
>> >and there shouldn't be any portability problems.
>> 
>> Good.  Do you know how much of Glib it needs?  IIRC, Dom's gotten a subset 
>> ported already for all our supported platforms.  
>
>Well, my advice is: use the real thing! :-)
>Note that I was talking about gdk-pixbuf included in Gtk 2.0: that
>requires the full glib because it uses the signal system for
>incremental loading...
>The current (old) gdk-pixbuf links to Gtk (for basically the same reason).

Paolo,

Thanks.  However, I'm unclear on one thing here.  

We've been wrestling with the issue of which XP interfaces to use for 
image-handling.  There are currently a number of half-formed "flyweight API" 
proposals on the table:

1.  Use raw libraries, such as libjpeg.  In this case our XP API would be 
implemented by stub classes that call those libraries directly.  For 
example, this is what Hub did recently with the libjpeg patch that started 
this thread. 

2.  Use system-specific services, such as the BeOS and QNX image munging 
APIs.  In this case, the XP API would be implemented by platform-specific 
code to call those system services.  This is what Thomas Fletcher has been 
advocating, for obvious (and good) reasons.  

3.  Some hybrid of 1 and 2.  I've been pointing out that we should be able 
to spec an API which advocates of both 1 and 2 would be happy with.  That 
way, each platform's maintainer could pick and choose the solution that 
makes sense for them, but the XP code wouldn't care because the details are 
hidden behind that API.  

4.  Have ImageMagick *be* our XP API for image-handling.  I'm one of the 
folks who've been most reluctant to add this dependency, mostly because IM 
feels like overkill, since it hasn't been tuned for the kinds of lightweight 
usage we need.  However, I understand that Leonard's expressed a willingness 
to help strip it down to a more appropriate miniIM, which would make this 
alternative more palatable.  

5.  Use gdk-pixbuf instead. 

I'm not clear on what *you* mean by #5.  Some folks seem to believe that 
something like gdk-pixbuf could be ported to become a lighter-weight 
solution than miniIM for all our platforms.  If I read Dom correctly, he's 
been proposing to only use gdk-pixbuf on GTK/GNOME.  

For you, is #5 more like #4 or more like #2?  

Paul

Reply via email to