Re: almost ported.....

[Owen Taylor <owt1 cornell edu>]

> 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.

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.

  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 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.

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. 

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.

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".)