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.

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

1. Add Box Select to the Drag Action dropdown inside the transform tools
2. Add some new way to make transform gizmos visible while other tools are active

I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other.

Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion.

We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there.

This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

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

some users would like to be able to do box select while the transform gizmos are visible.

Yes. This is truly needed indeed, and I'd go with option #1 too.
But please consider adding to the Drag Action dropdown the Lasso and Circle select as well, so we don't get limited to just Box select. Like:

There are situations where the Lasso or the Circle are more handy than the Box select, so it would be great to have access to those as well.

Yes, for sure, those could be in there too.

Great. 👍

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

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

Yeah, many users are waiting for this ability.
And yes, solution #1 seems to be the best.

Thanks for tackling the issue of not being able to box select while in transform mode, very welcome development!
Tried to replicate this myself by doing different things to the keymap before but I kept running into different problems, so quickly gave up. Glad to see it will officially be remedied.

Out of the two options, I think #2 is ideal, but #1 would be the quick(er) fix.

It's fine for hotkey users who enable tools via hotkey, but it's a little weird selecting a tool and seeing the manipulator going away.
For instance, the expected behavior for people coming from other programs might be like how Maya does extrusions: https://youtu.be/3mvIl3nyz7Q?t=31

If I extrude, being able to also quickly adjust transformation of that extrusion without having to switch tools is a much more fluid workflow.

Also, customized manipulator per tool giving quick access to useful tool options in the viewport would be fantastic. For tools where transform manipulator would actually hinder (though I frankly can't think of one), it could be hidden when it makes sense. But even with Shear, for me, it's welcome to have the transform manipulator.

Another approach
Or maybe another approach to explore is if the user can [Shift]+select/enable multiple tools? It would basically allow for one tool per category.
For instance, Shift selecting Transform, Extrude, and Box Select. If user selects the Knife tool, Extrude would be toggled off, but Transform and Box Select are still enabled.

One more thought would be that PS And Affinity use shift+shortcut to do the toggle. E.g w to change to select tool. Shift+w toggles select mode?

@William Reynish (billreynish) Could it be possible to place the 3D cursor at the world axis when Shift+RMB clicking an empty area? Effectively creating a context-sensitive way to reset the cursor orientation. I think that this could be implemented by creating a secondary orientation method using empty selection.

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

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible. I see two ways to do this:

1. Add Box Select to the Drag Action dropdown inside the transform tools
2. Add some new way to make transform gizmos visible while other tools are active
   
   I strongly prefer solution #1. It fits neatly within the current paradigm and causes no conflicts. Solution #2 can potentially cause lots of confusion and conflicts, because what if you then have the transform gizmos enabled while enabling the Shear tool, for example. You get two gizmos on top of each other.
   
   Also, from a user POV, the mental model is that the gizmo is part of the tool. Seeing the Move tool gizmo when the Move tool is not active will just create all sorts of confusion.
   
   We already have the concept of Drag Action (some apps call this setting 'Haul') so all that is needed is to add selection there.
   
   This is much more like what other DCC apps do. In short, if we are going to add this capability, #1 is how I think we should do it.

Maybe this deserves a new separate task, don't you think?
I mean, this is truly needed.

Hey, thanks for addressing this. Here's my recommendation.

Another thing to discuss related to the keymap, is that some users would like to be able to do box select while the transform gizmos are visible.

I think dragging on a blank area action should not be limited to Box select. The blank area drag action should use whatever selection method is active on the left-side toolbar. So if I choose lasso select mode, then activate the move gizmo, then start dragging on a blank area, I would expect a lasso selection to start. Here it is in action in 3ds Max.

I was able to tweak the current keymap in Blender to achive this functionality to some degree. See here, (first the original functionality, then my tweak):

The problem is that I can only specify one selection mode in the keymap editor (either box, lasso, circle). It would be ideal to have for example a 'view3d.select_modal' operator that uses whatever selection mode is active on the left-side toolbar.

1. Add Box Select to the Drag Action dropdown inside the transform tools

If such an operator were available, I think most of the problems would go away, and you wouldn't need an extra dropdown on the status bar, because the active selection method is already indicated on the left-side toolbar (see image, sorry for the serial-killery lettering :) )

If I as a user took the time to pick a selection method on the toolbar, I don't want to have to specify it at yet another place on the GUI, especially if I can cycle through the selection methods with a shortcut (also worth a recommendation, but that's another story :) ).

I have another thinks, like maya user, I love possibilities with move, scale and rotate gizmos, when I tweak on empty area and have access to grave scale etc. on maya that’s works by tweaking on empty area with middle button, but tweaking with lmb works like box, lasso etc. selection. With shift you extend selection and with Ctrl you deselect. Can create some gifs if you need that.

I use maya viewports navigation now so I have mmb free for me. But if it will be possible to tweak with some hotkey and access to gizmos middle round functionality on blank area it will be awesome for new blender users.

@ThinkingPolygons (ThinkingPolygons)

This is actually very easily achieved with some minor keymap tweaks.

Selection (box, laso) from the empty space.
Move, scale and rotate only when you click and drag on the object. It should be optional at least.
In Maya you can choose the type of interaction as blender with the middle button.

