Really? Too much to justify the gain? See, I don't entirely agree with that. Sure, you can use Mushclient now with WINE, but there are some minor limitations. If you also want to use a custom GUI element, like a mapper, you may run into **major** limits that make it effectively impossible. The WX libraries are cross platform, so its not impossible to a) have way more portability to start with and b) even possibly at some point replace the MFC with wx, thus making the application itself completely portable. (Mind you, I am not sure how the license for wx works or if its "practical" to do that. If its some version of GPL that doesn't allow the main application to be closed source...)
And frankly, how the heck else do you manage it? Supply every person that downloads Mushclient with a copy of GCC or WMing and a book on C++ programming? Right now its simply not practical for a casual coder to design ***anything*** to work with Mushclient. I can tell you right now, there are a half dozen ideas I would implement tomorrow *if* some way to do this existed that didn't rely on writing something in a completely different language and compiling it, or creating some lame wrapper for a program or dll I want to use, just because I can't use event sinks at all right now. The problem effects nearly everything we do with this client. You can't even open a web page without wasting script time constantly looking to *see* if the page finished loading in IE, because you can't simply have it "tell you" its done directly. Music players are crippled by the need to constantly ask what song it playing, instead of being told it changed to something new, then looking "once" to find out. Office applications, graphics application, etc. Anything the *pre-exists* and supplies a means to talk to it is crippled because of this when used from inside scripts. Stuff you code yourself.. Less so, but its still absurd that you have to call callplugin or some similar Mushclient function, passing it data on what happened, because you can't simply have the "what happened" call the script needed directly.
Anything you want to do right now requires far more than the basic knowledge of scripting and some simple examples the average user has access to. By comparison, wxLua, or even Python, you could teach someone the basics of creating a window with a button on it in five minutes. I would call that a HUGE advantage. And frankly, I suspect its ignorance that is making the actual problem seem insurmountable or so complicated that its not practical to try.
I don't know near enough about it, but I have read bits and pieces on event sinks, handlers, etc. And by my estimation, which I admit could be wrong, the changes needed are probably little more than overriding a single function in the MFC interface with a new function, which itself would simply do little more than:
function blah (){
if event.name contains "Lua"
call wxLua.eventhandler(event)
else
call me::original_function;
}
In other words, you redirect the events "temporarilly" to something that can figure out that they belong to the script system, pass those that do to it, and any that don't you simply pass "back" to the original MFC event handling function. This of course assumes that such a system exists. If not, then the event source *knows* where the script function is "supposed" to be, so I would assume that part of the event fired would "include" the location of the sink its "supposed" to go to. All that would need to happen is waking the script engine up, calling the address (possibly after verifying it still existed), then continuing on from there.
Now, its been like 4-5 years since I saw an example of anyone doing this, so it could be more complex than I think, but not by the huge chasm of difficulty everyone seems to think it would be. All you are doing is creating an event intercept, without disrupting the existing event sinks. Doing so, from what I remember, is quite trivial. The only question is, "Do we need such a thing in the first place?", and if that intercept needs to handle the function call or just pass things along to the right event handler. By comparison Nick has done stuff just in the last 3-4 updates that make such a change look as simple to manage as successfully filling a glass with water.
I suspect the answer lies in asking the question the right way, in the right place. Problem is, I am notoriously bad at asking the right question the first time, let alone figuring out where the right place really is to ask it. Worse, most places that deal with these things have a notoriously bad habit of linear thinking when it comes to how they code "everything" with it. It literally wouldn't occur to 99.9% of them that one might even *try* to code part of a program in something "other" than wxLua itself. The other 0.1%... problem never imagined trying to intergrate it into and existing GUI. I have chased my tail before over some things like this, only to have the "actual" problem explained in a three page article, with example code. It can drive you slightly nuts looking for anything that isn't "standard" implimentation. |
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top