Page MenuHome

Left Click Select tweaks and fixes
Open, NormalPublic

Tokens
"Like" token, awarded by ike."Love" token, awarded by NNois."Like" token, awarded by fiendish55."Like" token, awarded by johnsyed."Love" token, awarded by fabioroldan."Like" token, awarded by xrg."Like" token, awarded by michaelknubben."Like" token, awarded by vinc3r."Like" token, awarded by rawalanche.
Assigned To
None
Authored By

Description

Recently, an initial version of the updated approach to the left click keymap was added to Blender 2.8.

This makes it possible to use the active tools, as well as selection, both with the left mouse button. However, there are a few issues still with how it works. Here's a list of things we should improve:

General

  •  In all Editors, it should be possible to deselect by clicking in an empty area. Currently only in the 3D viewport.
  •  It should be possible to click over a Gizmo to select items underneath it, as long as you don't drag.
  •  As a general rule, Ctrl-click should deselect (just as shift-clicking adds to your selection)
  •  We can support a way to do 'tweak' actions (select and move at once) via a new Select (and tweak) tool, that does not use border select.
  • Tweak threshold does not take into account DPI, which may lead to too many accidental tweak events.

Node Editor

  •  Holding Shift to select more does not work in the Node Editor (There's a conflict with Add Re-route, which we need to remove or remap) (see D4055)
  •  In the Node Editor, it should be possible to move more than just one node by dragging, if more are selected
  •  In the Node Editor, We should remap the cut connections shortcut to Ctrl-RMB, to avoid conflicting with Ctrl-LMB used in the Box Select tool (see D4055)
  •  In the Node Editor, there's a conflict between the Box Select tool and dragging the node sockets. Box select should only invoke if outside the node socket threshold.

3D View

  •  In 3D View, we should make Shift+doubleclick toggle loops, rather than always extend (consistent with alt-click behaviour, and makes it possible to deselect loops too)
  •  (Fixed) In 3D View, when using the selection tools, if you drag a box selection in an empty area, it should deselect (already works in Edit Mode, but for some reason not in Object Mode.
  • Move tool drag option for 'None' isn't working T58655

Animation Editors

  •  We should add contextual RMB menus here.
  •  In the Graph Editor, dragging on a handle should move the handle, rather than start a box selection.
  •  In the animation editors, clicking in an empty area should both deselect and set the playhead to that position.
  •  In the animation editors, Shift-RMB should scrub the playhead anywhere
  • 3D Cursor transform should be possible with Shift+RMB (for easy snapping).
  •  In the animation editors, we should make this change, so that dragging in the groove at the top moves the playhead, while the scrollbar at the bottom scrolls. This is needed to make left click both perform selections, and have a way to scrub the playhead too:

Details

Type
To Do

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
William Reynish (billreynish) triaged this task as Normal priority.Sun, Nov 18, 9:15 PM
William Reynish (billreynish) renamed this task from Left Click Select tweaks and fixed to Left Click Select tweaks and fixes.

In 3D View, we should make Shift+doubleclick toggle loops, rather than always extend (consistent with alt-click behaviour, and makes it possible to deselect loops too)

Hi, Shift+doubleclick to toggle loops doesn't seem like a good thing. If you do this, then how we will be able to extend the loops by double clicking?
In softwares where they use the double click to select loops, the shift+doubleclick is always to extend and Ctrl+doubleclick is to deselect loop. This is very consistent, and imo this is how it should work in blender too.

@Regnas (Regnas): You'll be able to do that by holding Shift. Shift-Alt-click to select more loops also works this way. The only described change her is to make the double-click feature consistent with the alt-click feature.

Alright.
Shift-Alt-click always felt a little heavy for that btw. I thought for the left click select mode you were willing to simplify that.

@Regnas (Regnas): Yes, it's Shift double-click. I'm confused by what you mean.

Shift mod. key adds to selection when used in companion with LMB Box Select and Ctrl + Box Select removes from so far made selection. But simple point and click with above mentioned mod. keys doesn’t work in consistent way. Shift adds to selection, while Ctrl makes last clicked object selected and active, cancelling the rest of so far made selection.
It should work the same way, no matter what kind of selection is performed - simple click, Box, Lasso, Paint (no-ides-why-it’s-called “Circle”) selection…
Simple click should wipe selection as well. In crowded scene it will start new selection, so as the Box Select does now.

@Andrzej Ambroz (jendrzych): yes, that's why I added that item to the list. It's the third item in the list.

For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators.

Planned

Animation Editors
  • PRESS
    • If over keyframe: select keyframe, deselect all others
    • Else: deselect all
  • EVT_TWEAK
    • If keyframe(s) selected: tweak transforms
    • Else: box select

This one prioritizes quick transform tweak of just the keyframes under the mouse.

Node Editor
  • PRESS
    • If over node: select node, don't deselect others.
    • Else: deselect all
  • CLICK
    • If over node: deselect other nodes.
  • EVT_TWEAK
    • If node(s) selected: tweak transform
    • Else: box select

In this case, quick transform tweak does not deselect other nodes. It's inconsistent with animation editors, but maybe ok given different type of data being edited.

The complex logic with both PRESS and CLICK handling would be to avoid click delays, but is perhaps not needed and only CLICK may be ok.

3D Viewport Select Tool
  • PRESS
    • If over object: select object, deselect all others
    • Else: deselect all
  • EVT_TWEAK_L
    • If object(s) selected: transform Tweak

This tool is for users that want the 2.7x style interaction, like having no tool active.

3D Viewport Box Select Tool
  • CLICK
    • If over object: select object, deselect all others
    • Else: deselect all
  • EVT_TWEAK_L
    • Box select

This one suffers from click delay. It seems unavoidable, unless we accept box select changing the active object which is odd, and also unresponsive behavior in complex scenes where selecting an objects takes a while.

Ideas

3D Viewport Transform Tool with Auto Tweak
  • PRESS
    • If nothing selected: select object, deselect all others, enter tweak mode
  • CLICK
    • If not in tweak mode: select object, deselect all others
  • EVT_TWEAK
    • Transform
  • RELEASE:
    • If in tweak mode: deselect all

Sounds about right.

For my own reference, trying to figure out exact behavior of LMB in various cases. The logic can get quite complicated, and it may be best to implement some of these as modal Python operators that call other operators.
==== Node Editor ====

  • EVT_TWEAK
    • If node(s) selected: tweak transform
    • Else: box select

Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists
If started elsewhere, over empty area or unselected objects, it would still box select.

This is looking quite promising!

Not sure if we can get this level of granularity with the current system, but in the node editor (and where meaningful) EVT_TWEAK would ideally only tweak transform when started from over selected items, even if a selection exists
If started elsewhere, over empty area or unselected objects, it would still box select.

When starting over empty space, the logic as is would always box select. When starting over an unselected node, it would do transform tweak of that single node. We can't have both that and box select.

When starting over an unselected node, it would do transform tweak of that single node.

Yes that is what I meant, sounds perfect that way. Thanks

Dan Pool (dpdp) added a comment.EditedFri, Nov 23, 5:47 PM

We can't have both that and box select.

Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space.

Does this mean that dragging while over an object will box select? Shouldn’t box select only trigger if your drag starts over an empty space.

We could do either. What I'm proposing is to only do box select when starting over empty space.

re:

  • It should be possible to click over a Gizmo to select items underneath it, as long as you don't drag.

This has some implications:

  • Selection will have to happen on click, if only for the cases gizmo's overlay a selection. This may be annoying or seem glitchy if its only happening *sometimes*.
  • Either we limit gizmos never to respond of press/click events (making them less useful) or add a flag for gizmos not to respond to press events, only dragging.

Hmm, yes, I see. This was reported by users who want to keep the gizmo on, but also still be able to select things reliably, without the gizmo getting in the way and stealing the input while using LMB select.

Seems like a fairly basic thing, and is supported in some other apps (eg 3Ds Max)

Some apps solve this by having a fast way to hide gizmos (Maya)

Other apps don’t allow selection while using a tool at all (Modo)

Not sure which solution best.

Thinking more, making the gizmos respond only to dragging is more consistent with the general tools paradigm - the same applies to dragging in the viewport. But, if the gizmos feel sluggish it’s also not nice.

Making gizmos respond to dragging may be OK in general way but I don't think it's something we should enforce in all cases.

Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens.

Depending on how its implemented it could break the view-axis click action where dragging orbits the view and click sets the view axis.

I've just tested 3ds Max, and it happens exactly as Campbell had described. If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release.

I've been using 3ds Max for over 8 years and never noticed anything odd about this behavior. So any concerns about it appearing glitchy are probably not very relevant.

In general, it's crucial that there is very easy and straightforward way to very quickly and comfortably switch between selection tool and transform tools. Selection tool can currently be accessed conveniently using W key, but unfortunately, transform tools shortcuts are hidden behind weird spacebar+letter key combos which are a bit counter intuitive, making switching between transform tools and selection tool feel less accessible. If switching between selection and transforming is so easy it's effortless, then people are not going to be very concerned about switching back and forth in rare cases where this issue appears.

Regarding enforcing dragging. All the transform tool gizmos do absolutely nothing on click only. The only way to interact with them is to actually click and drag. If the issue is something as miniscule as adjusting camera lens using gizmo (which I can guarantee you almost no one will ever do), then simply apply this new behavior only to the tools in edit mode.

Other apps don’t allow selection while using a tool at all (Modo)

This function is a toggle in Modo.

Enforcing dragging means for eg, you wont be able to click and make small changes to the cameras lens.

This could be a good thing? Fewer possibilities for input error then.

If cursor is both over a gizmo handle and selectable item, then on click (mouse press and release) without cursor being moved, item is selected. When the mouse cursor is just on a selectable item, without gizmo on top, then the selection already happens on button down, not after the release.

That seems like a solution that would work. There are a lot of ifs and buts making it perhaps a bit complicated to implement, but it would make things more consistent and reliable for the user: Click to select, drag to use tool.

Hello,

What about Pose Mode + Weight Painting on mesh?
With Left Click Select, LMB is always painting, without any action on bones

It's Ctrl+LMB to select bones.

Uncertain if this is related to this change, but it feels harder to connect nodes now than before. I often activate box select by accident because the node connection hitbox is so small.

@Petter Lundh (plundh) Yes that is a problem. When I test it, it just seems random if it starts a node connection or a box selection. The two are fighting and a random one wins. Instead, box select should only fire if outside the hitbox margin defined by the socket connection.

Drag action in tools should include box, circle and lasso selection. A bug is that none moves the object. And also this type of selection configuration must be shared by all the tools.

@Fabio Roldan (fabioroldan) Yes, indeed, the Drag Action = None behaviour is a bug, basically. Drag Action options could be added to other tools as well, yes.

In Blender 2.8 Beta: When saving a customized keybinding (adding a preset) the "Preferences" box where you can choose left/right click and spacebar Action disappears, I believe this is a bug?

@Thales Davidsen (Thales), it's intentional, these only work for the builtin keymap. For custom presets it's not possible to make automatic changes to the keymap in a reliable way.

@Thales Davidsen (Thales) That's not a bug, no. The keymap preferences are only for the built-in keymap. It's some code in the keymap Python file.

I guess custom keymaps can add this too manually by adding the required logic.

@Brecht Van Lommel (brecht) , ok thats a pitty, but I if its a technical limitation I understand at least Blender have the option to choose left/right moste software do not have this choose anyway. Does this also apply to the Spacebar Action? I have found mysealf changing the keybinding and then later on forgot to change the spacebar action from "Play" to "search". Is their any way I can go back and change the spacebar Action after I have saved the new keybinding preset?

@Thales Davidsen (Thales) You can simply go to Preferences > Input to set this however you want. But this is not really relevant to the topic of improving left click selection.

@Brecht Van Lommel (brecht): Here's a patch to fix three issues in the Node Editor: D4055

  • Shift-click to select multiple nodes
  • Re-route mapped to shift-RMB
  • Cut Connections mapped to Ctrl-RMB to fix conflict with Box Select.