Gammon Forum : MUSHclient : General : Possible new client written using wxWidgets?

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

General

Possible new client written using wxWidgets?

Possible new client written using wxWidgets?

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5 6 7 8 9 10 11

Posted by

Jestre (13 posts)

Date

Reply #15 on Fri 24 Aug 2007 02:39 AM (UTC)

Message

To keep it short I'm just going to reply to what affects me.

>Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.

Unfortunately all of my scripts are in Python at the moment. I tried converting them to Lua but its been a slow processes needing to learn a whole new way of doing things. I'd prefer if you could some how keep access to some other scripting languages.

>If multiple panes were going to be supported, design them in from the start.

Definately something I'd want.

>Perhaps drop the ability to connect to multiple worlds. After all, many people would be playing one MUD at a time. If you wanted to play on more than one you can open multiple clients.

I actually connect to quite a few worlds at one time. I'm a big multi-tasker and enjoy that feature about Mush. I'd prefer if you kept it in.

Oh and I'm primarily a windows user at the moment.

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #16 on Fri 24 Aug 2007 03:04 AM (UTC)

Message

Ok, I'll throw in my two cents too. First off, Python can be linked in much the same way as Lua, instead of via Windows scripting, and it also has a wxwidgets version, so its more or less an interface issue with how/if you can duplicate some of the table tricks that are so handy when using Lua. If that can be overcome, then that is at least one added language that can be supported in a new design. Of course, what would really be nice is a "basic" clone that was wxwidgets capable, but... lol

MXP support - keep it. Mind you, I wouldn't mind having Zugg *at least* make a change to the implementation, such that you could do something like:

Can do MXP?
Will do MXP.
Supports strict?
Will do strict.

Where "strict" means the client acts like Mushclient does. So, no response would mean the behavior that Zugg's client has. There may be situations where having fallthrough is nicer than having to trap errors, but its a matter of taste, and it would lend itself to backward compatibility, with all the bloody muds in the prior MXP version that don't work right (since the default would be "fall through").

But in general, MXP is used by enough people that removing it isn't imho a good idea, especially when several of the recent posts on the TMS forums about clients have all been along the lines of, "What can we add to clients to help bring in more people?", not, "What should we remove from them?"

I happen to like the XML system. It means that other things can parse it, if needed. The only real problem we have right now is that if we are trying to hand code, nothing that exists *supports* the exact syntax of the functions for Mushclient (and adding that isn't entirely trivial in most of them), the internal editor is a control that doesn't work right (since its based on something that went out of useful application in Win 3.1, when 64k limits made sense, not that they did then either really), and there is no GUI system to edit things the same way as the ones in the main world. The later issue being imho, the biggest pain.

If we wanted to rework that, one might consider making the script in a parallel window to the triggers, etc. So that when you select a trigger, timer, etc. to edit it would also move to the "script" function called by that element, or show the code in its send field, if its not in the main script space. Cramming the whole mess into a single file, all of it script, just makes things worse for the casual user imho, and one of the things you are trying to do, by fixing some of the screwy function calls we have collected as things grew, is to make things simpler, not harder. ;)

Not sure how we deal with COM though. One of the biggest fracking pains in the rear using Firefox on Windows is its *lack* of COM support, which means most stuff won't work, and what does work only barely works, if it involves *using* anything that is based on COM. I have to open an IE tab 90% of the time to watch video clips in it, because 100% of all methods it has to handle running players fail too often to rely on it. One solution would be to support MONO, but that gets you into .NET, which means it might not run at all on machines earlier than 98, and I am not sure how/if it solved the problem of trying to use COM objects under Windows, where you *may* have situations where you want to talk to, and have talk back from, Windows applications that use COM to do that.

Also.. Some plugins *can't* be running solely in Mushclient, so some stable and straight forward means to get the plugin to talk to an external is needed. UDP and other solutions we use right now are neither straight forward, nor imho, entirely stable. Why do we need to do that? Because, not everything can run as a suspendable process, or as something that interrupts the client until it finishes. We sometimes **need** parallel execution, and short of creating a client script space that has restrictions on operation (like not being able to directly send anything to a mud itself), which can thus run in a separate thread, its just not possible to do some things using plugins, especially if it involves sockets and internet traffic, where delays may be in seconds, and responses can't be *held* until something checks for them.

I have to say, I agree with about half of your suggestions, mostly. The rest... I think is trying to fix issues by removing things that are complicated, rather than actually improving things by figuring out why they haven't worked right. The likely result is probably not a client I would use.

Oh, and one slight gripe. Mushclient uses Windows scripting, not WSH. The distinction might not seem like a big one, but WSH is a stand alone implementation, which includes several io functions not allowed in the embeddable version, and native event support, which is also not *natively* supported in the embedded version of any of their scripts. You can think of it as WSH-lite, or WSH-brain-dead. Much like other MS products, which work in one context, which 10% of the users actually find useful, but won't in the context that the other 90% are going to try it in. lol

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #17 on Fri 24 Aug 2007 05:09 AM (UTC)

