pymudclient
So, for the last several weeks, I've been writing my own mud client to use for Imperian (to be completely precise, I forked an existing open source client, mudpyl, which has been dormant since 2008, and been making extensive modifications to it).
The reasoning for this has been my dissatisfaction with the available options. Mudlet seemed like the most polished of the bunch, but I still felt pretty trapped by their GUI framework for scripting, and also I wanted to use python rather than lua.
It currently supports regex triggers and aliases, macros of almost any keys, triggers on gmcp_events, color HTML logs, gags and text replacement in triggers with Mudlet-like syntax for colors, tab completion of inputs, as well as history of previous commands. Combat modules, which is just a collection of triggers, aliases, gmcp event handlers and macros are simply python modules with very easy to learn syntax hooks. I find it to be just as fast, if not faster, than Mudlet and the coding is much easier (though that's in large part is driven by the fact that I prefer python to lua). It's feature-complete enough to use, I've been using it exclusively for 3-4 weeks now.
Some of the things not yet implemented that I'm planning for the future:
* Easily customizable interface (probably through something like Glade)
* Multi-line triggers
* Ability to run it as mudbot-like proxy for people who want to use their own client like Mudlet as a user front end
* A bunch of useful imperian-specific modules - possibly a healing module that's a bit more sophisticated than gbot.
Below is a screenshot of the interface. If anyone's interested in checking it out or helping me develop it further, please let me know
6
Comments
Nonetheless I'll play around with it but I just don't see how it's any easier
A shame because I was really taking a liking to it
Could look at wxPython maybe. I guess it depends what priority is (cross platform, it should look awesome, easy to install etc).
Cool project!
"On the battlefield I am a god. I love war. The steel, the smell, the corpses. I wish there were more. On the first day I drove the Northmen back alone at the ford. Alone! On the second I carried the bridge! Me! Yesterday I climbed the Heroes! I love war! I… I wish it wasn’t over."
Again, nice work.
Re: accessibility
The gui should probably be disabled on startup if inheriting from ScreenreaderProtocol. You can't really review properly using a screenreader with it enabled (text becomes mixed in with gui data).
After I disabled the gui, review was very solid. It'd be nice if it tried to wrap on whitespace; i.e
This is a line of truncated
data
Rather than:
This is a line of trun
cated data
I'm used to reading the latter version, but a lot of people won't be and will find it annoying. This is all based on the assumption there is not a setting somewhere to handle wrapping differently; I haven't dug in much yet outside of the accessibility stuff.
I tested with both jaws and NVDA. NVDA was basically fine out of the box, no issues at all. Jaws would read the command before the output on hitting enter; I imagine this would be resolveable by having an option to remove the last command history. There are probably other ways, but I'm not familiar enough with the interface of accessible_output to know how configurable it is in terms of speech interrupts/prioritisation. That is a fairly big deal though, as it essentially adds a response lag to all entered commands (which grows exponentially with how long it takes to read the command).
I will try to test voiceover/orca later when I have time to setup gtk on an osx and linux installation.
Re:disabling GUI - good point. This didn't occur to me at all, and in my testing with Windows Eyes this wasn't an issue (or I may not have tested thoroughly enough). This is easy enough to do. What should the ideal interface be in accessibility mode, in your opinion? Just a big text entry box? Sorry if this is a dumb question. I don't really have any understanding of HCI nuances for visual impaired people.
Along the same lines, does your existing set up allows for "scroll back" and replay of previous output? Is that something I should consider adding support for? (I'm not sure how I would do that yet, but I have some ideas)
Re: wrapping on whitespace, not sure I understand. Does it have anything to do with where Imperian wrap lines? I have it set up to not wrap all all (wrap width config setting of 0 or something like that) I didn't experience anything like you've described. Window Eyes would read the entire block for me with no midword "pauses". I'll try to replicate the issue some more
Re: reading back the command. I'm guessing this has to do with the fact that after you push enter, the default behavior of the client is to leave the previous line in the entry box and highlight it so that the user can either easily overwrite it by typing something else or just hit enter to send it again. I'm reasonably sure the highlighting is the reason the screen reader is reading that line again. I'll change it so that in accessibility mode the line is always left blank after you hit enter. You can still access the previous command with up arrow.
I haven't played much with accessible_output either yet, that's on my list of things to do.
Thanks, this has been most helpful
Interface:
Just a text field, yeah. The more minimal the better, basically. Sometimes it can be useful to have an info bar of some form at the bottom, but reallistically that's going to be an exception rather than the rule (and if someone needs it they'll probably be able to add it).
Scrollback:
Screenreaders basically support this already in varying flavours, I'd not worry much about it. This follows to the next point, this is where I encounter pauses. The actual reading of output when entering commands and such is fine. Its very possible its screenreader dependent. Unfortunately, I've never used window eyes so can't really draw comparrisons there.
Highlighting:
Yeah, that'd do it.