There are some interesting points below. Everyone likes a Friday GUI toolkit
discussion, right? <wink>
ka
···
---
From: Stephan Deibel
Subject: GUI toolkits discussion from gtk-devel-list
This seems relevant and seems to have some well thought out points about
GUI toolkit choices in general. Note that this isn't an unbiased
viewpoint (if such a thing exists) because Havoc is one of the original
GTK+ developers. But his point about trouble with wrapper toolkits does
mesh somewhat with feedback I've gotten about using wxWindows across
multiple platforms.
This would argue for Qt which emulates native look instead of wrapping
native widgets. Or, actually, GTK+ 2.x w/ different themes looks more
promising all the time as a way to approximate native look and feel in a
cross-platform app (also by emulation not wrapping).
Note that I don't myself have experience with *complex* cross-platform
apps using wxWindows/wxPython. This is where I'm continually looking
to get more info.
Chandler is definately something to watch. I asked John Anderson today
and they seem happy so far with wxPython and cited the worst problem being
bugs on OS X. But I believe they've also been concentrating on internals
up to now, so for me the jury is still out.
- Stephan
------------------------------
Message: 6
Date: Tue, 22 Apr 2003 20:20:23 -0400
From: Havoc Pennington <hp@redhat.com>
To: Sander Vesik <sander_traveling@yahoo.co.uk>
Cc: gsl <dev@gsl.openoffice.org>,
Gtk Hackers <gtk-devel-list@gnome.org>
Subject: Re: [gsl-dev] GTK+ v FLTK
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=downl
oad
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