[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua FLTK ?
- From: Jay Carlson <nop@...>
- Date: Mon, 1 Mar 2004 11:14:46 -0600 (CST)
On Mon, 1 Mar 2004, Juergen Fuhrmann wrote:
> > The problem is when to start running the GUI event loop, especially if
> > you want to keep your original console interactive...
> > Quoting the Lua FLTK manual:
> Hi, Jay,
> do you have any plans for FLTK & Lua 5 ? We made a definitive
> decision now to use FLTK for GUI, regardless if Lua5 FLTK will be
> available or not. I coded FLTK stuff in C++ (UI for OpenGL viewer
> widget), and it is _good_ . Unfortunately, I see no resources for
> hacking LuaFLTK5 by myself. If our project goes on we might try to
> hire someone, but this is only a vague idea for the time being.
I haven't been working on Lua FLTK mostly because I haven't been
working on the Agenda VR3 lately. I find it difficult to do a good
job on libraries I don't intend to use immediately. It's hard to do
good design without a) having use cases in your head and b) knowing
you're going to have to live with the API you've built for yourself. :-)
What version of FLTK are you targeting?
1.0 would be my default choice for personal projects, as it's what the
Agenda has. 1.1 would be in second place, as it's stable, released,
and plausible to port to the Agenda. A Lua binding to 1.0 could
easily support both though.
1.2 looks interesting, when it's released. 2.0 is useless to me
because it switched to floating point for coordinates, and that's just
too slow on platforms without FP hardware.
The two biggest problems I see in FLTK itself are:
The lack of a good text widget. This could be solved outside the core
by porting the Tk text widget.
No decent layout management. This can't be solved outside the core,
as Fl_Widget needs to have the notion of a "preferred size". This
depresses me, because I'm not going to maintain my own fork of FLTK.
Here's a general issue list for Lua FLTK:
1) Port support for "properties"/"attributes" to tolua 5, or figure
out how to do it with #define trickery. This allows you to have
widget.labelcolor = 5
get turned into
2) Figure out how to do that from Lua code too. There are a bunch of
places in the Lua FLTK 4 binding where it takes advantage of tolua
internals to intercept reads or writes to particular keys, translating
them to a less-convenient "raw" tolua binding.
3) Decide what to do about down casts. For example, you can get back
a list of child Widgets from a Group. But you don't want to wrap
these pointers as Widgets; you want to wrap them as their actual type,
like Button, or at least the closest superclass that you know about.
This has to be done in the tolua-generated code. RTTI would help
In tolua 4 this wasn't so bad, because if you still held a reference
to the Button, it would return the wrapped Button rather than creating
a new wrapper as a Widget. But that doesn't feel very safe. I
suspect this is still true in tolua 5.
4) Event loop. If Lua FLTK is only a loadable extension, it can't
provide the nice behavior of the flua executable for interaction and a
default Fl::run() call.
I would be happy to discuss this in detail with anybody who's working
on a Lua 5 binding, but I don't know if or when I would work on a Lua
5 binding myself. My "real work" has been quite demanding lately.