Re: almost ported.....

[raster redhat com]

On 13 Jan, Owen Taylor shouted:
->  
->  > On 12 Jan, Federico Mena shouted:
->  > ->  >  Some may not be excited to know this... other may...
->  > ->  
->  > ->  I am :-)
->  > 
->  > kewl. :)
->  > 
->  > ->  >  1. do you want imlbi as a separate library that is "gdk in style" or in
->  > ->  >  gdk. if its in gdk its easy.. the gdk_iit can call gdk_imlib_init();.
->  > ->  >  if ity isnt thsi must be done by the app itself.
->  > ->  
->  > ->  I'd put it inside gdk_init().  The idea is to have good image support
->  > ->  directly in Gdk.
->  > 
->  > fair enuf.. then i'll have to merge my code wiht gdk and hackthe
->  > configure stuff to make it go in...
->  
->  Hold on a second. I'm willing to forget that I said anything about
->  this not going into GDK before GTK 1.0, but I am _not_ going to
->  stand it being put in with "hacked" configure support.

hack means modify or change... and thats exactly what is required.

->  The configure code needs to:
->  
->    1) Autodetect the presence of the libraries you need. If it
->       doesn't find them, it should disable the portions of the
->       libraries it doesn't find.

well someone do thsi for me.. last time (about 3 months afgo) i used
configure to auto detect for libs (looking for known symbols in them)
it worked on my machine and faild on many other peolpes... for no
apparent reason. I thus do not trust configure's lib detection. if you
can make this work on multiple platforms and multipl boxes.. fine.

->  
->    2) It should probably take --with-jpeg-include= --with-jpeg-lib=
->       (I don't really like it, but people seem to object to 
->       setting the environment variables)
->  
->  If you would rather not handle this, I could probably do it. (Having
->  done some of the similar stuff for the GIMP).
->  
->  There is another problem though, in that after GTK is linked with
->  these libraries, other programs linked against GTK have to know which
->  libraries GTK needs. With image libraries this becomes variable (It
->  already is, if GTK is compiled with XInput support, but that doesn't
->  affect many people.) This is another reason I would like to hold
->  off on integrating this stuff into the GTK distribution.

I know. Linux does support linking libraries. i could hand-load .so's in
imlib easily (there's a function for it.. i forget the name.. i'll
find it if need be).. but only in linux. This doesn't i believe work
under any other os.

->  > ->  >  i have a bit of internal "cleaning" to be done in imlib to make it use
->  > ->  >  the gdk color allocing routines etc.. but that isnt hard...
->  > ->  
->  > ->  Umm, do you mean gdk_color_alloc() and friends, or are you using the
->  > ->  GdkColorContext?
->  > 
->  > i'm not sure how EXACTLY the colro conext stuff works right now.. but
->  > i'm goign to look into it, along wiht code cleanups and some work on
->  > macor fucntions.... then later maybe xpm loading code (native to imlib).
->  > 
->  > ->  I'm asking because, as I have said before, I'd like all of Gdk/Gtk to
->  > ->  use the GdkColorContext instead of directly allocating colors.  If
->  > ->  you are using plain gdk_color_aloc(), I don't think it will be hard to
->  > ->  change.
->  > 
->  > currently I use XAllocColor.. :) imlib is still pur Xlib at its core...
->  > its likely to stay this way for one good reason.. i can use shared
->  > pixmaps... :) alhto this pretty useless.. xsrevre shave a fundamental
->  > design flaw preventing their widespread use.. but i hope that might get
->  > fixed so my code will instantly work.... :)
->  
->  This doesn't seem relevant to XAllocColor. But, as long as you export
->  your pixmaps to GDK as GdkPixmaps (and they are properly refcounted)
->  I don't think you need to go through gdk_pixmap_new, etc. In GDK,
->  it's OK to use X functions directly.

no.. i wrote my own "foreing_pixmpa_to_gdk_pixmap" function by copying
& pasting the pixmap creation function form gdk, modifying it to accept
different params, etc.

->  I'd say, if the only reason you want it in GDK (for now) is the
->  initialization call, you might as well do a separate release.
->  That way, people can play around with it, without patching their
->  GTK sources. 

that is what i was planning unless others wanted it integrated now. i'm
quite happy having my programs calling one extra init function if they
want touse imlib... 

->  Until the configuration stuff is working, it shouldn't be in the CVS
->  repository. (Or it shouldn't be in the CVS repository until we can be
->  sure that we get the configuration stuff working before the next
->  release.) GTK may still be pre-release, but there are a number of
->  applications out there using it.

I know. I'm not touching the CVS stuff for a long time.. i'm keeping
tarballs and everyhting to myself.. if i blow my own desktop up with my
own code.. at least i know where to fix it.. :) once i've done some
cleaning i'll happily make tarballs available for people to look at,
play with, use, hack, debug, patch etc.

->  Regards,
->                                          Owen
->  
->  (Yes, I'm being a prig about this, but GTK is too close to 1.0
->  to do "two steps forward, one step back".)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/