Message

Quote:
First off, Python can be linked in much the same way as Lua, instead of via Windows scripting, and it also has a wxwidgets version

There is also a wxJava, wxPHP, wxTCL, wxRuby, wxBasic (this one can be flakey)... I don't know how well some of these work, but it seems like there is an option for most of the languages currently available.

Quote:
I happen to like the XML system. It means that other things can parse it, if needed. The only real problem we have right now is that if we are trying to hand code, nothing that exists *supports* the exact syntax of the functions for Mushclient

The part about xml is a good point, but the problem I currently have with everything being in xml is editing plugins. I have to swap the syntax highlighting back and forth between xml and whatever language to double check things as it is. And that's hinders things even more when the XML wrappers throw off the script language highlighting. At least if it's all one language, the parsers would have no trouble with it. Granted, this could cause plugin files to have to be named differently based on script language, with .lua .py .js etc, which honestly isn't a bad idea. It allows for quicker recognition.

Quote:
Oh, and one slight gripe. Mushclient uses Windows scripting, not WSH.

I thought WSH was the first thing Microsoft released to deal with adding scripting into programs. It even came standard in Win98. Do you have any sites handy that explain the difference?

It is much easier to fight for one's ideals than to live up to them.

Posted by

David Haley USA (3,881 posts)

Date

Reply #18 on Fri 24 Aug 2007 05:25 AM (UTC)

Message

Quote:
There is also a wxJava, wxPHP, wxTCL, wxRuby, wxBasic (this one can be flakey)... I don't know how well some of these work, but it seems like there is an option for most of the languages currently available.

All that is different, that's not binding PHP, Java etc. to wxWidgets; it's binding wxWidgets to the scripting language (so that you can write your wxWidget application in that language). It's a little different to have an application that hosts several scripting languages.

That being said, it is possible to embed several interpreters into an application. It's just a fair bit of legwork to support several at a time, depending on how much you want to support.

Quote:
The part about xml (David's note: that it is parseable) is a good point,

Frankly I'm not sure I agree; Lua is very, very easy to parse, arguably easier to parse than XML, and besides there happens to be a parser that is very small and easy to embed into an application; namely, the Lua interpreter itself.

Besides, as somebody said, the config file is really more of an implementation detail and the vast majority of users wouldn't care either way. For instance, it will not complicate anything for other scripting languages.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #19 on Fri 24 Aug 2007 06:02 AM (UTC)

Message

Quote:
All that is different, that's not binding PHP, Java etc. to wxWidgets; it's binding wxWidgets to the scripting language (so that you can write your wxWidget application in that language). It's a little different to have an application that hosts several scripting languages.

With wxLua at least, it can do both. I just figured it was the same for the rest, but they might not have all the same functionality as each other.

from http://wxlua.sourceforge.net/docs/FAQ.html

Quote:

#2 Can I use wxLua as script interpreter embedded in my own C++ applications?
* Yes! That's explained on the wxLua homepage.
* This is one of the strong points of wxLua: it can be a lightweight, fast interpreter to extend your application and let the user customize it...
* You may create as many wxLua interpreters in a single program as you like.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #20 on Fri 24 Aug 2007 06:12 AM (UTC)

Message

hah! Found it. There's a wxScriptInterpreter class in script.cpp/script.h which can be initialized to either Lua or Python from the documentation I've read so far. No reason to think that there isn't currently or won't eventually be a way to use a class inherited from the wxScriptInterpreter class for the rest of the wx* languages. Personally, I just care about Lua, so I'm not going to bother looking it up unless I have to.

Here's the most succinct doc I've found on the subject:
http://wxcode.sourceforge.net/docs/wxscript/classwxScriptInterpreter.html

It is much easier to fight for one's ideals than to live up to them.

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #21 on Fri 24 Aug 2007 06:18 AM (UTC)

Message

Quote:

Mushclient uses Windows scripting, not WSH.

You are probably right here. I wasn't sure when I wrote that. I probably mean "Active Scripting" judging by what I read when I looked into it again.

Thanks for the comments so far, keep them coming. :)

I am getting the impression at this stage that a lot of people are happy with MUSHclient as it is, and in particular like the support for multiple scripting languages.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

David Haley USA (3,881 posts)

Date

Reply #22 on Fri 24 Aug 2007 06:19 AM (UTC)

Message

Hmm, that's good news. It still means, though, that you'd need to do all the legwork of providing your application bindings in all of the languages. It also means that Nick would have to do a lot more work to let people do the cool things he was talking about like directly manipulating the client data structures in their 'native' language.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #23 on Fri 24 Aug 2007 07:52 AM (UTC)

Message

