Well. I haven't "yet" tried it, but in theory there is nothing preventing the use of the wxLua library being used to create true windows, with Mushclient as the master, and scripting all the needed stuff to make them work any way you want. The only big issue is that currently such a window might create serious lag if its own code isn't threaded correctly (i.e. coprocessed or what ever it was called). Something like a icon bar would be fairly trivial, something like a scrolling text window... I am not so sure about. But, the fact is no one has tried it. Everyone has instead relied on more complicated, less client specific, external application to handle all of it, which, while it works, isn't as flexible, since each application has to be designed to a specific task, not re-scripted to what ever you want to use it for.
The only real alternative would be quite silly. Design your own application that just provides a basic window framework, such as Mushclient doesn't provide directly itself, then tack on Lua, wxLua, wxWidgets, LuaCOM and what ever else is needed, to give the user a way to "design" what they want in it. But, that is doing the same bloody thing that you should be able to do with Mushclient already, for want of anyone testing to see if it will work in the first place.
In theory, the way to create a window for wxLua is:
frame = wx.frame(World.GetFrame, wx.wxID_ANY, "wxLua")
Its redesigning the rest to work with Mushclient that is an issue. As an example:
http://wxlua.sourceforge.net/wxLua/samples/editor.wx.lua
is a sample file for an editor in Lua that uses wxLua. With modifications it is probably possible to make it work "with" Mushclient as a mail editor or what ever, but... the key factor is making sure that "wx.wxNULL" is replaced with "World.GetFrame", since the first tells it that you are running a stand alone application with a "top level" window. If you try to create a top level window inside a script running in another top level, such as Mushclient's own frame, it will, at best, crash both the script and client. Otherwise, the only major issues are to add some extra toolbar items, menus, or whatever, so that you can "send" the contents to through Mushclient, or if using this as a text window, you might strip out all the menus, status bars, etc., adjust it to use a color supporting text field type and add code to let you send stuff to it from Mushclient instead.
The basic framework for a simple window should be fairly trivial. Been too busy with other stuff recently to fiddle with it though, and the biggest issue, due to the way these people developed wxWidgets and wxLua, is just getting all the damn .dlls you need in the right places for everything to work right. Straight installs rely on the old DOS autoexec.bat at startup to set "PATH". If that isn't set, manually, the libraries don't know where to find each other. This is why Lua5.dll must be in the Mushclient folder to work, though placing it in Windows/System would probably solve the problem too. With wxLua and wxWidgets, you are looking at them scattered through 2-3 different places, with no registry entry to find them, and no copies any place like Windows/System, where the OS can find them for you... Very annoying. Though, I think wxPython was even worse... lol |
![[Go to top]](/images/gototop.gif){kind=small}
top