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

@Tomislav Corak (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.

@michael knubben (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.

@michael knubben (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 (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.

@Diego Gangl (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 (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

@michael knubben (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.)

@Paweł Łyczkowski (plyczkowski) Then a modal dialog like @xrg (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.

@michael knubben (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.

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. :)

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.

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

@Marco G (marcog) Sorry, I formulated my example badly - a direct shortcut for placing the cursor would be still available (like Alt-RMB that @Vlad Mafteiu Scai (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 @Paweł Łyczkowski (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.

In T37420#64, @Paweł Łyczkowski (plyczkowski) 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.

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 @Paweł Łyczkowski (plyczkowski)'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 @Paweł Łyczkowski (plyczkowski) 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.

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?

@Ejnar Brendsdal (ejnaren) That actually sounds like it could work. Maybe Julian can prototype this behavior.

@Paweł Łyczkowski (plyczkowski), 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)

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.

@Campbell Barton (campbellbarton)

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.

@Paweł Łyczkowski (plyczkowski), 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 T37420#333464, @Campbell Barton (campbellbarton) wrote:

@Paweł Łyczkowski (plyczkowski), 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.

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 :)

@Campbell Barton (campbellbarton) 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 @Diego Gangl (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 T37420#333499, @Jonathan Williamson (carter2422) 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 T37420#333664, @Campbell Barton (campbellbarton) 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?

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?

@Benjamin Tolputt (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.

@Benjamin Tolputt (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.

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?

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

1. Select mode to select vertices/edges/polygons
2. Activate tool by hotkey, menu item or toolbar button
3. Manipulator shows with visual aid. For grab/rotate/scale, visual aid can be X/Y/Z. For extrude, visual aid can be Z.
4. 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:

1. If an tool is activated by a hotkey, it enters modal mode immediately. This is exactly the same as the current workflow.
2. 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.