[quote[It also means that Nick would have to do a lot more work to let people do the cool things he was talking about like directly manipulating the client data structures in their 'native' language.[/quote]
I think some encapsulation would still be required. Like having everything localized within plugins so they can't directly affect world aliases and triggers and such. I'm usually a bit wary of letting users directly manipulate data. Lua can get around some of the issues by using metatables to allow for the rejection of bad values, but I'm generally quite paranoid about data structures.

It is much easier to fight for one's ideals than to live up to them.

Posted by

Isthiriel (113 posts)

Date

Reply #24 on Fri 24 Aug 2007 10:16 AM (UTC)

Message

Quote:
David Haley wrote:
Hmm, that's good news. It still means, though, that you'd need to do all the legwork of providing your application bindings in all of the languages. It also means that Nick would have to do a lot more work to let people do the cool things he was talking about like directly manipulating the client data structures in their 'native' language.

That's why you use an interface generator like SWIG. As I understand it, you write the C++ functions that you want the script language to be able to call (and the classes etc...) and then write the description file for SWIG, telling it what you want to export. Run SWIG over it and get a .cpp file for each language with all the tedious legwork done for you.

Most of the time "tedious" = "write a program to do it for me".

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #25 on Fri 24 Aug 2007 11:33 AM (UTC)

Message

Looking over SWIG, it looks like we're comparing apples and oranges here. SWIG seems to just create an interface to the C code for the scripting languages. It does not appear to provide script support within the C program. Granted, I just poked through the very basic examples that were on the homepage. If it can go the other way, there's still the matter of needing a script interpreter which wxWidgets can provide.

It is much easier to fight for one's ideals than to live up to them.

Posted by

David Haley USA (3,881 posts)

Date

Reply #26 on Fri 24 Aug 2007 03:41 PM (UTC)

Message

SWIG will only get you so far. My understanding from following Lua list traffic is that it will get the most horrible leg work done for you -- writing the code that export the functions to the Lua namespace. But that's still unfortunately a far cry from doing all that needs to be done across all languages. My impression is that you still need a fair amount of manual tweaking with SWIG.

Besides, you still have the issue of needing to export the Lua data structures (that aren't in C++ to begin with) into the other scripting languages. For SWIG to help, you'd have to find a way to mirror the Lua structures in C++. SWIG definitely won't solve all the problems here, unfortunately.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #27 on Fri 24 Aug 2007 05:08 PM (UTC)

Amended on Fri 24 Aug 2007 05:12 PM (UTC) by Shadowfyr

Message

Quote:
I thought WSH was the first thing Microsoft released to deal with adding scripting into programs. It even came standard in Win98. Do you have any sites handy that explain the difference?

Well, I am not sure where you can find a page to describe it. The scripting help file for it explains the main one, which basically amounts to looking through the list of functions and finding that IO like directory lists, opening and closing files, etc., are disallowed in ActiveScript. Also, CreateObject in WSH will, when it creates an object, also create a lookup table of event sinks in that object, which can then use a connection function to link the reference address for a script function to allow you to handle the event you link. There also seems to be some sort of differences between which exe you use, since it has a cscript.exe and a wscript.exe file... I would guess that one has different restrictions than the other, but I have no clue what those would be. Its kind of a screwy system, all done for what MS calls "security", never mind that they never seem to manage to truly secure anything that way. lol

Basically, WSH assumes the task of dealing with object events and IO, while ActiveScript **assumes** that the hosting application will handle those things more securely, so doesn't allow them to be done via your script, and in fact, in the case of IO functions, doesn't even provide them at all (while object event handling *exists* in ActiveScript, it just assumes that the host is keeping track of it for it).

Posted by

Guest1 USA (256 posts)

Date

Reply #28 on Fri 24 Aug 2007 05:26 PM (UTC)

Message

Perhaps I misread.. if the proposed new client means that we can no longer use our external scripts if they are written in anything but lua, then that's a big no for me.. I use VB for that, and if the proposed client means having to rewrite 7 years of accumulated scripting to another language I don't know, then forget it, I just don't have the time unfortunately.

Posted by

Shaun Biggs USA (644 posts)

Date

Reply #29 on Fri 24 Aug 2007 08:44 PM (UTC)

Message

Quote:
Well, I am not sure where you can find a page to describe it.

Yeah, I got it when Nick mentioned Active Scripting. I just hadn't heard it referred to as Windows scripting before. Either way, the point is kind of moot, since one of the benefits of wxWidgets is that it is cross-platform, and the only thing MS does evenly throughout the various operating systems is filing law suits.

Quote:
if the proposed new client means that we can no longer use our external scripts if they are written in anything but lua, then that's a big no for me

I'm agreeing with this even though Lua is all I use anymore. Too many people like MUSHclient because of all the scripting languages available. This is certainly a huge concern, which is why a lot of people have been suggesting ways to support all or most of the scripting languages currently available.

It is much easier to fight for one's ideals than to live up to them.

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

318,551 views.

This is page 2, subject is 11 pages long: 1 2 3 4 5 6 7 8 9 10 11

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )