We use currently the right mouse to drag the timeline in the animation editors. Since left click is already mapped to drag the keyframes around. The idea is to find a solution to have the left mouse button for both actions. A job for the experimental keymap.
The following ideas files and conversation is from the old Bforartists tracker:
I had a chat on facebook with a talented Blender user here in Colombia, and he likes the Lclick default, BUT didin't like how it was inconsistent in the Dopesheet, Timeline and Grapheditor (possibly in the NLA too), meaning the changes are superficial as if Blender changed to "Left Click" in the user preferences, which is not enough elsewhere in the UI for consistency.
He requested (and I'm all for it) to change that default to Lclick drag for the timeline frame change in the Dopesheet, Timeline, Graph Editor and NLA, like most software standards.
Shall we do this in the shortcuts by default?
I already tried. You can either select the elements with left. Or drag the timeline with left. Even with shift ctrl or alt i wasn't able to find a good solution. I heravily dislike when i need to hold a key for standard features.
But you can try if you can find a solution here.
I'll have to look at the shortcut code and check it out, see how it works.
I wonder if making the "Move Keyframe/Element" with CTRL+Lclick might solve this and still keep it standard. I personally have accidentally moved keyframes annoyingly more often than I would have liked on just wanting to move the timeline out of muscle memory.
Ctrl lmb is afaik in use already. And i think there was something with alt and shift too ...
I just remember that i ended in a bigger and bigger mess. And decided to live with the rmb to move the slider then Smile
Sure, I can be assigned. Started tackling it already.
I found I can either use 'LEFTMOUSE', 'RIGHTMOUSE', 'MIDDLEMOUSE', 'ACTIVEMOUSE', 'SELECTMOUSE' on certain functions. I notice that I cannot have the same mouse button for selecting and setting timeline cursors (unless I set an IF/ELSE testing conditional?!). But since the selecting is already heavily dependant on CTRL/SHIFT/ALT already, moving keyframes with a mouse hotkey combo is easy if you are used to normal LEFTMOUSE as "move timeline" from most software - or not... not sure. Maybe reorganizing the combo LEFTMOUSE for select might.. be second nature instead of Left click/right click workflow with a weird Right click to move timeline, or weird right click to select, but more Right click timeline as being weird. Rightclick combo to select/move is also weird and still pretty much a Blender standard.
I am not sure about swapping them around in essence either. Have to think about this one.
How could you make conditionals by testing to see if keyframe is under mouse in Python?
EDIT
I could make selections work with a left double click, and scroll with single left click maybe.. with 'DOUBLE_CLICK' as a general item selection in all views - removing the idea of a Right Click to do things (adding function to like a pie menu or something for common actions/things?)
Thanks. It's better when you assign yourself at a task where you work at. Makes it easier to follow who does what. I've done it for you now. You can grab any open issue at any point and change even the status if required Smile
And i see you start to understand why it's not so easy Biggrin
As told, i had a crack at this problem before too. And ended with using rmb then. That's imo the best solution at the moment.
Ah right. Shall do that next time.
I posted some thoughts and ideas here, to try give a crack to the whole double mouse buttons for Selection/Active workflow that is probably what is confusing people and making things a bit complicat
--
Ok, created a test.
Things I changed:
Lclick + drag = move timeline
DOUBLE Lclick = place timeline
Lclick (on keyframe or handle) = select keyframe or handle
Rclick + drag = move selected keyframe or handle
W = move selected keyframe or handle (like BFA, normal)
I haven't changed the VSE system that much, but the Dopesheet and Timeline and Graphsheet and I think NLA work this way.
I noticed this is good for BFA because..there is a double entry here, you press W to move things, or you select and drag. I prefer the command of moving things intentionally instead of accidentally moving them when selecting. So select THEN move is a safer, solid way of animating (in my opinion). I don't know of other software that allows me to move things without having them selected first in action. It's just logical. This Lclick to timeline makes things just.. more standard, but also give the Rclick + drag to move selection still possible a la Blender (but as a secondary action). Also Rclick CLICK or RELEASE can be used for a BFA Pie menu system later on in life.
Other things you can test out is the outliner:
Lclick PRESS + drag = box select (with Shift remove, Ctrl add, etc working after dragging)
DOUBLE Lclick (not on name) = select what is highlighted
Shift + DOUBLE Lclick = unselect highlighted
It has proven quite useful.
bforartists - full - ver 0.6.py_.zip
Thanks Draise, I will have a look at this solution Smile
Hmm, i had a look at it, and am not convinced, sorry. The solution is not bad. But for me there is no win, but some losses. It's what i have feared.
The User now needs a tutorial for how to move the keyframes. The former solution with RMB to move the slider may be nasty and uncomfortable, but is easier to discover and to use. And now you need a hotkey to move the keyframes.
Other opinions here?
Other things you can test out is the outliner:
Lclick PRESS + drag = box select (with Shift remove, Ctrl add, etc working after dragging)
DOUBLE Lclick (not on name) = select what is highlighted
Shift + DOUBLE Lclick = unselect highlighted
Nice improvements. Border select conflicts with the standards though. It's not a good idea to have different standards across the editors. But traditional border select still works, so i don't mind.
Shift click has a problem though. You first need to border select, then hold down shift to subtract.
Yeah, the Border Select tool then Shift to change the modification is standard use in Blender...=( I tried to make that work easier, but couldn't get it going right. I'll try again later. You have to activate the tool first before hitting a modifier. I'll give that another go.
Not sure about your statement on the tutorial to train the Lclick timeline workflow... out of personal experience and training animators to work with Blender/BFA, I've had to teach the latter - how to move the timeline naturally, the more needed function. Rclick + drag to move keyframe is discoverable as much as moving the time line is in the Rclick, and Lclick to select a keyframe is normal expected use, and Lclick for timeline move is expected use in all animation applications I've used (other than Blender), and timeline change is the more common action over moving a keyframe , ultimately being that the debate be that the timeline should be Lclick, the dominant mouse click for the dominant timeline use. I am.. just thinking about the work with animators that I hire and have worked with and that is what I've noticed. And it's also first complaint they usually have.
I will do an evaluation based of a 3 step animation process me and my team have used, and others I've worked with, a 1. Blocking, 2. Timing, and 3. ANIMATION CURVE EDITING. The latter sometimes is a step we skip entirely for production efficiency purposes.
Goal:
Have Lclick be the dominant selection and timeline change system and Rclick as secondary function based off animation requirements and workflow to make the process organic and easy to train, saving time and animation difficulties.
Original Setup debate:
BLOCKING: Lcick move/pose then Rclick to change timeline makes a double finger alternating mess, less organic, harder to train animators after their other typical software muscle memory with only Lclick. Ultimately making the software less compatible with local animation talent from the getgo without training.
TIMING: Lclick to select and drag keyframe/handle has quick timing and curve tuning, also it is quick to move timing around after Blocking (which arguably is a task less required if animator does good blocking from the get go, making moving keyframes secondary), but this system also creates a finger alternation like mentioned earlier when changing timeline to see how changes look, making animating review slower with holding down Rclick more than Lclick in use and time, or having to play back animation from a time point or beginning with keyboard shortcut or switching to another view/toolbar to run animation controls - specifically normal if you're working from the dopesheet that have no timeline controls (and you know FPS in blender is terrible making playback choppy or very slow so timeline drag is best quick review solution) = stressing the less dominant finger over time for the more dominant action.
ANIMATION CURVE TUNING: Modifying curves and keyframes with Lclick + Drag is easy, organic, and expected use - but from old muscle memory, triggering a timing error is very easy by having/adding selected keyframes then forgetting it was selected and moving, or by just trying to change selection moving old selection when you try move something else by missing a handle/selection then moving the timing of keyframe/old handle, thus moving all those frames/selections out of time from the previous step already established - with workflow being often with the ESC or Rclick at the ready to cancel, or by adding the concept that you have to Deselect before Selecting just to be sure you don't make a mistake, a new selection to move (by pressing A) workflow = adding time to the process by canceling often done from accidental timing changes on finetuning - ultimately adding time to the finetuning process overall; and out of experience I have had experienced to novice animators do this issue more than once where their final animations become corrupt from another user or the same animator accidentalliy moving things around from old muscle memory (instead of checking timeline to check animation/poses) - backlogging previous blocking/timing animation work on the final finetuning step making production even more expensive and time consuming as we fix accidental frame shifts repeating previous work.
Things you'd win with the setup I propose:
BLOCKING: Lclick move/pose then Lclick change timeline to keyframe (with autokey) = fast blocking/posing, organic workflow, compatible wiht other animation workflows in other software.
TIMING: Rclick to drag keyframe without shortcut (feels similar to Rclick to change viewport) = fast (like Lclick + drag of BFA, though needs fixing as mentioned below) with secondary function of a dopesheet/timeline as discoverable as the primary action on a secondary mouse currently in BFA, moving the timline. Also feels like what a viewport Rclick is, changing perspective in 3D, like changing time perspective in the 1D environment of a timeline = creating consistency with the Lclick/Rclick workflow. Lclick is dominant timeline function to review timing, Rclick secondary to move frames/handles (or hotkey like the rest of the UI with W as move anything)
ANIMATION CURVE TUNING: Lclick select then T to change curve type, preserved functionality from earlier, but with added timing security = fast curve finetuning without risking changing timing on selection with work you'd have done in the Dopesheet timing/blocking process - with the option of Select+drag as secondary Rclick for a quick single click editing.
Improvments I can try implement to the proposal:
It may feel like we loose a function from BFA, because we do.. the Select + Drag in one click press. I could try add Rclick PRESS to also select keyframe like Lclick RELEASE so the Select + Drag workflow with Rclick would be functional just like it was with Lclick PRESS + drag originally in BFA - essentially adding the timeline use as priority in Lclick, yet still have Lclick selection on keyframe (added functionality over BFA and consistent with other software) and also have the Rclick + drag functionality preserved from BFA just swapped over as a secondary action. You can see pro's to that mentioned above.
In general, for animation typical use of a timeline/dopesheet is moving the time over a time/frame count marker/time bar with Lclick, then Lclick+drag on frames/handles to move them - but keeping it all Lclick. We can't do that out of the sourcecode design. But it's what animators are used to, and these are the least technical 3D artists I know of... They are not used to alternating mouse buttons - but if they should learn to use the Rclick and alternate, it should be for a secondary action in the animation process - which is changing what they animate with new timing or different handles - not the principal method of how they work, with the timeline change and review hand in hand with the Lclick posing.
Feedback anyone?
I have updated the shortcut layout to fix a bug I found with a test build (the transform.translate/transform.rotate/transform.resize has somehow been somewhat deprecated and sometimes won't work unless I assign the old Blender transform.transform + modal).
I also finetuned the Lclick workflow.
Lclick RELEASE = select
Lclick PRESS and move = move timeline
Lclick DOUBLE = place timeline
Rclick PRESS and move = move keyframe/handle
Rclick PRESS = select keyframe/handle (double entry, still not sure)
Please test, see if that solves the issue that I had on the previous!
bforartists - full - ver 07py.zip
I will close this once I finish checking the Full BFA Shortcuts, then make a duplicate with this system for user choice or personal use and upload it here.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
