[10179] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: gdk_imlib questions
daemon@ATHENA.MIT.EDU (Tor Lillqvist)
Mon Nov 16 14:32:39 1998
To: gtk-list@redhat.com
Date: Mon, 16 Nov 1998 21:31:22 +0200 (EET)
From: tml@iki.fi (Tor Lillqvist)
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
> 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
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
