On 1/30/07, Patrick Elliott <[EMAIL PROTECTED]> wrote:
> I am using a client to play MUDs which recently went withLua as its "main"
> scripting system. This works nicely, but has a fatal flaw imho, which is
> shared by all other script systems in this context. wxLua would correct this
> flaw, by adding the capacity to develop new GUI elements within the context
This would be easy to do with wxLua.
> So, I would like to be able to convince the developer to switch to wxLua
> instead. But, several questions need answering:
>
> 1. Threading. This already causes some issues. While coprocedures can be
> used and suspended/resumed to "fake" true threading, no additional threading
> systems are available. One reason being to avoid the script going out of
> sync with the data incoming to it. You don't want some complex process
> handling something to deal with line 50, while the client is displaying line
> 120, and a third script is altering the contents of line 114, which must,
> after that, be redisplayed in the correct order... The fear is obvious. How
> do events effect the situtation in cases where the script system and client
> are in the same thread space, and anything the script does may "suspend" the
> client until its finished?
If they're in the same thread then only one of them is active, events
will only be sent when your functions are idle. You cannot have "while
1 do ... end" since you don't allow the event loop to run unless you
call wxApp::Pending() and Dispatch(). I believe there was some
messages on wxlua-users about this too?
> Put simply, none of us have a real clear understanding of just how the heck
> the event system works, or what effect that could have on the client.
The event system is the GUI main loop. All GUI calls MUST be made in
the main thread since that's what the underlying system, MSW, GTK,
OSX, supports. You can create wxThreads in wxLua (untested, but there
shouldn't be any reason why they wouldn't work) and use wxPostEvent to
queue events back to the main thread where you can then call GUI
functions.
You can also "fake" threads using EVT_IDLE, these are idle events that
are sent when the event queue is emptied and you can use
wxIdleEvent::RequestMore (IIRC) to keep it going.
> 2. We don't have a clue how the event system works at all in this context.
> Does the client, which is written in MFC, need to have some adjustment made
> for the event generators and sinks to even work within wxLua? If so, how? If
> not, then why not?
Please see #1 and #3.
> 3. Now, this is the one that is the cause of some of the angst about the
> above issues. How does wxLua deal with cases where *it* isn't the initial
> GUI host? Put simply, the client has its own windows. There is a function
> added a while back, so that other applications could get better data on the
> client windows position, etc., called "GetFrame". This returns a handle to
> the main window of the client. This means that, in theory, making a new
> window is as simple as telling the frame creation function in wxLua to use
> "that" handle as the parent, not NULL. However, this could potentially have
> an impact on just how events get handled.
See wx-users mailing list for messages about using wxWidgets as a
plugin for photoshop. I believe there is code about how to do this,
perhaps on the Wiki? I know it can be done in C++ and there's no
reason why it wouldn't work with the lua bindings since wxLua is
really only translating from lua to C to wxWidgets C++ and back. We
may have to wrap the HNDWND however or just treat it as a void*
pointer.
> Now, my impression is that the new frame and its objects should become
> children of the main client window. This should mean that MFC will
> automatically pass any messages for those objects "to" the correct child
> window, and that event generated by those should correctly call the
> functions in wxLua that they have been "connected" to. But I admit complete
> ignorance on the subject with respect to *if* this is true, not to mention
> how to fix the problem if its not. Obviously, most examples that the wxlua
> system comes with "assume" that the client has no window, and that wxLua
> itself will create the master window. This doesn't lend any information one
> way or the other as to what the result will be in any case this isn't the
> way things are set up.
See the photoshop plugin discussions.
> Thanks for any help you can provide on these issues. The client I use is
> quite good, but needing to rely on "external" extensions to provide new GUI
> elements adds a level of complication that makes it unlikely for most people
> to even try developing such extensions. It adds a what is a nasty learning
> curve and huge cost to doing so, or, in the case of free compilers, which
> lack the additional tools to make development easy, it creates an "insane"
> learning curve, which 99% of the clients users are never going to over come,
> and which even most of those that already have the skill and tools, don't
> want to waste on it. wxLua could potentially solve a huge problem if it will
> work as I hope it does in such an implimentation.
The way I see it is, you'll create your own plugin module, a DLL I
suppose with a bit of C++ code as described in the photoshop plugin
wx-users/wx-dev message threads, create a wxLuaState (eg. a lua_State)
and then throw code at it.
Some simple examples of the C++ side are in
wxLua/modules/luamodule
wxLua/apps/wxluafreeze
wxLua/apps/wxlua
Hope this helps,
John Labenski
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
