Workshopping Middle Mouse Emulation

The current implementation of Middle Mouse Emulation (Alt + LMB) conflicts with the Left Click Select keymap and there isn’t a clean one-step solution. Lots of options have been discussed, but we don’t have a firm rubric to judge them against or a roadmap for testing them. I’m going to talk about that here, rather than on Phabricator, to spare everyone the email spam.

How MMB Emulation Works Right Now

The MMB emulation option in the user preferences isn’t a keymap tweak; when it’s enabled, Blender interprets Alt + LMB as an actual MMB event. This is why it works for things like axis constraints in transform modals, which can’t remapped otherwise.

You can see the relevant code for this in wm_event_system.c near line 4157. It’s fairly straightforward.

What’s Wrong with It?

From the task on Phabricator, here’s what it messes with in the Left Click Select keymap:

  • Number Button Alt-Drag to change all other selected items T69053: Emulate 3 Buttons doesn’t work with ALT Modifier key on UI buttons
  • Edit-Mesh: Edge-ring de-select isn’t possible.
  • Alt-MMB-drag to change views.
  • Grease Pencil, Circle Primitive
  • Weight Paint Gradient
  • Loop select (Worked around with double-click, but not very convenient since selecting boundaries requires quad-click).

Trying to design keymaps around a feature that blocks a particularly useful chunk of input space for a non-trivial portion of the user base is a pain, and expecting users to customize around it feels like a punt.

A Rubric for Better Implementations

Ideally, MMB emulation should:

  • Avoid keymap conflicts
  • Require minimal documentation
  • Fit Blender’s general input schema
  • Work for both touchpads and pens

In order to make these requirements more feasible, we’ll inevitably discuss ways we can:

  • Adjust the default keymaps to remove conflicts
  • Use status signalling in the viewport to communicate changed behaviors
  • Clarify Blender’s input schema through documentation, microcopy, and icons
  • Improve input recognition for touchpad and pen gestures

Solutions I’ve Tested

Testing basic key combinations is fairly easy; it’s just a matter of adjusting the relevant lines in wm_event_system.c and recompiling. Here’s a few that I’ve played with:

Spacebar + LMB

When a user opens Blender for the first time, one of the first things they see is the option to re-assign the Spacebar. It’s presented as a hotkey they’re “supposed” to customize; adding MMB emulation to that list of quick configurations would be an easy sell.

I swapped the existing Spacebar hotkeys from press to double-click when I tested the configuration, as it was the lowest-impact change I could think of. I had to adjust the transform modal map the ‘hard way’ in order to retain full MMB functionality, but I haven’t had any issues with it so far.

This is my favorite option at the moment, but I’m biased by the fact that I’ve used the Spacebar as a modifier, double-click Spacebar hotkeys, for a while now.

Q + LMB

Using an alphanumeric key as a modifier for MMB emulation isn’t ideal, by any stretch, but I wanted to experiment with one anyway. I decided to test Q because it’s a well-positioned key in the left key cluster that only has two popular functions mapped to it, neither of which are modal.

Here’s Q in the default keymap:

  • Q → Quick Menu
  • Ctrl + Q → Quit Blender
  • Ctrl + Alt + Q → Quad View
  • Shift + Q → Toggle Grease Pencil Overlay
  • Shift + Alt + Q → Toggle Grease Pencil Overlay

As I did with Spacebar + LMB, I remapped these hotkeys from press to double-click. Q’s in a great position for a navigation key, and it can be used for MMB emulation without altering the transform modal map. Using Q doesn’t fit Blender’s input schema, but it is the most ergonomic key I’ve tested.

[Anything] + RMB

RMB is consistently used to cancel things, and using it for MMB emulation would require tweaking modal maps, keymaps, and UI behaviors. This overhead, and the number of laptops with poorly designed integrated mouse buttons, makes RMB an ineffective choice.

I love using it for panning and gizmo interactions with a proper mouse, but I couldn’t find a user friendly key combo that used it for MMB emulation.

Capslock + [Anything]

Capslock is my white whale; I’ve managed to make it work as a hold-to-emulate key, but I haven’t worked the kinks out using it as a toggle. I’ll keep chipping away at it for my own entertainment, but I don’t see it working out as a user-friendly key for modifying core behaviors.

Things I Can’t Test

I can churn out patches and quote HCI studies, but I can’t break into your house and test your input devices for you. I’m not in a good position to test multi-platform support and I haven’t had a chance to test anything with the Industry Standard Keymap. I can test pen input, but not touch screens.

There are also some solutions that are too complex for me to implement explorativey, like differentiating between right and left modifier keys, and limiting MMB emulation to dynamic action zones. I’m some random schmuck who decided to Kool Aid Man my way into someone else’s design task and I’m still getting to know Blender’s codebase.

During 2.80 development we tried some unusual or clever key combinations, and after user testing the conclusion was always that we had to revert it because of serious problems.

Personally I think we should not try to invent our own system for things like this, and stick to using the typical modifier keys in our default keymap and settings. It’s fighting the way operating systems are designed to interpret keys and what users are used to, I don’t think it’s worth it.

Is there an archive I can dig through to get up to speed on the obstacles you hit in 2.80? I haven’t had much luck searching on Phabricator.

Unfortunately this wasn’t something we posted online.

We tried tap/drag on Tab so it could be used for both a pie menu and switching edit-mode.

Enough people found this annoying, some even asked why switching edit mode had become slower.

In general, each time we tried something that seemed clever but non-standard relating to key-maps, we found it to go against what users expect enough - that it wasn’t a good choice.


Personal note that I’m not against supporting some clever keyboard mappings for users that want to take advantage of them (as long as it’s not complicating things too much).

There is a preference for e.g. to support two actions [tap/drag] for some bindings. It’s just that I don’t think this is good as a default setup.

I tend to lump pie menus in with other gesture-based inputs; I prefer to initiate them with a mouse click while holding an alphanumeric key. An example of this would be how I’ve mapped the viewport shading options, with Z + LMB for the shading pie, ZZ to toggle between wireframe and solid shading, and small script on Z + Spacebar that enables X-ray on press and disables it on release (it serves as a quick and dirty ‘select through’ tool when combined with Spacebar+LMB for box select). It isn’t a perfect configuration, but it feels more responsive than the drag pies.

My main issue with using the OSkey for MMB emulation is that it shifts the problem instead of solving it. Changing a system behavior creates more training obstacles than introducing a new application behavior, and a non-full-screen application that uses a keyboard hook to eat system-wide shortcuts won’t score well in formalized usability tests. Given the number of alternatives and our ability to test them, using the OSkey feels like a bad take on HCI, let alone UX.