Re: GTK+ v FLTK

[Sander Vesik <sander_traveling yahoo co uk>]

 --- Havoc Pennington <hp redhat com> wrote: > Hi,
> 
> I feel like I'm missing big parts of this thread. ;-) 
> 

I think all messages in the thread from a certain point have been cc:-d to both the
dev gsl and gtk-devel-list

[snip]

> 
> The GTK+ team won't be offended at all if you don't use GTK+. However,
> I would personally be sad if you don't use one of Qt, GTK+, or Swing,
> as those three are in a different class from something like FLTK, and
> definitely in a different class from Yet Another Custom Toolkit.
> 

It is very unlikely it will be Qt unless somebody comes up with a LGPL 
or similar licenced version. 

> Those three are the only ones I think we can expect to be actively,
> robustly moved forward by the general community, and widely-used in
> desktop apps, among other things. They are the only three involved in
> taking advantage of new specs and features in X11 and from
> http://www.freedesktop.org for example, and the only three that you
> can theme to make all three look the same.
> 
> Every extra toolkit used by a major application is definitely a
> negative drain and a problem for the free software desktop platform,
> whether shipped by Red Hat, Sun, or Debian.
> 
> We (= UNIX-based desktop community) currently have XUL, VCL, WINE,
> Swing, GTK+, and Qt that I feel we need to care about.  The plan is to
> stop worrying about XUL by moving to Galeon or Epiphany or Konqueror
> or whatever, and to improve WINE to integrate better, perhaps linking
> it to one of the other toolkits for theme purposes. VCL is the area
> where a plan has been lacking that I know of, though I don't follow
> OO.o closely. 
> 
> So I'd hate to see the VCL issue replaced by a some-other-toolkit
> issue - I'd want to see OO.o hop to one of the toolkits that's already
> in the list, so we can get this list shorter. Or if OO.o can't be
> moved to one of those toolkits, improving VCL itself to do better
> platform emulation of one of the other toolkits would be good, and
> having VCL more actively track X and freedesktop.org features would be
> good.
> 

VCL being replaced by VCL2 aka 'toolkit 2' is one of the options. As no other
project is presently using VCL (for reasons of lacking documentation and some 
warts) this would not add additional pressure to the ecosystem of toolkits.

> 
> The fact is that maintaining a modern toolkit is a very, very major
> project. There's definitely some pain to using an existing toolkit
> rather than one custom-designed for a given app, but there are also
> big wins.
> 
> Consider this: every toolkit is about half a million lines of code
> that has to be maintained and more or less kept in sync with the other
> toolkits in the list. Every time you drop half a million lines of
> redundant code, that is a Good Thing (tm). Thus my comment that
> missing this opportunity is Wrong (tm). I hope I wasn't missing any
> necessary smileys after that comment.

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. 

> 
> Good luck,
> Havoc
> 


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