Re: [gsl-dev] GTK+ v FLTK

[Michael Meeks <michael ximian com>]

Hi Mark,

On Fri, 2003-04-18 at 03:39, M. Evans wrote:
> GTK+ is a fine toolkit, but isn't it still heavily based on X11
> graphics, even in the native ports - i.e. aren't the native GTK+ ports
> effectively ports of Xlib?

	In a word - no. Gtk+ provides a graphics device abstraction just like
any other toolkit; that runs fine, even well on Win32.

	Gtk+ is IMHO a viable choice for OO.o, from a licensing perspective
it's ideal; from a maintenance perspective it is actively maintained
etc. How best to C++ wrap it is a slightly open question, there are
several attempts: Inti, Gtk-- - I would imagine the demands of a
UNO-ized API would introduce the need for a 3rd custom wrapping.

	The problems with using gtk+ are almost solely it's thread support;
then again any existing toolkit (apart perhaps from the Java one & VCL)
has very weak threading support.

...

> I'm not saying that FLTK is the way to go (I don't think so at all),
> but only that in a contest between GTK+ and FLTK, I would give the nod
> to FLTK for the future needs of OO.

	When considering a new toolkit for OO.o, I would imagine that (for the
team) things such as: support (Sun has to support gtk+ already),
strategically encouraging fewer graphical toolkits by re-using commonly
used ones, maturity, deployment, API/ABI stability, etc. etc. might be
more telling than some speculative design advantage.

	Although as Dan says gtk+2.0 still needs work porting it to Mac/OS's
various flavours; doing this would IMHO be very useful work for 'the
community', and would immediately provide a large raft of other useful
apps on Mac/OS X.

	My feeling is that on most cost/benefit analysis charts, pragmatically,
and in net developer cost switching to using gtk+ instead of VCL is the
best move long term.

	But then I don't fully understand your threading requirements; Thorsten
- can you re-explain them ?

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot