Re: wxLua at Sourceforge

[John Labenski <jlabenski@...>]

On 11/27/05, Chris Marrin <chris@marrin.com> wrote:
> > Can you point to (in your repository) what you had to do to get it to
> > work (in 5.0 for now) so we can duplicate it?
>
> I am working in 5.1, so I don't have a 5.0 solution. And, while I can
> use require to load my module, it is not really wxLua. I wrap it in my
> own C++ wrapper so I can do the thread spawning and such. The result
> does not support the wxLua mechanism for creating dialogs, you do
> something more like this:
>
>      require "WxGUI"
>      local GUI = WxGUI {
>          url = "mygui.xrc"
>          widgets = {
>              WxGUI.Widget {
>                  name = "ID_BUTTON"
>                  action = function(self)
>                      print("You pressed ", self:getWidget():GetLabel())
>                  end
>              }
>          }
>      }

You've written a wrapper around wxLua it seems, I'll have to diff the
sources. Is this the stuff in wxLua/Module?

> This will load the .xrc file, bring up the dialog and then wait for
> button presses. The dialog's event loop runs in a separate thread, where
> the wxApp object was constructed. As I mentioned, this still runs the
> Lua code in the main thread because I added a callback mechanism to
> wxLua. When you create a WxGUI.Widget object, it creates the widget (a
> wxButton in this case) and then attaches a native C++ callback to it.
> When the event fires, this callback sends a message to the main thread,
> which processes it and calls the Lua function to print the button.

So instead of using sockets, as the wxLua app does, you use messages
between threads. This sounds great.

> You don't use all the LoadDialog mechanism of wxLua at all. But it does
> use all the other facilities of wxLua. For instance, calling
> Widget:getWidget() returns the wxLua wrapper around the wxButton,
> allowing you to call all of its methods, like the GetLabel() method I
> call above.

? I'll have to see the source.

> All of this is tied into Emma's object model. In this case it's just
> used to wrap Lua interfaces around the C++ classes of WxGUI and Widget.
> But Emma also provides an implicit event loop, which is why yoy don't
> see any call to a wxApp.run() sort of call above. That is the one piece
> that makes this not ready for prime-time. As soon as I fix that, you
> will add a:
>
>      WxGUI:run()
>
> call to the end of the program and it will run from a stock Lua interpreter.
>
> So, is this part of wxLua, or something different? All this code can be
> seen at:
>
>      http://emma3d.org/svn/emma

The current structure of wxLua is very modular, we build different
libraries for wxLua itself, the debug code, and the socket code. Your
thread code could just go into it's own lib, or if it's very small
just add it.  If anything needs to be made virtual, no problem.

> It is all Open Source, so I would be happy to make it part of wxLua. Or
> maybe we can just add my callback mechanism and a couple of bug fixes
> and then I could use wxLua from sourceforge and build my WxGUI package
> on top of it.

I think you'll like the new wxLua, it's got a new class wxLuaState
that pulls together the lua_State and the wxLuaStateVariables and
hopefully makes it a bit easier to understand. It's a little rough
now, since I just added it, but the API is basicly either use
wxLuaInterpreter as you did before or if you want to do stuff at a
little lower level use the wxLuaState.

> Let me know if there is any interest and I can send patches for my
> changes to wxLua. the callback mechanism is a very minor change. I
> basically added a class:
>
>      class wxLuaNativeCallback {
>      public:
>          virtual void execute(wxEvent* event)=0;
>      };
>
> and a new variant of ConnectEvent() which sets up the callback to be
> called. You simply subclass wxLuaNativeCallback, implement execute() and
> then call ConnectEvent. All the existing functionality is left intact.
> This just gives a new way to use it.

Ok, sounds simple enough. I'll diff your code and see what sense I can
make of it. The wxLua at SF is structurally different than the
original wxLua, but conceptually it works the same way.

Regards,
    John Labenski