Default Keymap: Review and/or Rework Selection #37420

The current selection tools and methods are all over the board. It's a mix of Left and Right mouse selection in the various editors and even across different tools within the same editor. These all needs to be made consistent and to be carefully mapped to the Select button in the keymap.

This involves:

Ensuring all tools correctly use Select / Action input, such that Left / Right selection can be swapped at anytime
Making all selection tool modifiers (add / remove) consistent.
Prioritizing Selection Tools within Editors (box, circle, lasso)

This needs to all be done very carefully as we have a large number of selection tools in Blender (particularly in Edit Mode). Conflicts are quite common and easy to create. Unless there's a very good reason, all selection tools should be made consistent across all editors.

Note: this will be done in conjunction with #37417, to create a new alternate keymap initially, giving users a chance to test thoroughly before updating the default.

Changed status to: 'Open'

Added subscribers: @JonathanWilliamson, @brecht

Initially assigning this to myself to actually implement, but of course will be working with all involved to define what changes are to be made.

Added subscriber: @billrey

As for deciding what to do, the main descision is the Left or Right-click select.

I'm in favour of left click selection for these reasons:

It's consistent with all major OS's and graphics apps
It's consistent with Blender itself (left click is used to select items in the Outliner, for example)

Right click selection is not only a major stumbling block for new users, but also for users who work in a mixed environment switching quickly back and forth between Maya, Blender and ZBrush etc.

Blender was designed for right-click select though, so switching to left click adds some issues:

