lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, 4 Sep 2002, Juergen Fuhrmann wrote:

> >  Wed, 4 Sep 2002 13:40:28 -0700
> >  David <> wrote:
> >
> >  Juergen wrote:
> >
> >  > a) Lua-FLTK ...
> >  > b) LuaJava ...
> >
> >
> Of course,  Java is not  _really_ lean. But  it seems to  be available
> everywhere we want  to go, i.e.  UNIX workstations  & perhaps NT. This
> means that porting would be lean somehow. and, as I said, we can count
> on lots of students already aquainted to JAVA.
> But  before this  becomes off-topic  --  my real  favourite indeed  is
> Lua-FLTK,  and if we  would get  Lua-5, tolua,  Jay Carlson's  tolua -
> property patch (necessary for lua-fltk), FLTK, and fluid-lua (fluid is
> the GUI designer of FLTK) together in a reliable fashion, we certainly
> would have something.

I have the start of a parser for Fluid's ".fl" files written in Lua.
If you're interested, I can finish it up enough for casual use.

What I'd *really* like is an Fltk UI builder written in Lua itself.
Some of the effort I went through in the Lua-Fltk documentation was
toward that end---all the properties and methods (and their docs) of
the Lua-Fltk classes are easily available in Lua format.

The biggest technical failing of Lua-Fltk is not getting down-casts
right.  Say you have a Container, and you want to iterate through its
child widgets.  You're going to get back toLua objects of type Widget,
not their actual type.  Unless of course you have a live reference
elsewhere to that child Widget, in which case the magic of userdata
merging will give you back the reference you hold.  I expect this
could be fixed during the 5.0 upgrade pretty easily, now that I
understand the problem.

The biggest missing Lua-Fltk feature is free drawing.  There should be
a way for Lua apps to draw arbitrary stuff and respond to mouse events
freely.  I expect the right thing is a little like a Tk canvas: a
Canvas widget type that has a an ordered list of graphic objects to
draw during repaint, along with some event delivery logic.  I started
on this and got bogged down in C++ details---I am not a very strong
C++ programmer.

The biggest missing Fltk feature is a decent text widget.  The text
widgets available are not as good as the Tk text widget.  (This is a
problem with every widget set of course---the Tk text widget is one of
the best ever designed.)  It might be possible to steal the code from
Tk without too many changes.  That's what I concluded last year, at

The biggest missing element in the Fltk design is advertising
preferred widget sizes.  Without this, it's not possible to build a
packing layout manager.  Should be fixed in Fltk 2.0, but there's no
release year, let alone release date...