Re: GTK+ v FLTK

[Havoc Pennington <hp redhat com>]

On Wed, Apr 23, 2003 at 08:42:27PM +0100, Sander Vesik wrote: 
> But in this particular case, half a million lines of code that needs to be
> maintained - and vcl is actually lighter and doesn't have qute the same 
> genericness requirements and some things that would go into gtk+ live in higher
> layers - compares unfavouranbly against the estimated two million lines of code
> needing to be chnaged if the toolkit or its wrapping are not sufficently similar,
> should it have to stand on its own. 

If you do a VCL2 that's much more similar to VCL1 than any of the
existing toolkits, because it's too hard to port to a standard
toolkit, then I buy that. It makes sense to me. I've long accepted
that it would be too much work to port OO.o to a new toolkit given
current resources.

If you do a VCL2 that's so different from VCL1 you have to do a lot of
porting work, seems like a wheel reinvention that misses a big
opportunity to improve the UNIX desktop platform as an overall
solution. Since that porting work could have been spent on getting a
standard toolkit adjusted to meet your needs and creating a
big-picture synergy. The value of that synergy over the next 10 years
is hard to underestimate.

If you do a VCL2 that's a wrapper toolkit (that uses GTK, etc. as
substrate), I think you will regret it; ad-hoc flexible wrapping a la
AbiWord works OK, but AWT/SWT sort of stuff with a frozen API just
doesn't, IMHO.  Wrappers end up being more work with worse results
than just writing the GUI once per platform would be (assuming you do
it in a sane, controlled way as AbiWord does).

If you do wrapping, it needs to be possible to a) change the API as
the underlying platforms evolve, so that it's possible to implement
the semantics well on all platforms and b) punch through the wrapper
occasionally to get things to work the last 10% of the way.

In large part the AWT/SWT flaw is that they've frozen the API such
that they can't fix the fact that their API doesn't map to the
toolkits they wrap. But part of the problem is also that it's
impossible to map GTK+ and Win32 to the same API in many cases, and
platform-specific code simply has to be written in order to use native
widgets. This is the "least common denominator" problem that emulating
toolkits try to avoid. GTK+/Qt/Swing simply could not have anything
close to their feature set if they were wrappers of native widgets.

wxWindows has various API features along the lines of b) - API that
only works on one of the platforms. Which I think helps.

Havoc