What to do with 3D Cursor placement
What to do with paint modes (clearly we don't want to map painting to right click)
How to handle corner cases like weight painting while selecting bones

I think these are solvable issues though.

There's a few more issue with left-click select, see e.g. this video by Sebastian .

The transform manipulator can get in the way of selecting things.
Scrubbing time and selecting keyframes in animation editors: users may expect both on left but it's not efficient that way because of accidental selection when scrubbing.

These are not solvable in an optimal way and there is a trade-off to be made.

That being said, I think there is some agreement that we will make left click select the default, Ton agreed with it as well as long as we have a well supported way of switching to right click select.

Added subscriber: @cessen

@brecht

The transform manipulator issue is indeed a bit annoying. But I think it's addressable.
The Maya approach is to make turning manipulators on/off extremely fast and convenient. There is a single hot key for each of the manipulators: "translate", "rotate", and "scale". And additionally there is a "manipulators off" hot key. So when a user wants to select something, and their manipulator is in the way, they can just turn the manipulator off temporarily.
The XSI approach encompasses the Maya approach, but also does something else that's cool: the hot for a manipulator can simply be held down to make the manipulator appear, and then releasing the hot key hides the manipulator again. When I used XSI, this was a super nice workflow, and I wonder if we couldn't take that "hold down to show manipulator" approach.
(I still prefer the pure-hotkey approach the Blender takes without manipulators, though.)

RMB for scrubbing actually works really well. I'm not sure why Sebastian harps on it as a bad thing: RMB scrub is a lot better than RMB select from a user-confusion standpoint. It's a little non-standard, but fast to pick up. The only issue might be if we want to introduce RMB context menus down the line. But IMO we can tackle that if/when we get there.

The biggest issue with LMB select, and IMO the only major problem with switching to it, is paint modes. The issue is that in, e.g., Weight Paint mode the user needs to both be able to paint the mesh and select bones. A typical wacom setup, however, sets the pressure-sensitive tip of the stylus as LMB, which means LMB really needs to be used for painting. The other paint modes have similar issues. It's not clear to me what the best way is to deal with this.

Added subscriber: @fahr

Hello Cessen,

I reviewed your youtube videos of your new keycaps and I'm in love with most of it.

I do have a suggestion concerning your use of the alt key. My opinion is that you really shouldn't assign any default functionality to it at all.

There are several reasons for this. First and foremost, the alt key is often used as a modifier for other things. In blender, it's used to emulate middle mouse button, which is actually useful. Many Linux distros, by default, hijack the alt key. Relying on the alt key for default functionality could result in inaccessible features for some.

Additionally, leaving the alt-key alone for the default key map frees it up to allow alternative navigation options for those who want camera navigation to be similar to other apps. For example, one could assign maya-like alt-nav options without disturbing any other keymap. As it is now, if I wanted maya-style navigation, I would have to reassign lasso select (which I use a lot), possibly requiring even more re-assignments in a cascading effect.

Added subscriber: @Januz

I've been using left-click to select for the past month, here's what I found:

The transform manipulator does get in the way. I usually zoom closer to select or (rarely) disable it.
The 3D cursor placement is set to ctrl+LMB. I used to accidentally misplace it a lot before, this setting feels easier to control.
You can't use LMB to scrub and select at the same time. Select seems to override scrubbing. I kept scrubbing with RMB on F-Curves,the Dopesheet and the VSE, while using LMB in the timeline. I found I tend to scrub more in the timeline now, even with the other editors open.
Having the Add Node menu in RMB is awesome

@cessen +1 to hotkeys for the manipulators
@fahr I'm not sure this is an issue for most of users. It could be solved by having an "emulated third button" (or Unity-friendly :) ) keymap.

Added subscriber: @GabrielGazzan

I'm in favor of LMB selection too.

I think a good workflow for the Dopesheet/Graph Editor would be:

LMB click over a keyframe to select it.
LMB drag over a keyframe to move it (or them, if there are several ones already selected).
Shift + LMB drag to restrict movement to horizontal/vertical direction only.
LMB drag over an empty space to define a border selection.
Ctrl + LMB click/drag to change/scrub time.
LMB drag over the time cursor to scrub time.

Added subscriber: @PawelLyczkowski-1

Added subscriber: @liquidape

Added subscriber: @CarstenWartmann

Added subscriber: @xrg

Added subscriber: @michaelknubben

Added subscriber: @marcog

Added subscriber: @ErickNyanduKabongo

Added subscriber: @AditiaA.Pratama

Added subscriber: @Bollebib

Added subscriber: @tommy5

Hi, in my keyconfigs, i use doubleclick to set 3d cursor. It works well.

@tommy5 Sounds good to me!

(as posted elsewhere earlier:)
The only issue I see there is that when you're placing your cursor on another mesh, you're always going to select the component underneath on the first click, losing your initial selection. I'd vote against this, personally.

@michaelknubben I thought that you either LMB click, or LMB double click, but I tested this and you are right, currently it would select first.

This is almost always the case.
Unless you add a small delay (as is done in sticky key hotkeys), which might result in some missed selections, you're going to want to use the double-click where a single-click isn't disruptive. This is why doubleclick to launch a program works well, or double-click to loop-select edges.

Can it be put in the Shift+S menu? Something such as Shift+S -> "Cursor to Mouse" and next spot you click is where it places it. Could potentially even be a modal tool, that you have to ESC out of like Circle Select.

Double-Click I think should "Select Linked." Click once, select a face or whatever, double click select the entire object. If double-click does a loop-select it won't work with the preselection highlighting add-on.

@michaelknubben Yep, you're right, It does select first. Never noticed that, that tells you how much its used. For me, it's usually Cursor to selection and sometimes i set manually XYZ coo. in N panel

@xrg that's exactly what I was thinking too.
Is the 3D cursor used so often to have such a prominent key? It would be better in the snap menu, and the RMB could be used for useful menus (like add).

How often do you add meshes, though? Not often enough for it to take up rmb, I think. The spacebar-menu plugin is a much better fit, although a more context-sensitive menu on rmb with the spacebar menu remaining on spacebar would be much better still.

Basically, have RMB open something like the Face menu when you're in face-selection, Edge menu when in edge-selection etc.
The problem with those current menus is that you can run face-specific tools even in vert-selection mode, when your selection encompasses a face, and that you'd be missing out on the Specials menu, so it would have to be a reorganised menu.

@Januz If it's used, it's typically used repeatedly in a short amount of time, to position it correctly, so it being just an entry in a menu is no good.

@xrg +1 for double LMB click - Select Linked.

Yes, I also like double-click for select linked.
It would have to respect the conventions of regular selection than it currently does, though, as it adds by default, without holding shift.

I'd also want to change those conventions (no toggle, but actual add and remove actions), but that's a seperate discussion :D

@michaelknubben I meant add as an example. RMB menus would depend on mode and give quick access to often used tools/ops (like giving you quick access to specials in edit mode, etc.)

@PawelLyczkowski-1 Then a modal dialog like @xrg mentioned would work better. You click on "Set 3Dcursor" and LMB lets you position the cursor anywhere you want until you hit esc or enter.

Any way to set the double click in the keymap? I can't add to my selection, but I'm fairly new to the keymap editor so I might just be missing something.

@michaelknubben https://db.tt/oUbvQlwY

Thanks, but I'd already done that. I meant that I can select linked by double-clicking, but I can't find a way to add to my selection. Removing works fine, though.

I don't know if it's been suggested before, but what about making the 3D cursor selectable (like an object)? Then the user could use G to position it, along with the axis locks/shift/snapping/numinput/etc. That would be free the LMB and it might even make it easier to use.

Added subscriber: @mont29

Added subscriber: @00Ghz

The 3D Cursor Object sounds like a good idea. Through just as an extra I would like it to remember the normal of whatever surface is attached to so new objects can be aligned perfectly to the surface. :)

