Shortcuts for Tools (design task) #69992
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
28 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#69992
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
One of the major issues with the tool system, is that switching tools isn't easy enough using the keyboard with the default keymap.
We would like to introduce a way to make the keyboard shortcuts switch tools, without having to click on the toolbar, or opening menus. Here's how we think we can solve it:
We want to leverage muscle memory for shortcuts users already know, such as G, R, S for the transform tools, as well as K for Knife, Alt-S for Move Along Normals, and so on.
Leader Keys
To do this, we use the concept of leader keys (also known as chained keys). This makes it so that tapping (but not holding) a modifier will change the following shortcut. In this case we think we will use Alt to switch tools.
In practice, this means users will tap Alt, then G to switch to the Move tool, and so forth.
Visual Feedback
We want to make it obvious that a leader key has been entered, so that users know that the following key stroke will differ from normal. We do this in a few ways:
Status Bar
Here we can see the leader key, plus the shortcuts:
{F7753731, size=full}
Toolbar
After the leader key is pressed, we can also display the hotkeys inside the toolbar buttons. This gives a more direct association with the tools in the toolbar and their corresponding shortcut.
{F7753735, size=full}
Implementation
Precedents
Added subscriber: @WilliamReynish
Added subscriber: @JulienKaspar
Added subscriber: @ThatAsherGuy
Is the end goal a true vim-style leader key system, or a version of the
wm.toolbaroperator that uses UI overlays instead of a popover?Added subscriber: @Harley
I'm sure you have thought of this, but as described there might be some issues caused by toolbars being per-editor, while the status bar is global. And other related problems caused by the leader key being a press rather than a hold.
Since we are talking about using the tap of a key rather than holding it as a modifier, how long do you wait for the next key? Since the leader key press is transitory, not a hold, when does the following state happen exactly? Is this shown immediately after pressing of Alt or on release? If on release how long does it wait? What if you move your mouse to a different editor? What if you press something else?
If I just press Alt does it wait forever and seem broken if I don't hit one of the allowed keys? Does it time out? Or do I have to hit Esc to exit the mode? If I hit some other key, like "E", does it cause an error message, ignored, or cancel the mode?
@Harley edited the task to include exact behavior, see "Implementation"
@ideasman42 - yes, thanks! Wasn't trying to shit on it, just trying to think it through.
Hmmm, although... seeing that "Alt", "G", "R", and "S" makes me think it might be nice to have outline and background color added to uiFontStyle. Might be a better way of doing that than the event icons since those have to be fixed width.
Added subscriber: @hlorus
Added subscriber: @BrendonMurphy
Don't all tools have hotkeys already? How would addons be affected?
Maybe an Alt/T menu is needed for people who map the spacebar to other than Tools?
Currently it's easy to press spacebar for the menu, then use the hotkeys after for speed/non mouse move.
Is all this dressing really needed? Isn't there enough ui confusion to look at before adding more?
Maybe I'm misunderstanding things here.
While it's definitely important to be able to easily access tools i'm not sure about that solution. I don't see why it's necessary to have a whole new UI concept only to be able to do 2 things that are ment to do the same task:
I'd prefer tools to be directly activated (like in: D4603) and let them behave slightly different when activated by a shortcut. That would mean something like the following:
for tools that need a selection to work:
switching to a tool by shortcut should invoke the tweaking of their primary property when there's already a valid selection (similar to modal operators)
switching to a tool if there's no valid selection, would only activate it without any action
switching to the already active tool could apply the modification and trigger the action again
Pros:
Cons:
I like the idea of leader keys as a general feature, and I could see using
TorSpacebaras a leader for tool-switching (toggling toolbar visibility or calling a different operator withTTorDbl-Spacebar), but I don't thinkAltis a good default. Programs that useAltas a leader, or to initialize a keyboard-based UI navigation mode, tend to use input schemas that aren't directly comparable to Blender's, using either fewer modifier keys in general or a firmer division between mouse-based and keyboard-based input modes. I'd investigate other options, including off-the-wall ones likeTabas a leader orEnterto toggle shortcuts between modals and tools, before getting too far into this.Added subscriber: @renderhjs
@BrendonMurphy, while space-bar tool menu works it's not default.
@hlorus
Whether this is a new UI concept or not is fuzzy, it's a new way of accessing tools but don't think it's so different to other modal states in Blender.
making keys activate tools immediately is too disruptive to existing Blender users and will slow down their workflow. Otherwise, the changes you suggest are fairly larger and would better be posted to #66304 (Tools, Selection & Gizmo design).
@ThatAsherGuy
The exact key can be changed, Alt is convenient because it's easily accessible - similar to other modifiers. Even people who don't touch type can press it without looking at the keyboard.
Having said that, we're not locked into using this key, once implemented we could have different leader keys or user defined leaders keys that perform different actions.
@ideasman42
Thanks for the response, i commented on the task you mentioned.
Added subscriber: @MACHIN3
Added subscriber: @zeauro
Currently, cursor tool is not accessible that way.
C is used for Circle Select.
Toolbar popup uses Spacebar. But Alt tapping does not.
Don't you think it could be a good default to have a solution for this active tool ?
IMO, active tool is superior than shift right click shortcut. Because it supports snapping and rotation options for 3D Cursor in a more intuitive way.
Added subscriber: @AndresStephens
Adding another layer of hotkeys is not a user friendly solution. Writing with accent hotkeys, eg, is very slowing and tiring.
The alternative is to.. improve the keymap editor and unification of identical operators. eg. Transform with legacy transform should be the one and the same tool and hotkey, not two.
Added subscriber: @AlbertoVelazquez
It won't work well with paint vertex, sculpt, Uvs,... Also It have few sense, if the user wants active tools he don't need modal shortcuts. If the user uses modal shortcuts he won't need active tools. Also if the user is advanced he will know to change the shortcut of a active tool.
Is more easy made the old proposal
less clicks and key pressed, problem solved.
Alt, Space now activates the 3D cursor
1ed46bf727Added subscriber: @a.monti
I don't think I understand the reasons behind this proposal to be honest.
Right now we can do the same thing with Shift+Spacebar but that implementation is better imo since, apart from allowing you to press the tool key, you can also simply hover the cursor over it, it's also more visually evident and it's dismissible by moving the mouse away.
Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes.
That doesn't mean they don't want to use shortcuts to change tools.
Some tools aren't accessible directly, Measure or Transform gizmo for example.
Expecting any users (advanced or not) to map tools to their own key bindings isn't reasonable. They might map one or two, but mapping many becomes a hassle to maintain.
It is not a good solution have different shortcuts for same paradigms depending of the mode. It's make more complex the software when you could have easy solutions, like have another option in the splash screen. Also that use alt like that modifier is prone to errors.
But only shortcuts for active tools, that overwrite modal tools shortcuts.
Well, like are not modal tools that shortcuts can be shared by modal and active tool keymaps.
That's not true, an advanced user change a lot of shortcuts. More when in blender2.8 you have change a lot of shortcuts.
Seriously, after having erased the T-shelf and then bring it back to the sidebar. To create the popup to select active tools and then leave forgotten. To put the active tools in the panel of properties..... This seems like another new step of how to delve into the problem of a bad design of the use of the active tools instead of search a simple solution.
As a vim user, I applaud the introduction of leader keys. I hope it will be integrated in a general way that's applicable to every kind of shortcut. I already use the underlined letter shortcuts in (pie) menus to start chaining key presses, and then often continue them in various modal operaters I've made.
It's a great concept. Looking forward to where this goes. Using a leader key to switch tools is a great start IMO.
Added subscriber: @mankysee
Speaking from my own perspective the first thing i've done with the final blender 2.80 was changing the hotkeys for grab/rotate/scale from operators to tools(because I like to get a visual feedback when moving along the axis and I've always been using gizmos where they were available).
I've done this mostly because it's confusing to have two tools doing the same thing but doing that thing a little differently. For example a loop cut tool don't have the same functionality as a loop cut operator assigned to ctrl-r(you can't add more loops using mouse wheel if you click on a tool in a shelf but you can do this if you invoke an operator via shortcut; this makes the tool almost useless for anything other than a basic use btw). That's less obvious with grab/rotate/scale operators and you can have kinda old behaviour if you click and drag outside the gizmos but the inconvenience is still there(kinda-like since for example pressing x/y/z for isolating axis won't work with g/r/s tools).
With adding more shortcuts instead of unifying behaviour across the board between tools and similar operators it will be an even more confusing for new users(I've been always have to explain why default shortcuts for grab/rotate/scale are behaving differently then a same named tool when explaining blender to new users and that was happening more that a few times).
Therefore I think this is a bad idea both for power users who can find their way to change shortcuts by themselves(actually it's not that hard for new users too, it's just one click on a tool) and for new users alike since it brings even more shortcuts for seemingly same things but somehow working differently. The best solution to the problem this proposal is trying to solve would be not to bring more shortcuts on top of other shortcuts but a unified tool/shortcut-operator behaviour with an optional but visible toggle that would show/hide gizmos for all tools/operators used until it's unchecked(more or less like it was in 2.79). So if the toggle is on pressing g would invoke a grab operator(with all the options like pressing x to lock x axis etc) with gizmo and with no immediate dragging applied while the toggle is of the same grab operator would be invoked with a "classic" blender behaviour and so on.
I prefer this Alt tapping that does not introduce visual disturbance like shift space toolbar popover that requires to use two fingers.
But I agree that is a similar solution. Although power user can assign shortcuts, he will not create and retain hundreds of them and will use toolbar one way or the other.
I recently tried to teach 2.80 to newbies. And I have to restrain myself to show them only one way to do a thing, otherwise, I will lost them and not be able to make them learn basics in a reasonable of time.
That is a situation a little bit similar to texture paint mode where brush sliders are available in 4 different places.
That is not a bad thing to give several options to user. But it is prejudice to avoid to make choices for official release.
Not all active tools are directly accessible in toolbar and toolbar popover that requires to make a press click on button of active tool of same category.
With this leader key, all active tools shortcuts in object mode are visible in status bar. But it is no more the case in edit mode, they are too numerous.
I think that idea is good. But I think that should be restrained to some tools and not all; like tool settings bar in texture paint mode should be restrained to some settings of brush and not all.
We need a system to let user customize UI to tell : "For this tool, I use this solution. For that tool, I use another one." And we need same kind of choices done in official release.
Seriously, I will continue to use tilde pie-menu to set a transform gizmo because that allows me to use a select tool or 3D cursor as active tool at same time.
Really, Move, Rotate & Scale active tools are less efficient choice that a user can make.
Use of their gizmo does not allow to select with left click at same time and they can not be combine like when using Transform active tool.
But those active tools with great icons in evident toolbar are the most discoverable way to do things.
It is difficult to say to your student : "this obvious thing that is easy to retain : don't use it. It is slowing you down and limiting you. Use the thing difficult to remember (because it is hidden) or the one with more buttons to click on or force yourself to remember 3 shortcuts and middle mouse axis constraint."
To allow combination of several gizmos, Toolbar should allow to activate several tools at same time. That would be the most simplest way to have an obvious and efficient solution.
Toolbar should display directly all tools unless user creates categories to arrange them.
This alt tapping should be reserve to most common active tools unless user configures the feature in another way.
To sum-up, I think that customization should be added for that feature. Why not adding or removing an active tool by a right click menu ? Like a quick favorites menu for active tools.
Having generic leader keys is fairly trivial to implement now, it's mostly a matter of connecting different parts of the API.
I would have liked if switching tools could use a generic system however there are some details that made it impractical.
I can see you're point, personally I didn't mind using this, however artists I talked to (Julian at the Blender Institute for eg, others too IIRC) didn't view this as a short-cut even though it allows shortcut style access.
Some statements to the effect: "If it's a shortcut why is it flashing a menu?
When I added this it used one finger (Spacebar), however this didn't end up being a popular choice - from what I can tell.
As you say, this has less visual disturbance.
Currently not all tools are accessible (additional annotation tools for eg aren't although all could be exposed).
The issue wit having too many items in edit-mode should be addressed too. Perhaps names could be abbreviated.
Added subscriber: @Grady
Interesting proposal, but I think it would pretty significantly slow down workflow for modelling. Going from being able to grab, rotate and scale with one tap of a key, to requiring two taps of two keys, will mean basically double the number of keystrokes. It also seems out of step with how other similar professional tools work. I understand the example of Firefox uses this system, but other design applications such as Photoshop, GIMP, Inkscape, Krita, etc, don't use that kind of behaviour.
At the very least I think your point about displaying the keymap for a button on the button itself in the UI for the toolbar, should be integrated, otherwise the user really has to go hunting to figure out what the keymap is for something. The keymap for a button could be displayed while the button is expanded and in it's large form, displaying both icon and label. It could also be mentioned in the hover tip for all of the toolbar buttons, so the user can discover the keymap while the buttons are condensed to only display icons. That's something which seems to be kinda inconsistent at the moment with Blender, some UI elements display the keymapping with a hovertext while others don't.
Single key access to directly run operators has not been removed.
This is in this proposal and still planned.
Added subscriber: @Voronium
As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it:
This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.
Added subscriber: @AnadinX
ˆ definitely +1
@Voronium this requires changes to the event system, see D5153: Event system & keymap support for key detecting/ignoring key repeat events
Although there are implications for pressing other keys while a modal operator runs.
G,X,2currently moves 2 on the X axis... it could be made to work I couldn't think of solutions that didn't feel kludgy.I thoght about that as well and it's definitely an interesting approach. One downside i see is that it might be awkward to change operator settings (like axis constraining) while holding a key. The proposal i wrote a bit further up the comments section is similar but relies on the given selection instead of key-hold events.
Anyway in the long run i think it's important to unify the two systems and not just giving the user the possibility to access both tools and operators. Otherwise there will always be the potential for inconsistentcies between every tool-operator pair.
Added subscriber: @Schiette
As a new user starting to learn Blender, I have found the difference between the 'gizmo move tool' vs the 'G move shortcut' for example confusing.
This proposal (alt as a leader key) does add shortcuts to the gizmo, but it doesn't address the underlying problem. I think you could argue that this design makes the program more complicated. A more elegant solution would be to merge the gizmo tools with the traditional transform operators.
There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that.
One way you could look at it is that there's one command (grab) that exists in two flavors: active tool (with the gizmo) and modal.
What if there was a shortcut to switch between modal / gizmo after triggering the grab. It would be especially helpful if it remembered that setting.
I should stress that I haven't been using blender for long so there's a good chance this proposal has severe downsides and/or is unrealistic :)
that's not really merging since these tools and operators have somehow different additional functionality. But for g/r/s tools I've actually done that since for me it's easier to get visual feedback instead of keeping all of the gizmos on all the time.
I am a somehow power user and I do like your idea a lot.
You need a way to access text input during transform, bevel, etc or, remove this feature which is a bigger change.
@ideasman42 I am not necessarily proposing that. Just merely explaining why they aren't 'merged' so to speak.
Added subscriber: @CobraA
I too don't like this, it adds an extra complexity and causes confusion with the clear transform operations..., and like what the others have said, we got the toolbar shortcut. better work on improving that imo.
PS: can we disable this option completely? for us who won't use it.
Added subscriber: @Stan_Pancakes
IMHO, this is a mis-feature at this point. The first thought when seeing this in 2.82 for the first time was "no, no way in hell". And I'm a vim user.
The (shift) spacebar menu already achieves similar functionality, and the argument that "it's not a shortcut because it shows a menu" just doesn't make any sense. There are tons of shortcuts in Blender that do just that, one of the most prominent examples being the X key. Alt, g or space, g is the same two finger motions. No. Difference. At. All. When one knows the shortcut already, they'd press it. When not, they'll look for the hint. In fact, popping it up in a menu where user's eyes are already looking is far more helpful, for obvious reasons. Moreover, status text simply doesn't fit the width (e.g. edit mode with current implementation of this... "feature": on a 1920 display it ends with Alt-S, not even showing what that key does). Moreover, this approach creates ambiguity. For example, with the Alt key as leader by default, in edit mode Alt, e will do a different thing compared to Alt+e, and since it's far less apparent (because the "hint" is down there, not where the eyes are), it's going to create confusion.
A far better approach, IMHO, is to allow easier customization of tool keys, e.g. to make the frequently-used tools (by a given person) more accessible via existing means (the spacebar menu).
How many input paradigms are there at this point? We have shortcuts, shortcuts that call menus, pie menus, pie menus with regular menus in them, menus on press, menus on hold... Now this.
Lastly, as @CobraA suggests, if this... thing does end up in Blender, it absolutely must be disabled by default. It will just confuse new users who will undoubtedly be hitting the "leader" at a regular basis and tripping up on unexpected actions.
Added subscriber: @RayMairlot
Added subscriber: @franMarz
I don't find an option to disable the leader-key in the preferences, or change it. Am I missing it, or is it planned?
I have a lot of key-bindings that include the Alt key (for modeling, orbiting) and I'm experiencing undesirable switches to different tools fairly often.
Added subscriber: @Constantina32
Some feedback after testing this on recent builds (I still think it's a feature that doesn't need to exist, but since it's already here, might as well at least help improve it):
It seems to not take well to key conflicts, although that may be more of a failure of the tool system in general. For example, in the keymap for Mesh, I've rebound the 't' key to Inset Faces. So now when I press t in edit mode I instantly activate the Inset modal operator (easier to reach with left hand than the default 'i' key). But, 't' is also bound to the Transform tool, so both in the Tools menu, and in this new prompt, the Transform and Inset both now list the 'T' key as shortcut, and since the Transform comes before Inset, the alt, t sequence activates Transform tool, instead of Inset.
I can "lose" tools when unbound in keymap. I've unbound the 'B' key in the keymap, since it's redundant in 2.8x. For the Tools menu, this resulted in Select Box tool being available via the '2' key. But with this new prompt, it would seem that made the tool inaccessible altogether - it's not listed in the prompt at all.
Removed subscriber: @RayMairlot
I found how to disable it, search "wm.toolbar_prompt" in the input editor and disable toolbar prompt for both left/right Alt.
Added subscriber: @jenkm
@ideasman42 @WilliamReynish
There are currently some issues.
First, trying to "Rotate View" using the
Trackpad Panand "Zoom" with theCmd + Trackpad Panwill not cancel the leader keys prompt.Second, say I'm going to press
Alt+D, I press and holdAlt, and suddenly I realize I needShift+D, I releaseAlt, and then I can't pressShift+Dright away.So, the leader keys should be activated only by short tapping, but not holding, at least if the Alt/Shift/Ctrl is used as a modifier.
Removed subscriber: @franMarz
Why is this enabled by default? Why is this not mentioned in release notes?
Added subscriber: @Mobin-2
conflicts with emulate 3 button mouse. had to disable the keybinding for this feature to get a reliable emulate 3 button mouse while working.
Added subscriber: @temeddix
+1 for this idea!
Maybe this is the cleanest solution we can achieve. This satisfies both the tool system and the existing users(though now they would need to long-press G/R/S). Now that tool gizmos are complete and selection method got significant improvements(with fallback tools) in 2.82, the only thing left is to apply G/R/S/K/E...to these tools, while long-press leads to operators(just like short-click used to do).
Furthurmore the long-press hotkey concept has a huge potential for other operations as well(i.e. long-press tab for object mode pie-menus)
Wouldn't changing the event handler be worth the effort?
Added subscriber: @1D_Inc
That's correct.
Key-based (two hands no gizmo) modal operators workflow have a goal to be fastest, because it is used for intensive work, while tool-based (one-hand gizmo-related) slow workflow better fits learning process, lowering entry threshold.
Current solution keeps speed-related G.E.A.R.S. workflow fast.
Added subscriber: @EAW
279cc34343This change should be in the release notes, otherwise bug reports will most likely be filed about how it "missing."