What I can not fathom is why the left click remains inaccurate , when the right click is not
When vertices fall under a part of the transform/move gizmo these are perfectly selectabnnle with the right click approach , the left click is not
See screen shot , the vertices that have boxes around them are not selectable with mouse click ,
I honoustly can not believe this is not a priority.

@ward (gentleclockdivider)
it is a priority, which is why it is mentioned in this task already. It’s the first item under the 3D View section even.

Hello,

In Pose mode + Weight Painting, selection of bones is now on CTRL + LMB,
but how to select multiple bones ? Seems SHIFT + CTRL + LMB doesn't work

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

In T57918#644565, @Christophe (StroBlend) wrote:

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

Shift-Click is used for constraining to two axes when using transform handles.

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

Shift-Click is used for constraining to two axes when using transform handles.

I don't get it... To me shift is used to do fine adjustment when using transform handles. We have the little square on the gizmo if we want to constraint 2 axes. Also when we are doing the transform, we are not doing the selection. Transform is after the selection (once you clicked on the handle). Before that Shift is to add something else to the selection.

In T57918#644565, @Christophe (StroBlend) wrote:

Since this issue occurs only when you try to do multiple selection right ? Why not de-activate or hide the gizmo when hold shift ? It can be a good way to fix it what you think ?

This issue also occurs when trying to select a single vertex that is under the gizmo, so this would be another reason to stay away from using shift.

@Campbell Barton (campbellbarton) and @William Reynish (billreynish) the key binding for Offset Edge Loop Cut should be changed from a "Mouse>Left>Press" event to a "Tweak>Left>Any" event like that used in loop slide. Right now it is impossible to make a new selection with that tool active.

@Dan Pool (dpdp) yes. We also should make it so you can click to select and shift-click to select more even when clicking on top of the gizmos.

We can do this by differentiating between a click event and a drag event, as we already do outside the gizmos.

During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue.

It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys,

So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious:

Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here.

@Brecht Van Lommel (brecht): Depending on how you look at it, just modifying the marker area a bit could solve the issue?

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

During the work on the Industry Compatible Keymap, I discovered that we aren't actually all that far off from solving the left-click animation player issue.

It's already possible to use the Marker area at the bottom of the animation editors to scrub the playhead, while keeping the rest of the editor for selecting and moving keys,

So, 'all' that's needed then, is to make this marker area more visually prominent, so that it's more obvious:

Here I moved it to the top, and added the frame numbers there too. This way it's more obvious that you can drag the playhead here.

@Brecht Van Lommel (brecht): Depending on how you look at it, just modifying the marker area a bit could solve the issue?

Looking good!

In addition to that top area for the playhead, it could have some keystroke assignment that transforms EVERYTHING in a scrub area.
While you hold [KEY], you can drag anywhere on 3D View or Animation editors to scrub back and forth. It's very handy for animators not having to point at somewhere else to scrub. Just press a key and scrub right where you (your pointer) are.

For instance, it could be like:

Quick press [SPACEBAR]: Playback/Stop Animation
Hold [SPACEBAR]: Click'n'drag to "scrub anywhere"

@William Reynish (billreynish) the design for the marker area is nice and appealing. One thing though, in the graph editor, there are two of these numbered sliders (horizontal and vertical). Would the design of the vertical slider change as well, to fit the overall style?

@Ricardo Drehmer (rdrehmer)
Sure, yes, that kind of thing is in fact already possible to set up inside the marker area.

@Matjaž Lamut (lamoot)

It could be solved like so?

Either next to scrollbar

Or opposite:

Has the advantage of not using vertical text too.

As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor.

Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors).

How would the user adjust vertical position of the time slider/cursor?

1. Through the additional vertical area.
2. Through the horizontal area, where you can adjust the frame as well as move the cursor up-down.
3. A combination of the two, where both areas allow you to scrub up-down and left-right?

In T57918#655571, @Matjaž Lamut (lamoot) wrote:

As far as my preference, I'd go for values next to the scroll bars. It's close to the list of fcurves, which makes it's easier to glance at rather than at the other end of the editor.

next to it, sure, just not on top of like it is now., but i do like how @William Reynish (billreynish) 's proposal looks, and maybe make the scrollbars a bit thicker and more obvious (in general), for us tablet users is very hard to use the new ones because the area to click is very small.
and regarding the scrollbar particularly in time editors, I tend to forget it even exists because its sort of hidden.

Thinking about this some more, you don't only scrub through time in the graph editor but also up-down along values. The time indicator is also a cursor. I mainly use it when I wish to transform curves from a specific pivot (like you'd use the 3d or 2d cursors in other editors).

How would the user adjust vertical position of the time slider/cursor?

1. Through the additional vertical area.

yeah why not?

2. Through the horizontal area, where you can adjust the frame as well as move the cursor up-down.

that could work

3. A combination of the two, where both areas allow you to scrub up-down and left-right?

better.

or maybe we leave that as secondary functionality, and use the mouse cursor as default pivot for scaling keyframes in the editor, and though it might be a tad less precise, it'd be a much much faster workflow.

anyways, it all seems to be going the right direction.

I think change frame in the animation editor types should be left click instead of right. It doesn't make sense for the selecting and changing of a frame to be right click when selecting an object or buttons is generally left.

@EitanSomething That's what the top high priority item is about "T63193: Animation Editor Scrubbing Area."