Added subscriber: @ideasman42

Maybe of interest regarding cursor grabbing:
http://lists.blender.org/pipermail/bf-committers/2004-July/006863.html

Probably design and situation is different, just to note it was done once before.

Added subscriber: @BartekMoniewski

I knew someone must have thought about it before :)

I can see the biggest issue with it from that thread: having to deselect objects so they're not grabbed with the cursor. Adding an op for modal set is probably the best solution (it can still have lock axis, snapping, etc).

I wrote it in another task, but this really belongs here:

After having cursor placement on Alt-RMB for a while now (and a context menu on RMB) I like this solution less and less - this is an important function, hiding it under obscure shortcuts that use modifier keys would be very bad for discoverability/learning curve.

So I'm starting to think that a Cursor Placement Tool could be a good addition to such a shortcut.

Workflow Example:

You click on the Cursor Placement Tool's button (currently the best spot for it is the 3d View's header), mouse cursor changes signifying that the Cursor Placement Tool is active, you click with LMB in the viewport to place the cursor - this does not exit the tool mode, so you can for instance rotate view and click again - and when you are satisfied with the new cursor placement you press RMB to exit the tool mode or press the button again.

Now I think the shorcut alt - RMB would work as shorcut for that tool.

A cursor placement tool would lead to a tremendously slow workflow and would not be beneficial at all imho, forcing tons of unneeded clicks.

Just look at this video and think about having to click the placement tool-> position-> do something-> placement tool-> position-> do something...pain. 3d cursor video

We have draggable 3d cursor now, just need a snapping in object and edit mode. (key + secondary mouse button to activate snap still the best and quicker option imho)
https://developer.blender.org/rB26eae6315c05526021b93d9e32b064208a9d7ab8

@marcog Sorry, I formulated my example badly - a direct shortcut for placing the cursor would be still available (like Alt-RMB that @00Ghz mentioned). I just think that a mouse button + modifier key would have too low discoverability. With a tool, a user could after a time switch to the shortcut that would be described in the tool's tooltip. Such a solution would follow a paradigm I described here .

Also - the motivation for this type of cursor placement is a RMB menu. I'm testing one (rRMB) for a while now and it just works.

After having cursor placement on Alt-RMB for a while now (and a context menu on RMB) I like this solution less and less -

this is an important function, hiding it under obscure shortcuts that use modifier keys would be very bad for discoverability/learning curve.

I think I disagree @plyczkowski. I don't disagree that it's harder to discover, it is. But I'm not so sure that's a bad thing. Currently the cursor is almost too easy to discover, leading to annoyance and problems when the user doesn't yet know what the cursor does. And let's face it, NO ONE coming to Blender for the first time knows what the cursor does.

By putting cursor placement on ALT/SHIFT+LMB/RMB we keep it very easy to access, but out of the way of new users and vital mouse functions (like selection).

