Developer diary: plans and progress reports.

By browsing this website you are agreeing to our use of cookies.

Archive of April 2010

The best-laid plans of mice and men Sunday 25th April 2010

An important usability problem has come up in this Boxer issue, and I’m belatedly considering how Boxer’s mouse handling should really work. My comment in the issue goes into more detail, but the short version is this:

Boxer’s windowed mouse handling sucks.

So what to do?

To me, the best solution is to go back to what DOSBox does: ignore the mouse altogether until its locked. Clicking the mouse inside the DOS view would lock it and Cmdclick (or CmdL) would unlock it. The statusbar would tell you what how to lock and unlock the mouse, so there’d be no how-the-hell-do-I-get-my-mouse-back confusion.

What do you think? Are there other better solutions? Ways to reduce the friction of the proposed solution? Please share your thoughts, here or in the issue itself!

Whatever solution is chosen would become the default for new and existing users. The current behaviour is still appropriate and natural for many programs (such as adventure games and productivity apps) but it’s broken enough of the time that it shouldn’t be the default; I’m ambivalent about continuing to offer it as an option, since that would complicate support (two separate application behaviours instead of one) and doing so means adding interface clutter.

Design by 40watt.