Page MenuHome

Tweaks & Fixes for Improved Left Click Select Support (Parent task)
Open, NormalPublic

Tokens
"Like" token, awarded by Tetone."Party Time" token, awarded by Thales."Love" token, awarded by dpdp."Love" token, awarded by eobet."Love" token, awarded by Moctor."Like" token, awarded by yrrnn."Love" token, awarded by 0o00o0oo."Like" token, awarded by KartoonHead."Like" token, awarded by zaha."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:

High Priority

These are issues we should fix before the initial release of Blender 2.80

Details

Type
To Do

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

Ne Dudgi (nedudgi) added a comment.EditedFeb 15 2019, 8:09 PM

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 ?


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.

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.


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?

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?
Brecht Van Lommel (brecht) raised the priority of this task from Normal to Confirmed, High.Apr 9 2019, 1:44 PM

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?

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

that could work

  1. 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.

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

When did we agree to put this on my desk? I don’t mind spending time on that, but that won’t be an efficient spending, I did not work on this since ages (and not at all in 2.8)…

@Bastien Montagne (mont29), we agreed on this at the homestretch workshop, that you would look at the high priority left click select issues except for the animation scrubbing one.

William Reynish (billreynish) renamed this task from Left Click Select tweaks and fixes to Tweaks & Fixes for Improved Left Click Select Support (Parent task).Apr 29 2019, 8:25 PM
Bastien Montagne (mont29) removed Bastien Montagne (mont29) as the assignee of this task.

Okay so now that we have sub-tasks, no need to be assigned that whole one then. :)

Brecht Van Lommel (brecht) lowered the priority of this task from Confirmed, High to Normal.May 1 2019, 2:01 PM

Since there are subtasks now, only leave those at high priority.

Is it possible to use same hotkey for loop select and pick shortest path, but differentiate them using a number of edge selection? For instance: if one edge is selected, do loop select. But if two edges are selected, enable pick shortest path between those two edges.

@Bob Stern (Nomo) in theory that’s possible yes, although I’m not sure we should do that by default.

In my opinion, it is as intuitive as using box select by holding click and dragging. But I can see that it may not be wanted by some users who prefer to keep things separate.

@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.

the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable.

the text is sideways in Graph/VSE..etc now, is it by design or just due to the new changes? can we get it back to straight so it's easily readable.

It never was straight. It was like that in 2.79 also:

The issue with horizontal text, is that it can eat into the content area. So for now, this is by design.

@William Reynish (billreynish) for 2.80 seems possible though the text is always on top and the scaling bars are on the opposite side, can't see the issue to be honest.

The issue with horizontal text, is that it can eat into the content area. If you go to 10.000 for eg, it takes up a lot more horizontal space then, which the editors need to account for.

excuse me for being thick, but i made a mock-up

and acutally if u have VSE as part of the workspace the vertical text actually gets skewed

Maybe unrelated to this question, but channel numbers and time codes can overlap, and become unreadable: