lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] wrote:
> Hi, Claus!
> At the 18th of march you wrote:
> For what it's worth, I'm fiddling with a Lua-gui system. Currently using a
> binding to the FLTK widget set ( ), but trying to keep the
> underlying toolkit easily interchangable with something else.
> FLTK fits Lua extremely well, however, being compact, simple, modular, and
> cross-platform to a reasonable extent. A full Lua Wish-like shell - with
> everything statically linked - compiles to well below 400kB.
> The idea is to produce a full Lua IDE, including a Delphi-like RAD tool -
> ideally written entirely in Lua.  The whole thing should run on all (sort
> of) X-nix and WinDos platforms.
> There will be a web-page for this in a couple of weeks - to  be announced.
>  Participation welcome.
> I would be interested in you GUI-developement - not only for Lua. Is there
> something established yet?
> Martin

I thought that my 0.02$, while unsolicited, might be of interest.
I was very excited by fltk (nee FL) when I first came across it.
I agree it is a great fit for Lua.  In fact I think that the kind
of role it can provide is possibly most valuable when paired with 
a language like Lua.  But I feel that it is my duty to point out
something about it that many may dislike.  It was ultimately why
I stopped using it.  

The root of the problem is that in a fltk program there is only
one system defined window.  All other widget-like things are
in fact analogous to gadgets, for those familiar with Xt/Motif. 
They are all drawn one hundred percent with the graphics library
of the underlying system.

This is in one sense a VERY good thing.  It means that a fltk program
is _very_ light on resources.  So light that most can quite 
compfortably be run remotely across a _very_ slow connection.  I 
have run a simple program across a 14.4 modem.

The most serious downside is that (at least when I used it) that
it does not handle geometry very good at the extreme.  It has
very nice strut/spring system similar to other quality toolkits
and supports easy setup of a sensible resizable layout of widgets.
However when a widgets boundary gets too small for its contents,
the contents are not clipped.  For instance when a static (in
windows terms) or a label (in Qt terms), or XmLabel (in motif)
gets too small/narrow, the text gets written outside the boundaries
of the widget.  The other drawback is that widgets bear no resemblance
in appearance to native analogous widgets on the platform (not a 
big deal in X, but quite serious on win).

fltk has evolved since I used it.  Maintanence has moved to a consortium
away from it's central single developer maintenance since I used it.
It is possible that it has improved greatly.

All the best,