Re: gdk_imlib questions



> remember Imlib isnt gdk_imlib - imlib is 2 libraries with 2 api's
> almost the samethat allow both gdk level and Xlib level apps to share
> the same functionality.

> Maintinence wise I keep them both at Xlib level sicne Imlib has Xlib
> and gdk front-ends. having either significantly different will mean
> nightmares for maintinence. Beleive it or not the Xlib API to Imlib
> is being used by many apps and is attractive to other people like
> the KDE people.

Would it be better then to split off gdk_imlib from the "plain" Imlib,
and develop it in the direction of really living up to its name, using
just GDK. The windowing/graphics API functionality that gdk_imlib
needs that is not doable with GDK currently could be added to GDK,
just a few new gdk_image_ and gdk_pixmap_ functions, probably.

(I will have to this anyway if/when porting gdk_imlib to Windows,
sigh, but it would be nice if it would be official.)

> ->  - Is there a reason why gdk_imlib shouldn't use g_malloc and friends?
> 
> same as below - parallelism for maintinence. I don't see why it should
> either. malloc is portable - standard ansi-c. it's a moot point.

But why does all of GTk+ and GIMP (dunno about GNOME) then use
g_malloc etc? Presumably there is some sound reasoning behind these
wrappers to malloc and free? 

--tml



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]