Re: [gsl-dev] GTK+ v FLTK

[Havoc Pennington <hp redhat com>]

On Tue, Apr 22, 2003 at 09:49:21PM +0100, Sander Vesik wrote:
>  --- Havoc Pennington <hp redhat com> wrote: > Hi,
> > 
> > On gtk-devel-list we have no context - is this a serious conversation
> > about changing OO.o toolkit, or just people speculating? ;-)
> > 
> 
> This is serious discussion in the context of 'toolkit 2' - see
> http://gsl.openoffice.org/servlets/ProjectDocumentList?dcID=848&action=download
>

Interesting, this is very exciting. That document distinguishes:

     - Native platform GUI toolkit
        Toolkit recommended by the platform vendor for GUI applications.

     - Multi-platform GUI toolkit
        GUI toolkit attempts to build on the higher-level widgets/controls of
        the platform toolkit.

     - Cross-platform GUI toolkit
        Toolkit that is built on the lowest-level graphical capabilities of
        the platform.

     - Platform-aware GUI toolkit
        Cross-platform GUI toolkit that uses platform-sensitive themes.
 
I call "cross-platform GUI toolkit" an "emulating toolkit."  GTK+, Qt,
and Swing (the three toolkits I would consider
modern/interesting/general-purpose/full-featured/widely-deployed on
UNIX) are all emulating toolkits, and there's a reason for that.

They are also all platform-aware, at least to some extent, and can
trivially be made more so. See 
http://www.gnomedesktop.com/article.php?sid=1031&mode=thread&order=0&thold=0
http://gtk-wimp.sourceforge.net/

"multi-platform" toolkits (I call these "wrapper toolkits") such as
AWT, SWT, wxWindows, etc. are basically kind of bad - they have
unreliable semantics, and are packed with hacks that negatively impact
UI and performance and robustness. They also leave you with a very
limited least-common-denominator API. Going this route for OpenOffice
would IMHO be a *giant* mistake. Platform-aware emulating toolkits are
Better (tm) as demonstrated by many years of experience, wrapper
toolkits are a nightmare of breakage.

If you want to use native widgets rather than emulating them, the best
approach I've seen is that taken by AbiWord; which is essentially to
rewrite the UI for every platform in a controlled way that still
leaves nearly all code cross-platform, using subclassing. I don't know
what their current %age of cross-platform code is but it used to be
very good. AbiWord approach produces both ideal platform integration
and reasonably maintainable code.

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.

There are a couple exceptions, such as the file and print dialogs,
that are easy to wrap and are generally wrapped even in emulating
kits.


The funny thing is that apps using emulating kits all want to start
using wrapper kits, and apps using wrapper kits all want to start
using emulating kits, and the reason is that they both are compromises
to save on programming time; only the AbiWord-style approach produces
100% correct results from a user perspective. However, if you're going
to compromise to save programming time, the emulating kit is pretty
convincingly the right way to go.
 
> There are valid reasons to change irregardless of syncing up with any of 
> the 'in the wild' toolkits. I'm not sure VCL is missing much as things 
> stand from the a11y and i18n angles as things stand, actually, i think its much
> better than say qt ATM 

FWIW, I've never seen a custom app-specific toolkit that didn't suck a
lot more than GTK/Qt/Swing. (Not to single out VCL, there's also XUL
and SWT for example.) This is perhaps the largest reason to use one of
the three major toolkits. There are also just thousands upon thousands
of details that the major toolkits get right and app toolkits don't.

I'd pretty much have to go in a corner and cry for a week if
OpenOffice went to the trouble to change toolkits and didn't use 
one of the three big ones.

A nice thing about these is that they are both the "native platform
toolkit" for UNIX, and also cross-platform.

If GTK+ changes are needed to make it work for OpenOffice I think we'd
be fully open to that.

btw, another bit of advice: rather than porting lots of GUI code to
yet more different GUI code, I'd definitely be looking at a
load-a-resource-file system as in libglade or the Qt UI builder stuff;
that will save you more time and be a more important choice than *any*
other aspect - including which toolkit you use and what that toolkit
is like. So whether a toolkit has a GUI builder should definitely 
be a critical evaluation criterion.

Glade makes the AbiWord approach dramatically easier since most
toolkit usage in an office app is dialogs, you can use glade for all
those, and so you really only have per-platform resource files, not
much per-platform code.

So summary: 1) don't fall for the lure of wrapper toolkits, 2) please,
please, begging you to use one of the 3 major toolkits, 3) consider
AbiWord approach rather than a single toolkit on all platforms, and 4)
use a GUI builder. That's the current best practice I would say.

Havoc