Re: GTK+ v FLTK
- From: Havoc Pennington <hp redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: "M. Evans" <datafeed gmx net>, gsl <dev gsl openoffice org>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: GTK+ v FLTK
- Date: Wed, 23 Apr 2003 14:32:01 -0400
Hi,
I feel like I'm missing big parts of this thread. ;-)
On Wed, Apr 23, 2003 at 04:57:12PM +0100, Michael Meeks wrote:
> Hi Mark,
>
> On Tue, 2003-04-22 at 18:33, M. Evans wrote:
> > > In a word - no. Gtk+ provides a graphics device abstraction just like
> > > any other toolkit; that runs fine, even well on Win32.
> >
> > That wasn't brought into question. My question was how closely the
> > GTK+ abstraction layer, on any platform, resembles X11 API.
>
> Well; the best people to answer that are the gtk+ hackers; although
> quite why that should be an issue I don't really see.
>
GDK (the abstraction layer) has some resemblance to the X11 API (just
as the abstraction layer for many toolkits is similar to the win32
API). However, it is a thick and opaque wrapper that changes X11
semantics in lots of ways. I remember someone saying that the X11
backend and win32 backend are about the same size in terms of lines of
code, which seems to indicate that the abstraction layer requires
about as much work to implement on either. If it was just an Xlib
wrapper, you would expect the X11 backend to be much smaller than the
other backends.
Don't get me wrong, I think there is some work involved to get GTK+
100% up to speed on Windows, such as folding in the Windows emulation
theme upstream. However, that work is very feasible and encouraged,
and much less than the work to do a custom toolkit (where you lose all
your synergies with the broader operating system platform).
> > Cross-posting was impolite. Maybe we should bring the FLTK folks in
> > here too! They would say that GTK+ is Wrong (tm). Then we could have a
> > real Flame War! You get the idea.
>
> I would imagine that we would all benefit from a more informed
> discussion; I imagine you under-estimate the FLTK team.
>
Consulting toolkit experts when deciding on a toolkit is very
appropriate. I tried to give unbiased advice based on experiences such
as Mozilla, AbiWord, Eclipse, etc. that I've looked at or been
involved with.
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.
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.
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.
Good luck,
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]