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:

@Ailish, I installed pymudclient on my Mac. Are you really keen/attached to pygtk? Just seemed quite convoluted to acquire it on my machine/easy to get new users confused. Are you planning to package it as a distributable? Would you consider a different gui framework?

Ok, I looked at Kivy and it's even more of a pain in the **** to install than pygtk. It doesn't nearly easy-install and the binary installer for Windows they give you installs it's own instance of python rather than using your existing one which is patently ridiculous.

Nonetheless I'll play around with it but I just don't see how it's any easier

wxpython is unfortunately the ugliest thing I've ever seen. Kivy is gorgeous and the installation is actually easier than I thought but the fact that it has no usable Text Box type widget and you'd have to handle output using a Label widget that treats text as graphics rather than text is *headdesk *

Yeah, you probably don't want to take graphical appeal advice from me. The only other big one that springs to mind is pyqt, and I think that has a nasty licence if I'm remembering rightly (I might not be).

Think it's a LGPL licence, need to keep your code open source iirc. Yeah, PyQt would be the other popular option but I haven't looked at it much myself. Leveraging Qt is supposedly very beneficial (see Mudlet's 3.0) but I don't see the need myself. Happy to be proven wrong!

Then PyQt may be something else you might be interested in; that said, if pygtk is the familiar territory and if you could some how bundle it with the rest of your code, that would be sufficient. Sorry, I don't mean to sound demanding, but if you really are going to put the hard yards in, I wouldn't like for it to become unused because of accessibility/ease of installation issues.

I haven't posted any updates on pymudclient recently (mostly because there hasn't been a lot of interest in anyone other than me using it). I do have one important update though. Pymudclient now (hopefully) fully supports all popular screen readers. I tested it to the extend that I was able myself, but obviously, I don't really know what proper screen reader support should sound like.

I'd really appreciate if the players who actively use screen readers for accessibility could reach out to me and help me test this.

Do you actually pay any attention at all to that side panel? I gave up on fancy UI things like that when I realized that I never actually looked at any of it in combat.

"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."

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 truncateddata

Rather than:

This is a line of truncated 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.

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.