Maybe use wxLua instead of Lua?

Posted by Shadowfyr on Sat 06 Jan 2007 12:20 AM — 3 posts, 18,274 views.

Shadowfyr USA Sat 06 Jan 2007 12:20 AM #0

I got things about half wrong when looking at this. The wxLua implimentation for windows *comes* with the dlls for wxWidgets, *however*, there is now .lua or other binding method to tie them into Lua5.1. Instead, it appears that you have to link against wxlua.dll?, which itself links against lua5.1.dll to get the main language elements. Its not possible to simply drop wxlua into the directory with Mushclient and have it work.

Now, the "good" thing about it is that, in theory, if wxlua was added/traded for the script engine for the client, the connect functions for events are part of the wxlua libraries, no need for luacom to be added. And the only line you should have to change in the code for their example on the main page is the first one:

frame = wx.wxFrame(wx.wxNull, wx.wxID_ANY, "wxLua Minimal Demo",
                   wx.wxDefaultPosition, wx.wxSize(450, 450),
                   wx.wxDEFAULT_FRAME_STYLE)

to

frame = wx.wxFrame(World.GetFrame, wx.wxID_ANY, "wxLua Minimal Demo",
                   wx.wxDefaultPosition, wx.wxSize(450, 450),
                   wx.wxDEFAULT_FRAME_STYLE)

This would expand what the client can do by a lot, since it would give access to all functions available through wxWidgets, including windows, buttons, images, etc. Basically, everything that at the moment is a pain in the rear to impliment with an external application (which is in turn a lot harder for people to program). My only real complaint is the sketchy documentation for it, which, while it gives examples, isn't 100% clear on just how the bits fit together. I guess you are supposed to look at the source code, which includes the source for an exe that impliments it. I presume its pretty much the same as the existing lua5.1.

Anyway, you might want to take a look at it and see if it is implimentable. It shouldn't assuming the way it ties in is the same, effect existing scripts, just extend what they are capable of. The only drawback I can see is that a significantly new release of Lua may not be immediately usable with wxlua (such as going to a lua5.2.dll, etc.).

http://wxlua.sourceforge.net/index.php

Nick Gammon Australia Forum Administrator Sat 06 Jan 2007 01:33 AM #1

It looks cool, but I can't help feeling that it will involve the "two event loops" problem.

MUSHclient already has an event loop, so I can't see how the correct events will go to any wxLua frames also.

Shadowfyr USA Sat 06 Jan 2007 09:16 PM #2

Umm. It would have to work, otherwise any and all script languages that use these sorts of things would fail. As I understand it, if something isn't explicitly trapped in your programs loop, it instead gets passed on to the OS, eventually the OS passes it to the object that it belongs to. That is what the "connect (event, function)" stuff does. It explicitly binds the event to the address of the function inside the script, so that unless you intentionally intercept the event and prevent it, the event automatically calls that entry address. Mind you, I have been wrong before, but I don't think, short of intentionally preventing it, you can stop a system like this from working. Your application isn't *actually* sending the event to the function, its more like:

Event happens->OS recieves->OS informs main application->if returned, OS informs subwindow/object->if returned, OS informs the sub-sub window/object->etc., until it either fails to find the function, the right function is found, or something else handles it and tells the OS to stop trying to find the correct owner.

But, people have successfully used LuaCOM and its connect function for events right? Or am I wrong there? If that works, then why should an integrated wx.connect be *less* possible than luacom's version? Wouldn't the previous one create the same conflict (or actually logically a worse one), if one existed?

Shouldn't be hard to try it out and see anyway.

As I said, in theory, the only lines that need to be changed in any of the samples to test it is the one for creating the main window. The one that uses wx.NULL as the first argument, instead of an existing frame. Using NULL *will* crash the client and engine. I tried it with Python. lol But, when I tried it we didn't have GetFrame to return an existing window, nor was I aware of the connect function for events (since I had bits of the details on how it all worked wrong). Now, I would say that the odds of it working is probably 90%, with the other 10% being maybe some code to make sure the engine is passed the un-trapped events from the client, so it has a chance to deal with them.

But, I don't think that is likely necessary. Your forgetting something. If I do:

myframe = wx.frame(world.getframe, ...)

myframe becomes a *child* of the main mushclient window. Since its a child of that window, any events not handled by the parent are passes in turn to all children, which *should* include the new window we just created. Events going the other direction are, I would assume, going to get handled correctly as well, since they are calling functions in Mushclients environment space, and I assume the engine is using that space for its own operation. After all, if it wasn't, the client would freeze in a script loop. Since both engine and new objects are in the event loop of the client already... the only issue is if the client accidently prevents them from going where they are supposed to, right?