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.

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

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.

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

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

In T57918#685427, @Zino Guerr (Zino) wrote:

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

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

At this point the graph editor changes (T70634) are too late to do in 2.81 I think, so moving to next.