[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua 5.0 and tolua/SWIG ?
- From: Jay Carlson <nop@...>
- Date: Wed, 4 Sep 2002 14:36:39 -0500 (CDT)
On Wed, 4 Sep 2002, Juergen Fuhrmann wrote:
> > Wed, 4 Sep 2002 13:40:28 -0700
> > David <email@example.com> 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
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...