Re: [gsl-dev] GTK+ v FLTK

[Havoc Pennington <hp redhat com>]

On Wed, Apr 23, 2003 at 09:00:17PM +0100, Sander Vesik wrote: 
> The problem here are users of certain not insignificant platforms - like say MacOSX
> - that emand 100% correct look meaning the use of native widgets. 

Wrapper toolkit doesn't give you that. It doesn't let you use many
more complex platform features, unless you have a way to do ad hoc
"punch through" to platform-specific code. You can't properly support
a platform using least-common-denominator features only.

Note also that using the native widgets *is not* enough. You have to
follow the platform UI guidelines - what accelerators to use, how much
spacing to put where, when to use bold labels, button order,
etc. Abstracting all that is basically impossible to get right.  And
indeed Eclipse (using SWT) gets this very wrong and would be very hard
to fix.

This is why 100% correct platform integration requires writing to
multiple APIs. Neither an emulating nor a wrapper toolkit gives you
100% proper platform look-and-feel.

If you want a single API though, you have to pick one of these
compromises. I believe that the toolkit community has repeatedly
demonstrated that the right compromise is the emulating toolkit; all
three major toolkits use that approach because it works. Indeed the
Java community explicitly switched from AWT to Swing, so they
empirically tried out both ways before deciding.
 
> Well... Abiword is also very much a small program, so number of
> platforms x rewrite amount is actually small. Its not a
> particularily scalable approach.

I don't agree; there is a structure to the way AbiWord does this, and
it has been applied repeatedly across the many pieces of AbiWord.
There's no reason to believe that the percentage won't remain the same
as AbiWord gets larger - it's remained the same for quite some time
and AbiWord has been growing. AbiWord is not as huge as OpenOffice,
but neither is it tiny.

The approach AbiWord uses was driven by the original AbiSource guys
who were I believe veterans of a web browser project (Spyglass or
something?) that also used it. They had a clear proven strategy for
cross-platform and I think it's a good one, if you want to be
uncompromising.

> > The idea of a "wrapper" or "multi-platform" toolkit is tempting but
> > it's a pipe dream IMO. It isn't even possible for many of the more
> > complex widgets - SWT for example uses emulation for tree and text
> > controls, because wrapping those doesn't work out well.
> > 
> 
> I'm not sure to what extent this is a problem - no toolkit provides
> anything even resembling what you need as the main 'work' area in
> writer, calc or draw. POssibly a sufficently generic table widget
> could be used in some of teh database dialogs and simlar

The main "work" area is going to be a custom widget, as it also is in
AbiWord, Gnumeric, gpdf, whatever. How to implement that is pretty
much orthogonal to the toolkit you use.

If toolkits contained a "word processor" widget and a "spreadsheet"
widget writing those apps would be pretty easy. ;-) 

So this needs to be separated out. The toolkit decision should be
about how you want to do menubars and dialogs. The drawing API
decision should be orthogonal, and based on how you want to implement
your large core-functionality custom widgets.
 
If you entangle these two issues you'll probably end up with a mess.

> For me the largest problem with gtk+ is all the lower layers that you end 
> up pulling in and then essentially not using and that there is no layer 
> above gtk+ to which some of the feature creep could land - which coupled with
> increasing number of increasingly comlpex dialogs likes set to be a non-trivial
> overhead. 

I'm not sure what you mean here. (I'm pretty sure GTK code size is a
drop in the OO.o bucket, if that's the issue ;-))

Havoc