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.

In T57918#557591, @Brecht Van Lommel (brecht) wrote:

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.

In T57918#557595, @Brecht Van Lommel (brecht) wrote:

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

In T57918#557595, @Brecht Van Lommel (brecht) wrote:

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.

In T57918#557613, @Dan Pool (dpdp) wrote:

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.

In T57918#559078, @William Reynish (billreynish) wrote:

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

This function is a toggle in Modo.

In T57918#559090, @Campbell Barton (campbellbarton) wrote:

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.

In T57918#559091, @Ludvik Koutny (rawalanche) wrote:

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.