Re: [gsl-dev] GTK+ v FLTK

[Sander Vesik <Sander Vesik Sun COM>]

On Sun, 27 Apr 2003, Havoc Pennington wrote:

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

Heh. I'm one of the people around who doesn't particularily mind using
OOo with its toolkit as is and mozilla with the pinball theme (+gnome2 
with high contrrast inverse) so I guess I don't presonaly see the
native L&F problem as long as things "just work" inside one program at a
time.

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

Agreed.

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

I guess a required goal is primarily to be able to arrive somewhere -
where that somewhere sounds horribly like 'everybody is happy' ;-) 

That everybody might be a slightly cropped at the edges everybody - though
things like MacOSX and running without java are not really croppable (and
I dare say thats quite not only my opinion), and the proposed thing most
be implementable. Implementability isn't something you can really
compromise on either, at least if you are in the 'writing code and
delivering the stuff' camp.

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

I believe people have looked at the 'vcl using gtk theme engine/drawing
api' in the past, I believe one could do it now, and not wait for
toolkit2. It would give you a correctly theming and drawing but not really
gtk looking (except for small details like widget looks) app.

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

Some of vcl api and widget hiearchy will (i believe) be changing in any
scenario. Having a front-end that is gtk+2 (or at least visualy
non-distinguisable for gtk+2 in trivial ways) is something I'd personaly
actually liek to see happen at some point in the not too distant future,
even if this is for the wrong reasons. But I also very much want to see
OpenOffice.org 2.0 come out in a reasonable timeframe.
 
> Havoc
> 

	Sander

	Humans love to categorize and organize things. We break up time into
	hours, days and years. Everything has to have a name, a history, an
	understanding of it's origins and must be indexed somewhere on Google.