Default keymap MMB+Alt vs Alt+MMB conflict

Recently, issue of auto-perspective not working with user ortho views has been adressed, see here: Viewport orbit snap still does not work with Auto Perspective and is present in 2.73 alpha build. This now allows users to switch between perspective view and axis aligned orthographic views intuitively without need for any silly pie menus or ridiculous matrix of numpad hotkeys.

The problem is that this improvement is partially negated with the other failed concept of viewport switching, which randomly switches to (almost always wrong) neighbouring orthographic view when holding down Alt key first and then middle click dragging in a desired direction (which you will only rarely end up in).

So now users will be confused that when they press MMB first, and then drag Alt, the viewport snapping works, but when they press Alt first, and then MMB drag, the viewport will seemingly randomly jump around.

Remove Alt+MMB click drag axis align from the default keymap and deprecate it in favor MMB+Alt viewport snapping. The two simply can not coexist together while providing predictable user experience.


100% agree. Alt+MMB is too unpredictable compared to MMB+Alt.
@billrey, @ideasman42 - what do you think?

@Skif, I’m also not very keen on adding new features because users don’t like what we have. If the pie menu is not working well, that can be looked into.

Alt-MMB is not easily accessible for tablet users. Or users that enable MMB emulation.
It was intended to be a fast convenience shortcut for users on workstations. Not the primary way to switch views.

So I rather leave this as is, or - if switching views is currently weak, solve it in a way that doesn’t rely on Alt-MMB which already conflicts with an existing preference - see T69323

Pie menu is not working well and it will never work well because it requires user to first determine the name of the view they want to switch to before doing so. It’s significantly less interactive way of view switching. No amount of pie view menu changes will fix that.

Please watch this video for a complete reason:

The point here is not about Alt+MMB accessibility, it’s that there are now two very similar features mapped to Alt+MMB and MMB+Alt, depending on the order they are pressed in. One of those features is comfortable to use and reliable now in 2.83, and other one is unpredictable and uncomfortable to use. The latter one should be simply removed as it is a failed experiment.

I fail to understand the argument of “Not being very keen on adding new features because users don’t like what you have”. That just makes no sense, the whole point of adding and improving new features is to make them more user friendly. The whole Blender development follows that logic, e.g. if users do not like something because it’s not nice to use, then it gets improved upon. Such as the whole ongoing UI change from 2.79 to 2.8.

The idea here is to introduce new axis aligned view switching mode which exceeds the old ones because it is both easier to use and requires just one hotkey.

Also, please explain to me how do you want to make View orbit snap not rely on Alt+MMB when view orbit snap only applies during orbiting which requires MMB to be held? View orbit snap is a sub-mode of orbit tool.

The whole point of this thread is just that there are now two similar feature mapped to same key combination just depending on order of press. Imagine same for example for Extrude, where Ctrl+E would extrude while E+Ctrl would for example delete polygon. Wouldn’t make sense, now would it?

Or to explain it in a different way:
Bug report:
In Blender 2.83 alpha, View orbit snap sometimes fails and instead jumps to random axis aligned view.
Repro steps:

  1. In any scene, hold down MMB first to orbit, then press Alt
  2. Notice the view snaps to closest axis aligned view
  3. Hold down Alt first, then press MMB
  4. Notice view jumps to a random axis aligned view
    Result: View orbit snap sometimes jumps to a random axis aligned view if Alt is pressed before MMB
    Expected: View orbit snap always works reliably regardless fo Alt and MMB key press order.

@ideasman42, nobody asks to remove existing functionality.
The proposal is to map the invocation of operator view3d.view_axis to a different hotkey or disable it by default, it just confuses new blender users:

You could make the same argument for Ctrl-S compared with S, Ctrl.

Where Ctrl-S is save, and S, Ctrl is Snapped Scale. Users are able to handle this difference fairly well.

Removing by default, requiring key-map editing is removing for all intents and purposes for many users.

Suggest this is made into a key-map preference, then we can test different methods

Yes, but that isn’t a combination of a modifier key and a mouse button, and those are two completely different features. On top of that, both of them work reliably. Look at it this way. I’ve never accidentally pressed S+Ctrl in my life, despite using Blender for years, but I’ve discovered this after testing 2.83 for just a couple of minutes. The factors here are very different:

  • When users usually start some viewport navigation, in many cases, modifier key will be pressed before mouse button is clicked. I bet many people pressing Alt+MMB in any software expect exactly the same thing to happen as when they press MMB+Alt.
  • Unlike Ctrl+S/S+Ctrl, this conflict groups two very similar features together. Both do snap current view to an axis aligned view
  • Unlike Ctrl+S/S+Ctrl conflict, both features are not useful here. One is reliable, other is not. One is therefore superior to the other, and given the other two factors above, it’s clear what should be done here.

People almost never (I’d argue absolutely never, aside from Blender’s odd conventions) press a key first and then a modifier key that modifies it, simply because more often that not, an action is already mapped on DOWN action of the key that’s being executed by modifier key. So most of the time, you can not press A+Ctrl to get same result as Ctrl+A, because as soon as A is down, the action A key does already executes. This order dependent nonsense needs to die in case of combining modifier and regular keys. It hurts predictability while not bringing anything in terms of usability. The fact S+Ctrl exist doesn’t meany any notable amount of people use it. I’d be very surprised if people even know it exists given the general assumptions most people make about how a modified keystrokes should work.

I have yet to see a single person who can utilize Alt+MMB in current way and reliably land into the axis aligned view they desire. I’ve never seen such a person.


There are enough examples that use mouse buttons too (transform tool, cursor tool & number buttons for e.g).
Other software also does this, Firefox for e.g supports selecting link text using Alt,Drag, which behaves differently to Drag,Alt.

Not sure what you mean by this.

Unfortunately we don’t have design docs for this since it was a user request made in person by Hjalti (animator in the Blender studio during the code-quest). He found this a fast way to switch views and requested this in the default keymap.

Given this seems to be a case of conflicting personal preferences, I rather leave things as they are, unless someone is interested to treat this as a design task (something like this) and get people in the UI module on-board with updates to view axis switching behavior.

Hi, @ideasman42. Sorry for a little off-topic, but what about the fate of my patch?
I’ve fixed code according to your feedbacks 2 weeks ago. Can you please take a look?
View snap works well, but Auto Persp does not work when user orbits from “User Orthographic” view.
Thanks in advance!

Well, all that’s really needed for me personally is finishing approving @Skif 's patch. I can them simply switch it in my custom keymap. The point of this thread was, as you are saying, actually getting people on board with the novel idea of view switching. If there is unpredictable behavior between Alt+MMB and MMB+Alt, then people will be inevitably mistaking one for the other and it will be in turn hard to get them onboard with it as most people still use default keymap, where these two features clash.

While Hjalti may find it useful, it was most likely very shortsighted solution on his side, and I am quite confident that the new behavior Skif’s patch allows for would probably be found superior to the current one even by Hjalti himself.

1 Like