Re: Lua FLTK ?

[Jay Carlson <nop@...>]

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
something like

  widget.labelcolor = 5

get turned into

    Lua:  widget:labelcolor(5)
    C++:  widget->labelcolor(5)

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
here.

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.

Jay