|There have been various threads recently about proposed major enhancements to MUSHclient. Some of these are:|
- Internationalization (already done)
- Improvements to the configuration screens
- Removal of lots of configuration items from Registry to configuration files
- Extra panels (panes) for the world window (eg. statuses, coloured chat, health bars)
- Better support for some things like accelerator keys (binding keystrokes to actions)
- Better font management (eg. multiple fonts in output window, possibly graphics as well)
- Support for Linux and Mac operating systems
I wonder whether, rather than adding all these things into MUSHclient, it would be better to start from scratch (a bit like Zugg is doing with CMud, as opposed to enhancing zMud).
One thing that caught my eye a while ago was wxWidgets (formerly known as wxWindows), see:
This is a cross-platform, open-source set of GUI-oriented libraries (similar in concept to MFC from Microsoft).
Using that, a single set of source code could be used to build binaries that would run on Windows, Linux, and Macintosh, which itself would be a great thing.
Since it is open source there would be no big problems with writing a new client with it. Possibly wxLua could be used too.
Now I am well aware (more than most people I imagine) that writing a MUD client is a big job, however it might be worth it, compared to fiddling around the edges of MUSHclient.
I did a trial version a few years ago using wxWidgets, and got a rudimentary implementation going, before I got bogged down in problems of replicating things like multiple worlds being open at once. However times have changed a bit since then (hello, Lua!), and I think it could be a bit easier nowadays. For one thing, the goal would be to simplify a lot of the stuff that has built up over the years in MUSHclient, as I have added new ways of doing things, but retained the older ways for backwards compatibility.
Various things that could be simplified are:
- Use Lua for configuration files rather than XML. Lua configurations can be loaded and saved in a few lines of code, thus saving heaps of XML parsing and writing.
- Drop the various Windows Script Engine script interfaces in favour of straight Lua scripting.
- Drop the "macros" idea in favour of accelerator keys.
- Drop the "keypad" configuration in favour of accelerator keys.
- Drop the "default fonts/triggers/aliases" idea. This has pretty-well been replaced by plugins.
- Store all colour runs internally as RGB codes, rather than the current (complex) system of ANSI, custom colours, or RGB. The current system makes it very fiddly when using colours (eg. drawing them).
- If multiple panes were going to be supported, design them in from the start.
- Drop MXP support (at least initially) as I don't think *that* many MUDs are using it. A quick search of MudConnector shows that about 151 out of 1,515 MUDs use MXP.
- Drop the "multiple output windows" idea (Window menu -> New Window) - as this makes things more complicated in various places.
- Maybe drop the "chat" system initially - I am not sure how many people use this.
- Maybe drop the notepad idea - after all you can always use your favourite text editor.
- Drop "custom colours" in favour of simply specifying RGB colour codes where required (eg. in triggers).
- 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.
- Use STL (C++ Standard Template Library) internally where possible to simplify list (and similar) management. (I am aware that wxWidgets does not use STL internally, however as it is written in C++ there is no reason why I can't).
- Build in proper support for Telnet negotiation from the ground up, which would simplify things a bit.
- Simplify the "send to" part of triggers, aliases and timers. Perhaps everything could be "send to script", as you can script sending to all the other places. (eg. "Send 'go west'" to send to the MUD).
- Simplify the script interface somewhat. A lot of early script functions (like WorldName, WorldAddress, WorldPort) can be achieved by doing (the equivalent of) GetInfo. Also, by only supporting Lua scripting, the script interface can become more powerful. For example, you can have optional arguments, supply tables as arguments, and return multiple return values.
- Some script actions (like plugin callbacks, or "on world connect") could be simplified by having some sort of event model, where you add a function to a table of events for which you would like notification. This could provide a more flexible way of intercepting things (like incoming/outgoing packets).
Now I realize there will be howls of protest about some proposed things, perhaps you love MXP, or are connected to 10 worlds at once all the time? However, remember the existing MUSHclient will still be available.
What I am interested in getting a feel for, is how much interest there would be in a new, cross-platform, open-source, client along the general lines proposed above?
If you are interested, please reply indicating:
- How interested
- Which operating system you are interested in (Mac, Linux, Windows)
- List any "must have" features - these are features, without which, it would be useless to you. (By "must have" I don't mean "the ability to turn my coffee-maker on in the morning"). Appropriate things to list might be: ability to open multiple worlds, spell checker, plugin support, MCCP support.
- List any existing features you don't use, or care about (for example, spell checker, MXP support, proxy support).
I am not necessarily promising to sit down and write this new client, but am trying to gauge where to best spend future effort.
- Nick Gammon
| top |