Re: [gsl-dev] GTK+ v FLTK

[Havoc Pennington <hp redhat com>]

On Sun, Apr 27, 2003 at 05:59:33AM +0100, Sander Vesik wrote:
>  --- Havoc Pennington <hp redhat com> wrote: 
> > 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.
> > 
> 
> I believe some of that is needed and in the plans for macosx/winxp support 
> at any rate. This may be as simple/complex as supporting a platform spellchecker if
> there is a suitable one, or doing menu merging (both ways - system components in
> native menus and macos style annoying finder menu).

If you want the fully native L&F some people are advocating, you have
to do a substantial amount of this punchthrough, not just a little
bit.

Note, I haven't made an argument on *whether* 100% native L&F is the
right way to decide the tradeoff. All I'm saying is thousands of
programmers have spent many years failing to escape this tradeoff in
the past, and native platforms are only getting wider in scope. ;-)

There are fundamentally impossible-to-solve problems here. You have to
either do more platform specific work to get 100% native L&F, or you
have to sacrifice the L&F nativeness by 10-15% in order to do less
work. Make this decision consciously and up-front and the code will
end up less confused.

Anyway, the horse is dead. ;-)

> Yes - but this is not about writing a new Office suite from scratch while 
> trying to see if there are salvageable pieces in the old, or at least thats
> not the impression I have got so far.

Rewriting 6 million lines of code from scratch is clearly insanity, so
any path forward needs a plan for doing it gradually rather than all
at once.

If a required goal is to keep a VCL-like API, then I'd imagine you're
best off evolving VCL into a better emulating toolkit (e.g. using
platform-native theme engines and such). 

Conceivably it would be useful to use a native UNIX toolkit just for a
toplevel window widget and some other infrastructure below VCL, to get
some of the low-level details taken care of more robustly instead of
using Xlib directly. But most of the widgets would remain
VCL. Retarget-VCL-to-toolkit would also simplify calling the toolkit's
theme rendering functions. Note that Mozilla works this way (XUL built
on the GTK core instead of Xlib, but not using GTK widgets).

If you wanted to move away from the VCL-like API, the way I'd imagine
doing that is to refactor VCL to be able to coexist with your new
framework, then rework the code a dialog at a time as time permits.

Havoc