Well, keyboard layout is a level of customization that assumes correspondance to software system design.
This is why different programs have such different incompatible keyboard layouts - different programs represent different approaches to workflow, and the default level of customization assumes fairly tight support for the functionality of the software and its intended use.
Indeed, there are many software that doesnot even have stencils, and those who have them never intended to have a compatible solution.
Not sure about gizmo solution to this problem, since gizmos systems are usually object-dependent and belongs to 3d space, so it will be hard to control a screenspace system like stencil with it, but viewport widgets system (similar to those that allow to control viewport navigation, which is also a screenspace-related system) seems to fit better.
Sorry, that document shouldâve been already saved and linked to some existing task.
I added it to the description of #115257 - IC Keymap Support.
The proposal document is great but what I was referring to are the current issues with the keymap.
Iâm ok with redesigning the VSE part of the keymap as long as there are no glaring conflicts between the VSE and the other editors.
The animation editors and general playback keymap have a very different keymap atm and will need to synch up with the rest. I think that will be the main challenge.
Iâd also like to compare some more IC softwares like Davinci Resolve. Maybe Final Cut Pro?
Also one of these needs to be the primary source. The tie breaker if all follow different conventions.
Iâm ok with that being Premiere.
The scope of the IC keymap needs to be small to be maintainable. I think itâs very important to:
Follow the same paradigms as the default Blender keymap (not reinventing the software)
Reflect industry conventions where possible (Prevent a steep learning curve and incompatible muscle memory)
Be Active Tool oriented (bigger emphasis on user friendly UI, modes and mouse use instead of shortcut oriented)
Keep the keymap keymap light (Easy to customize and learn. Discovery and accessible use via menus)
These seem to be the some main principles when the IC keymap was made by William Reynish.
iMovie shortcuts are also seems to be different.
It looks like ai designed the table in the same way the rest IC layout was designed though (there were a struggle between max users like Ludvik and maya users like William - maya has been chosen as tiebreaker, so the resulting layout is not very reasonable from the point of view of 3dsmax. But those software users always fight anyway - a conflict between max and maya users was the original reason annual CGBattle event was invented - to define which approach is the most efficient in practice)
Seconded. Basically never trust ChatGPT on any Godot questions. I tried a few times and the basic concepts are mostly right but overall there is so many detail errors. And itâs also no use pointing them out or correcting them. I think Godot currently develops way too fast for ChatGPT to keep up.
Yup⌠Unity does not use those shortcuts, neither in animation editor or timeline.
But besides ChatGPT getting it wrong, it does seem like Da Vinci uses them.
I think J K L would still be better than spacebar. Having play assigned to spacebar is insidious, because it is so easy to hit by accident and not notice for a while. If youâre modeling itâs so hard to notice and many tools donât work with the timeline playing.
Alternatively, Houdini uses the arrow keys. Just as the current Industry Compatible Keymap already does for these functions:
Left and Right: Step frame back and forth.
Ctrl + Left and Ctrl + Right: Jump to endpoints.
All Thats is missing to match houdini are these:
Up: play forward
Down: play backwards
When playing, both Up and Down Pauses
And for full funtionality Ctrl + Up and Ctrl + Down could be jump to keyframe.
As mentioned Arrow keys are already used for parts of Timeline play. I think we should fully embrace and make it intuitive that all play functions are together on the arrow keys.
Currently Up and Down are used in 3D View and Pose mode they are used for walking up and down the hierarchy. But my guess is most animators will visually pick their controls or use an interface like X-Pose-Picker add-on and as is planned in Project Baklava. Going up and down the hierarchy is unintuitive as it only works with FK controls and not IK. Then in Edit Mesh context, Up and Down are used to grow and shrink selection. I personally use this so often that the arrow keys seem too far away. My suggestion would be to mimic Maya and move this to \ and Shift + \. To clarify, \ is the key between Z and Shift on an English keyboard. It lies unused at the moment.
That should free up Up and Down to unify the functionality of playback to the arrow keys.
Edit: I can see I may have confused a discussion in just VSE context with general idea of play function. I still think making it consistent across contexts would be a benefit and so will leave my arguments up.
I agree that Spacebar is industry standard too.
JKL could theoretically be added as shortcuts to VSE editors if that helps but they cannot be universal shortcuts across Blender. But I have my doubts about adding multiple playback shortcuts if a single one already works well.
JKL is not just for playback, but also for shuttle/jog. J+L subtracts/adds speed in incremental steps. So, itâs for quickly playing through the edit or slowly playing back and forth on a strip to find the exact frame to ex. cut.
This is the implementation in the document linked to file:
The JKL buttons are basically an imitation of the Slider of an old Steenbeck editing table, which is why all NLEs have them, as they simply work well for editing a/v:
I believe itâs fine for VSE shortcuts to not be overly constrained by what is done in the other areas of blender. Editing video is a fundamentally different task and workflow than modeling, sculpting, or animating.
Easy fake example just to illustrate: no video editor on the planet would find pressing G to move a clip to be normal.
There are also no any restrictons that prevent them from doing this - itâs just that most video editors donât have modeling abilities, so they dont have to reconcile them to avoid patchwork design.
I donât think a video editorâs lack (or skill) in 3D has any relation to what keys and workflow they prefer to use when editing - so, not sure what point youâre making there.
Under âvideo editorsâ I meant âvideo editing software and its designâ, not âpeople who make videoeditingâ.
To rephrase -
Most of a video editing programs donât have modeling abilities, so their programmers dont have to reconcile such modes in keymaps in order to avoid patchwork design of their videoediting software.
