Re: Many GUI Toolkits, no "Best Option" [was wxWindows vs. FLTK]

[Sean Middleditch <elanthis@...>]

On Tue, 2003-02-11 at 23:24, Antonio Scuri wrote:

<snip/>

>    GTK is in C. It is primarily for X-Windows, Win32 is an external 
> project, and no Mac port that I know. Also no native controls.
> 
>    FLTK has all the ports, but no native controls.
> 
>    WxWindows is complete with native controls and much more. But they put 
> everything together, it is a lot more than an interface toolkit. If there 
> were several small libraries will be far the best option.
> 
>    So, there is no "Best Option". Depends on the application, the 
> development team, the development main platform, and so on.

This "native controls" argument is completely stupid.  Even if you have
"buttons that look alike," that does nothing for feel or tie-in to a
desktop.  Good Mac apps look nothing like good Windows apps, and the
same goes for GNOME or KDE apps (why people think Motif is a good GUI is
beyond me - it's a crap user experience, and if you don't care about
user experience, what's the point of worrying about what the fricking
buttons *look* like?).

You're much better off worrying about more relevant criteria, for
example how portable (which you are), speed/size, etc.

And, simply as another point of view (unrelated to the toolkit chosen),
calling Motif native-UNIX is pretty bad.  ~,^  That toolkit should die,
and soon.  It's out-dated, doesn't work well with modern desktop
environments (HP-UX and Solaris are switching to GNOME, iirc, Linux/BSD
already use mostly KDE or GNOME, they are *real* GUI environment, and
tying into their look *and* feel would be a much brighter move for new
applications, instead of the UI nightmare of old Motif UNIX apps).

That's one point up for using WxWindows, since not only does it use an
actually modern toolkit under UNIX, it gives a choice between GTK and Qt
(or will, when Qt port is done).  Of course, cross-platform UI's always
suck anyways, since 99% of the time they always feel and act like
Windows apps, even tho that is *completely* incorrect UI-wise on a Mac,
or even GNOME.  I know for a fact in GNOME, it's painfully obvious when
even other GTK apps don't follow the HIG or closely use GNOME
technologies - they do not fit in cleanly at all.  (For example, the
GIMP, even tho the CVS version follows the HIG, the lack of use of
GNOME-VFS or GConf stands out rather clearly in many situations.)  Point
of this whole paragraph: "native widgets" is a completely pointless
criteria.  ^,^

</spiel>

>    Maybe the "Best Option" is to develop an independent Lua GUI toolkit 
> that could be implemented using FLTK, GTK, IUP or any other toolkit.

This actually might be a decent option - a very lite-weight and clean
API that builds on any number of toolkits.  The simpler the API the
better, as well, since a call like "CreateAlertDialog(...)" is a lot
more likely to produce the correct platform output (icon usage,
spacing/margins, button ordering, etc.) than an API that requires the
programmer to hand-construct even simple dialogs.  This is one of my
beefs with GTK (programmers have to do a lot of extraneous work to get
the effects that should be default, as per the GNOME HIG), but that's
another and wholly unrelated story.. ;-)

> 
> scuri
>