However, with that said, having a Cursor Placement tool would make the act of snapping much simpler. For example, pressing ALT+RMB Drag to start placing the cursor, and then having to hold CTRL to snap (assuming snap state is off) just sounds awful.

However, with that said, having a Cursor Placement tool would make the act of snapping much simpler. For example, pressing ALT+RMB Drag to start placing the cursor, and then having to hold CTRL to snap (assuming snap state is off) just sounds awful.

Nah, when the Cursor Placement tool would be active, a simple LMB would place it. So, activate the tool via button, press and hold LMB to drag cursor, add Ctrl to make the cursor snap to elements.

Scratch the shortcut using RMB though, that made no sense. We need something with the left mouse button. Maybe something like - press q (for example) to activate the CP tool (and place the cursor via LMB), but hold q to enter it temporarily, and exit the tool when q is released?

Cursor snap to elements will be very nice feature. This will replace many cases of using shift+S menu.

well even now you could snap the cursor based on depth of the 3D view and it will attach to whatever is underneath it, although it is not very smart, like snap to center.

Most of the time I snap it one vertex. THen to edge loops (snap to center) and that probably need to be run via snap menu.

You can assign individual shortcuts to each of the Shift + S functions.

I have Ctrl + for Cursor to Selected, Shift + for Selected to cursor, and Ctrl + shift + ` for Selection to Grid

Saves you quite some steps.

Added subscriber: @DataDay

Added subscriber: @Luarvik

Added subscriber: @zeauro

In #37420#64, @PawelLyczkowski-1 wrote:
Nah, when the Cursor Placement tool would be active, a simple LMB would place it. So, activate the tool via button, press and hold LMB to drag cursor, add Ctrl to make the cursor snap to elements.

Scratch the shortcut using RMB though, that made no sense. We need something with the left mouse button. Maybe something like - press q (for example) to activate the CP tool (and place the cursor via LMB), but hold q to enter it temporarily, and exit the tool when q is released?

I know that many people don't use a lot 3d Cursor with LMB because it is not precise.
But it is quick. For this reason, 3D Cursor is interesting for modeling tools and it is used as a reference for some modeling tools.

Spin, Bend, Warp tools would become slower modeling tools if 3D Cursor placement needs, each time you have to use it, an On/Off activation.
http://youtu.be/jnSK7162mNw?t=2m9s

We already need a shortcut to use 3D cursor as a pivot.
interest of 3D cursor as a pivot transformation is that it can be used for a multiple objects selection.

I think that it would be acceptable to have 3D Cursor move item in shift S menu if it will be a built-in pie menu.

I agree a toggle action is only acceptable if we have an hold/release keymap.
Button seems a bad choïce.

Added subscriber: @TARDISMaker-2

Added subscriber: @btolputt

I'm going into feature request territory here, under the assumption 'if something deserves to be done, it deserves to be done well'.

Here's my suggestion; Put it on a hotkey, let's take q as an example (completely random, don't pay too much attention to it for now):

Pressing Q once toggles the display of the 3d cursor.
Holding Q and clicking with LMB places the 3d cursor (this is the current behaviour).
Holding Q and dragging with LMB grabs the 3d cursor, during which you can hold ctrl to snap (defaults to verts, or should we follow what the user has set in snap settings?) and ctrl-shift to snap in smaller increments. This follows the design of other modal tools.

If it's modal, we can use other hotkeys as well, but more importantly: the user can set their own.
I might for instance want this:

Holding Q and doubleclicking on a spot over a mesh places the 3d cursor at the spot, on the surface of the mesh.

In addition to all of that I don't mind @PawelLyczkowski-1's suggestion of making it a tool at all, as long as hotkey-activation as I describe will still be possible.

I use the addon 'Enhanced 3d cursor', and a lot of this has been implemented already. I couldn't go back, the dragging and snapping make a big difference in usability!

Here is one to decrease the amount of hotkeys: combine Box, Circle and Lasso select into a single Area select, activated with LMB click-and-drag in the 3d view, with a menu of the chosen type on the header. Shift add to selection, Ctrl remove from selection.

I really, really like having paint-select be standard when dragging within the mesh, box or lasso select when dragging outside of the mesh.
Even if this isn't the default behaviour, I'd like to be able to set this up. Here's a gif of how I've got selection set up in another program:

Always one key for adding to a selection, one key for subtracting from a selection, and without modifier keys the new selection overrides the old one.

Here's how that works with multi-selection in that setup:

Again, I'm not suggesting this as a default, but a system that's flexible to allow this to be setup through the keymap would have my preference.

edit: ofcourse, even with this setup I'd keep it possible to invoke box/circle/lasso select through a hotkey, so those who prefer using them to select things inside of a mesh aren't limited. This was just a perfect way for me to make selection very fast, and make use of the --formerly useless-- empty space. The context-sensitivity of this system made it very easy to adjust to.

Just wanted to leave a small update here to say that @PawelLyczkowski-1 and I are actively working on the first version of the new keymap. The goal is to have a simple version ready for active testing during 2.74 dev.

Thanks to everyone that's submitted feedback and ideas. At this point we need to step away from the committee and actually build a first version.

Added subscriber: @DuarteRamos

Added subscriber: @ManuJarvinen

Added subscriber: @EjnarBrendsdal

Nice discussion on the curser snap, pivot etc.

As for solution to transform widgit obscuring selection:
The widget only works with click-drag.
Why not allow selecting what's behind the widget when only single-clicking?

The widget only works with click-drag.
Why not allow selecting what's behind the widget when only single-clicking?

@EjnarBrendsdal That actually sounds like it could work. Maybe Julian can prototype this behavior.

Added subscriber: @JulianEisel

@PawelLyczkowski-1, you can already try that by setting 3D Manipulator operator (view3d.manipulator) to event type "Tweak".

I think this would be a great candidate project to move forward for the great Blender 2.8 development leap.

I am all for left-click select, but that is easy for a user to change if he wants to; my main concern about any new keymap is that modifier keys are used consistently.
In many parts of Blender [Shift] key is already used as some sort of "Plus" or "Add" or "Augment" of an operator, while [Alt] is the "reverse" or "opposite" operation say like:

[ H] hides [Alt+H] unhides or
[ P] parents while [Alt+P] clears parent
[ G] modes [Alt+G] clears transform or
[ M] moves to layer [Shift+M] moves to several layers, etc. you get the point.

This should be made as consistent as possible across all tools and operators over all editors, including obviously all selection modes, so that if one either enters the lasso select mode, circle select, border select or regular Click Select, [Shift] would always exclusively add to current selection, [Alt] would only remove from current selection, and maybe use [Ctrl] to toggle (?), conflicts with loop and ring select o others in other editors may arise and would have to be addressed.
Anyway whatever you choose to go with, the important thing is to make it consistent so an unsuspecting user would know what to press.

I posted a proposal about it in the wiki some time ago)

Added subscriber: @AndersonOmori

This is task being linked as a record that we are moving to left-mouse-select default.

When did this happen? Is this noted in meeting minutes or agreed on by maintainers?
Is anyone taking responsibility to resolve all remaining conflicts with LMB select?

(As far as I can see - neither Ton or any active core developers posted on this).

"That being said, I think there is some agreement that we will make left click select the default, Ton agreed with it as well as long as we have a well supported way of switching to right click select."
- Brecht

It's been mentioned/linked in the BA forums by multiple developers / team members now and the preliminary test scripts/keymaps seem based on that presumption too (though digging them all up would take some time).

(Note: This was posted in response to the original comment, not the edited one above)

I was searching exactly for that quote myself, but you beat me to it.
I read that too some time ago, now I did not check my sources and I cannot verify that Ton actually said that, I just assumed it is true and he did give his blessing. :)
Anyway left click select as default or not is a huge change and one that is bound to be both controversial and troublesome, I was more concerned about consistency

The entire new keymap is going to be a huge change, controversial, and troublesome. ;)

For what it's worth, I don't think we're going to find a public statement by Ton on the matter. He has stayed out of (public) discussion on the new keymap since the creation of the UI Team. There might be an IRC log with his commentary or a private email, but he's been pretty scarce on the tracker, blog, and forums about controversial issues like this.

That said, I don't think anyone is actually questioning Brecht's honesty here. If he says Ton agreed with it - I'm pretty sure that Ton agreed with Brecht on the matter (at least at the time). Whether he does now is something else, but doesn't seem to be what Campbell was asking about.

@ideasman42

conflicts with LMB select?

For me one of the bigger roadblocks is the dope sheet. You have either selection or scrubbing with LMB, and no possibility of area select with LMB-click-on-empty-and-drag.

That's why I would go with a more standard solution regarding dopesheet scrubbing (maybe along a dopesheet and timeline merge), a separate area for scrubbing with a handle:

Let me know if I should open a separate design task for that. I'm not animating that often lately, a pro would have to speak about that.

@PawelLyczkowski-1, there are quite some conflicts, which is biggest depends on your POV, did anyone collect them all?

There is:
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Left_Mouse_selection_conflicts_with_defaults - but its not some comprehensive list (just noting that its an issue).

In #37420#333464, @ideasman42 wrote:
@PawelLyczkowski-1, there are quite some conflicts, which is biggest depends on your POV, did anyone collect them all?

Not that I'm aware of.

I guess you're referring to my recent post on BA , worded like this:

Yes, plan is to change to left-select as default. There was never really made an 'official' decision about it, but almost everyone agrees on it.

It's obvious that there's quite some lack of communication within the UI team and to the outside, and I'd say this is a case where bad communication got in the way of a final decision making process. Other than Brecht's old comment here, things weren't really communicated to the outside, but whenever we (UI team members) talked about plans regarding keymap revamp etc, we handled it as pretty much given that we'll switch to LMB default selection (at least it seemed like this to me).

However, my BA comment was a bit too firm about it, let me put it a bit more vague: Yes, common opinion from UI team members and users involved appears to be LMB selection as default. There was never really made an 'official' decision about it, but most members agree on it and current plans aim towards this.

Maybe it's time to actually make an 'official' decision about LMB/RMB selection default and which conditions need to be met in case of a change. This discussion will go on forever if not.

This comment was removed by @ideasman42

Maybe it's time to actually make an 'official' decision about LMB/RMB selection default and which conditions need to be met in case of a change. This discussion will go on forever if not.

Best wait until Ton comes back from holidays first :)

@ideasman42 Thought the same, just forgot to mention ;)

For what it's worth, my understanding of the consensus over many discussion was that we'd move to LMB in the new keymap by default but with the ability to switch instantly as preferred. Technically this is already doable in the current keymap, but there's lots of conflicts and problems. Of of my goals with this new keymap is to resolve those conflicts such that LMB/RMB switch actually works as it should.

If that is successful then it really doesn't matter which mouse button is used, so far as user preference goes.

Even if LMB-select doesn't become the default, better support for LMB setups would be very welcome. I've mostly forgotten how I built my keymap but I remember it took a lot of fiddling (and Paweł's addon).

Absolutely @januz. So long as we successfully use Action / Selection inputs everywhere then it should not be an issue. Most likely we'll run into a few hard-coded areas that'll need resolved, but that'll be tackled when we get to it.

In #37420#333499, @JonathanWilliamson wrote:
For what it's worth, my understanding of the consensus over many discussion was that we'd move to LMB in the new keymap by default but with the ability to switch instantly as preferred. Technically this is already doable in the current keymap, but there's lots of conflicts and problems. Of of my goals with this new keymap is to resolve those conflicts such that LMB/RMB switch actually works as it should.

This is a sensible of course, but its a bit strange to announce a decision has been made regarding a design that doesn't exist.

The new keymap needs to be created, evaluated, iterated on... after that a decision would be made.

If that is successful then it really doesn't matter which mouse button is used, so far as user preference goes.

Disagree that it "doesn't matter" - documentation & educational material tend to follow defaults, add-on developers will choose keys which work best with the default too (currently configuring key-maps for add-ons isn't working well, this needs to be addressed too).

The new keymap needs to be created, evaluated, iterated on... after that a decision would be made.

Yup agreed, which is really where we are at now. At the end of the day the keymap may get rejected and that's okay; but as it is right now the goal has been to create one that uses LMB default.

I think it's pretty obvious that I've done poor job of communicating on this and keeping everyone in the loop, so my apologies for that. Admittedly, this is partly influenced by the overwhelming amount of discussion in other areas which can, and has had a stymieing result on progress.

As it stands right now I'm still trying to finalize my initial version of the new keymap, at which point I'll put it here for more iterative work and discussion.

In #37420#333664, @ideasman42 wrote:
This is a sensible of course, but its a bit strange to announce a decision has been made regarding a design that doesn't exist.

Actually, I always think it a good thing to establish the fundamentals of any planned design changes. Given it was possibly the feature that attracted the most attention & controversy in the lead-up to the establishment of the UI Team & these tracker tasks - I would think the planned setup for the left mouse button pretty fundamental.

I'm actually confused as to why people seem upset/concerned that the UI Team made their goals for the LMB input clear. What is wrong with the UI Team stating upfront that they intend to change the default?

Added subscriber: @JasonSchleifer

Removed subscriber: @JasonSchleifer

I'm actually confused as to why people seem upset/concerned that the UI Team made their goals for the LMB input clear. What is wrong with the UI Team stating upfront that they intend to change the default?

@btolputt it was more of an issue of miscommunication with goals and intents. I've updated both the parent task and this one to better reflect actual goals and status.

Does this mean that the UI Team no longer intends for the defaults to have left-click as select?

Asking about intent here, not for a guaranteed outcome.

@btolputt, of course agreeing on design direction is good (before going ahead and finalizing the design).

However from reading these posts it wasn't clear to me exactly what was agreed on.
And when asking for details... there were still open topics to resolve.

The reason I am replying here is (for all I knew) this would be committed to master right after 2.76 release, with some edits to resolve the major keymap conflicts... and tag all other remaining keymap conflicts as TODO's.

There are many open-tasks, and I don't follow all closely.

So the task is still in the design phase and WIP, thats fine but that should be communicated.

Added subscriber: @bugaevc

Added subscriber: @dongyfeng

As a beginner user, I like LMB select. But RMB select has one clear advantage over LMB select that I simply cannot ignore: be able to select vertices/edges/polygons even if the transform manipulator is on the way. In a ideal world, I have both the LMB select AND be able to select object/components without worry about transform manipulator. Here is my proposal on how to achieve it:

We need a clear separation between the Select mode and Tool mode. Select mode is only for selecting objects/components and it should not show any transform manipulator or sort of things.
When I press a hot key or click a button in the toolbar, I'm in Tool mode. Here is where the manipulator shows. For example, I press G/R/S, I'm in Transform Tool mode.
In tool mode, I have two choices: one for beginner user and one for experienced user.

For experienced/current Blender user:

I press X/Y/Z key, and I can immediately transform on X/Y/Z axis.
I can also press A key to transform on all axis. Note: this is equivalent to press G/R/S and move the mouse cursor.
After I satisfy with the result, I click LMB to confirm the operation. It goes back to selection mode and transform manipulator disappears. Transform manipulator acts as a visual guide in this scenario.

For beginner Blender user:

Since the transform manipulator is shown, I can transform the object/components by dragging the transform manipulator.
After I release the mouse, transform is complete. Transform manipulate is disappear and I'm now in selection mode again.

This approach works for Extrude as well: first select some polygons then press E to enter Extrude Tool, there will be a manipulator shown at the selected faces. I can either press Z key to immediate extrude the faces and LMB to confirm or I can drag the manipulator to extrude and release the mouse to confirm.

Pros this approach:

LMB select is natural for most users especially beginner users.
Since there is no manipulator in Select mode, users can select object/components without worry about transform manipulator on the way just like RMB select user does.
Blender's most distinct hotkey workflow is preserved.
Toolbar button

Cons of this approach:

Experienced Blender users will have to hit two keys instead of one key to use a tool. For example, G + A instead of G; E + Z instead of E.

As a beginner user, I like LMB select. But RMB select has one clear advantage over LMB select that I simply cannot ignore: be able to select vertices/edges/polygons even if the transform manipulator is on the way. In a ideal world, I have both the LMB select AND be able to select object/components without worry about transform manipulator. Here is my proposal on how to achieve it: 1. We need a clear separation between the Select mode and Tool mode. Select mode is only for selecting objects/components and it should not show any transform manipulator or sort of things. 2. When I press a hot key or click a button in the toolbar, I'm in Tool mode. Here is where the manipulator shows. For example, I press G/R/S, I'm in Transform Tool mode. 3. In tool mode, I have two choices: one for beginner user and one for experienced user. For experienced/current Blender user: 1) I press X/Y/Z key, and I can immediately transform on X/Y/Z axis. 2) I can also press A key to transform on all axis. Note: this is equivalent to press G/R/S and move the mouse cursor. 3) After I satisfy with the result, I click LMB to confirm the operation. It goes back to selection mode and transform manipulator disappears. Transform manipulator acts as a visual guide in this scenario. For beginner Blender user: 1) Since the transform manipulator is shown, I can transform the object/components by dragging the transform manipulator. 2) After I release the mouse, transform is complete. Transform manipulate is disappear and I'm now in selection mode again. This approach works for Extrude as well: first select some polygons then press E to enter Extrude Tool, there will be a manipulator shown at the selected faces. I can either press Z key to immediate extrude the faces and LMB to confirm or I can drag the manipulator to extrude and release the mouse to confirm. Pros this approach: 1) LMB select is natural for most users especially beginner users. 2) Since there is no manipulator in Select mode, users can select object/components without worry about transform manipulator on the way just like RMB select user does. 3) Blender's most distinct hotkey workflow is preserved. 4) Toolbar button Cons of this approach: 1) Experienced Blender users will have to hit two keys instead of one key to use a tool. For example, G + A instead of G; E + Z instead of E.

The point of the manipulator is to avoid having to use a hotkey, and to give beginners an easy way to get used to the interface. Making it show up when you press one of the transform keys, kind of (imo) get's rid of the purpose of having them there.

Also worth mentioning that it sounds like you're trying to turn the transforms into a full on modal mode where it's probably not really necessary.

Just so you know, you can disable the manipulator. On the default Key Combination, just press Ctrl+Space, and it will get rid of it. There's also a button in the header of the 3D view that does exactly the same thing.

The point of the manipulator is to avoid having to use a hotkey, and to give beginners an easy way to get used to the interface. Making it show up when you press one of the transform keys, kind of (imo) get's rid of the purpose of having them there.

Manipulator can act as a visual aid for hot key users. When I use G/S/R to transform, I don't know which axis I want to transform. So every time I have to look at left bottom of the 3d viewport to check if I input the right axis.

Also worth mentioning that it sounds like you're trying to turn the transforms into a full on modal mode where it's probably not really necessary.

Yes and why not?

Select mode to select vertices/edges/polygons
Activate tool by hotkey, menu item or toolbar button
Manipulator shows with visual aid. For grab/rotate/scale, visual aid can be X/Y/Z. For extrude, visual aid can be Z.
Move mouse cursor to a convenient place and press a second hotkey to enter modal mode.

Select mode to select vertices/edges/polygons

Activate tool by hotkey, menu item or toolbar button

Manipulator shows with visual aid. For grab/rotate/scale, visual aid can be X/Y/Z. For extrude, visual aid can be Z.

Move mouse cursor to a convenient place and press a second hotkey to enter modal mode.

Maybe I can eliminate the second hotkey to better align with the current workflow.

In Step 4:

If an tool is activated by a hotkey, it enters modal mode immediately. This is exactly the same as the current workflow.
If an tool is activated by a menu item or a toolbar button, then you will have to single LMB click somewhere(anywhere) in the 3D viewport to let blender know your mouse cursor starting point. After that, it enters modal mode.

Added subscriber: @JasonSchleifer

Added subscriber: @ACap99

Changed status from 'Open' to: 'Archived'

There were various Blender keymap changes in 2.8 to improve consistency, with no further changes planned to shortcuts.

For bigger changes, the industry standard keymap is still under development: T5496, and for left-click select there will also be changes to accommodate the tool system. But this is also handled in other tasks.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Default Keymap: Review and/or Rework Selection #37420