Re: GTK+ v FLTK

[Sander Vesik <sander_traveling yahoo co uk>]

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

I personaly very much hope this is not a major 'lets rewrite half the codebase' 
project as that will mean first non-working and then later just merely really 
screwed up UI state for teh codebase for months and months which would imho be 
quite damaging. 

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

Well, the API of VCL2 would probably be at least initialy much more flexible
than that of a "generic" toolkit like AWT/SWT and probably not need to freeze 
before significant amount of testing on the present 3.5 alive (X, windows x 1.5, 
macosx) gui platforms has happened. In fact I believe vcl presently lives
above the "compat guarenteed" treshhold and hence is somewhat fuid. I'd hope this
chnages though or that there is at least some stable interface in the future
for component's UI's.

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

Some of the evlove part may not be simple, and some of teh punch-through will
be needed in any case for "proper" support of mocosx and winxp.

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

If you need to deliver essentialy the same functionality from the app on all
platforms, then you will need to do something about these widgets (provided 
your UI uses them).

> 
> Havoc 

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