With all due respect… that’s complete bollocks. When I first went to pick up Blender, it was to get software I could use on my home PC for which the studio I was working for wouldn’t let me have a license. I tried hard to get the “Blender way” but gave up and used Wings3D for modelling and some other software I paid for out of my own pocket for texturing. Despite the fact that Blender could do those things, Blender’s abnormal user interface was too much of a hassle at the time to work through.
As my needs increased beyond basic modelling and texturing, I returned multiple times to Blender (& giving up) before it became my primary 3DCC application. So, I am the example that proves your complaint incorrect - I did/do care about LMB select, I did give up multiple times because of Blender’s backward (& then inconsistently implemented) user interface and, frankly, if you’re going to tell me my work with it is “not anything of note” - you & I are going to have a problem.
Love to see it implemented! I’ve used it shortly and it seems well implemented at first sight which is great. Funnily enough, I’ve now reached a point where I am torn between changing to left click select over right click select, now that I’ve waited so long for it to be implemented. Oh the irony
Using W, now, is not different than using B before the commit.
It is not a toggle. It does not solve conflict with active tools.
We have one go from active tool to select tool. But there is no return to previous active tool.
If W was able to switch from select tool to previous active tool, it would be an help.
But currently, problem is still present in edit mode or paint mode.
At least, less people will request RMB as context menu and double click to select loop or be surprised by cursor moves.
Action/selection separation (what most people simply refer to as right mouse select) has various benefits all of which have been explained plenty of times before.
In terms of ergonomics, right click is what is closer to left click.
So, right clickers have 1 left click and 1 almost left click in situation when people would like to use left click.
Left clickers just have 1 left click + a switch key to change left click use or only half of tools used by right clickers.
Currently, right click select gives you ability to modify selection without changing active tool using left click.
In paint modes, you can restrict painting to a selection of elements of mesh done with right click while left click is used to paint.
There is still actually a real advantage in terms of speed to use right click select.
In terms of ergonomics, it is same principle behind selling of a mouse with extra buttons.
Action/selection separation is not in any way conditioned by which mouse button is primary. The same way you can RMB select and LMB move gizmo, you can also LMB select and move gizmo using RMB. Given how rare is the situation of an action based UI element covering a selectable scene element, the tradeoff is not worth it.
I don’t see how this could be related to speed in any way. In the same manner Left Click can be used for action and right one for selection, it can be swapped the other way around. It’d make for an equally weird input solution, but it proves that it’s not relevant which mouse button is considered primary.
But there is one significant difference. Selection is far more frequent action, so it should be mapped to a mouse button which is most commonly used as primary.
Bottom line is that if you were to take any other 3D software out there, and edit it’s input mapping to be similar to Blender’s with Right Click select and the action/selection separation thing, I can guarantee you you would see no substantial increase in speed or productivity.
On top of that, action/selection separation may sound easy when said, but in practice it may come with a lot more compromises. When you pointed out differences between left clickers and right clickers, you forgot to mention that right clickers have to resort to reaching for B key every time they intent to perform selection of multiple elements
Of course no one would expect RMB to be a brush stroke in any sensible 3D software. But you can’t apply same rules to 3D modeling viewport and painting/sculpting workspace. That would make no sense. Making LMB selection in viewport work doesn’t mean brush strokes suddenly have to be done with RMB.
It uses the standard left mouse selection, it still uses LMB for brush in any painting modes, and overall, it’s proof that Blender’s input mapping can be even faster and more efficient with LMB centric workflow.
How is that inconsistent? You can not possibly expect consistency between completely different types of work. It’s like complaining that WASD keys perform walking in First Person Shooter game but move camera view in Real Time Strategy game. Those are different scenarios requiring different input layout optimization. Consistency only makes sense if the context is same, or at least similar.
Blender is one piece of software, not two or three or four. One of it’s many advantages is that between editors, keys and actions, workflows and ui elements, remain quite consistent.
Of course, we can. 2.8 is full of shiny gizmos.
You want to explain to us that RMB is intuitively what a new user will do, each time, he encounters a new one.
I think that is a lot simpler to associate RMB to one unique behavior.
Of course, pressing the gizmo could be considered as one unique behavior.
But it would really means all gizmos. So, navigation gizmo, too.
And finally, it implies more RMB than LMB. It can’t be easier to retain than RMB for selection.
The way you are putting it sounds like if LMB does selection in viewport, then it must do brush strokes in sculpt mode, even though selecting and brush painting are two completely different actions.
That just makes no sense. Following your extreme consistency, what would you do in Text Editor, where pressin N key types N letter instead of opening the N panel. Or in image editor, where you have to press Alt+N to create a new image because Ctrl+N creates a new file. These mappings always need to be customized in terms of context.
If you think I meant that we should simply swap RMB and LMB, that’s not the case at all. The only reason I’ve mentioned that was to disprove your theory that the RMB centric workflow has any speed advantages.
I think LMB should select, and LMB should interact with gizmos as well. I think that LMB should perform both action and selection at once, and the rare cases where these two overlap at a single place on screen can be solved in smarter ways, than compromising ergonomics of the entire keymap.
In what parallel universe are you living ? How blender could have a mind connection to know when this left click means selection but this one means action ?
Go ahead. Give your magical solution because it would close the topic for ever.
