Page MenuHome

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

Tokens
"Love" token, awarded by bnzs."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.
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

Related Objects

Event Timeline

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

@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) triaged this task as Confirmed, High priority.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

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:

William Reynish (billreynish) triaged this task as Confirmed, High priority.Tue, Sep 24, 12:26 AM