Re: [gsl-dev] GTK+ v FLTK

[Sander Vesik <sander_traveling yahoo co uk>]

 --- Havoc Pennington <hp redhat com> wrote: > 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.
> 

The problem here are users of certain not insignificant platforms - like say MacOSX
- that emand 100% correct look meaning the use of native widgets. 

> 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.
> 

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.

> 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

> 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.
> 

I believe these live a couple of layers above toolkit in OOo - you also get cases
like the non-webdav awareness in the windows file open dialog and so on.

> 
> 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.
> 

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. 

> 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 

__________________________________________________
Yahoo! Plus
For a better Internet experience
http://www.yahoo.co.uk/btoffer