Default Keymap: Review and/or Rework Selection #37420
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
35 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37420
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?
The current selection tools and methods are all over the board. It's a mix of Left and Right mouse selection in the various editors and even across different tools within the same editor. These all needs to be made consistent and to be carefully mapped to the Select button in the keymap.
This involves:
This needs to all be done very carefully as we have a large number of selection tools in Blender (particularly in Edit Mode). Conflicts are quite common and easy to create. Unless there's a very good reason, all selection tools should be made consistent across all editors.
Note: this will be done in conjunction with #37417, to create a new alternate keymap initially, giving users a chance to test thoroughly before updating the default.
Changed status to: 'Open'
Added subscribers: @JonathanWilliamson, @brecht
Selection Methodsto Review and/or Rework Selection KeymapInitially assigning this to myself to actually implement, but of course will be working with all involved to define what changes are to be made.
Added subscriber: @billrey
As for deciding what to do, the main descision is the Left or Right-click select.
I'm in favour of left click selection for these reasons:
Right click selection is not only a major stumbling block for new users, but also for users who work in a mixed environment switching quickly back and forth between Maya, Blender and ZBrush etc.
Blender was designed for right-click select though, so switching to left click adds some issues:
I think these are solvable issues though.
There's a few more issue with left-click select, see e.g. this video by Sebastian .
These are not solvable in an optimal way and there is a trade-off to be made.
That being said, I think there is some agreement that we will make left click select the default, Ton agreed with it as well as long as we have a well supported way of switching to right click select.
Added subscriber: @cessen
@brecht
The transform manipulator issue is indeed a bit annoying. But I think it's addressable.
The Maya approach is to make turning manipulators on/off extremely fast and convenient. There is a single hot key for each of the manipulators: "translate", "rotate", and "scale". And additionally there is a "manipulators off" hot key. So when a user wants to select something, and their manipulator is in the way, they can just turn the manipulator off temporarily.
The XSI approach encompasses the Maya approach, but also does something else that's cool: the hot for a manipulator can simply be held down to make the manipulator appear, and then releasing the hot key hides the manipulator again. When I used XSI, this was a super nice workflow, and I wonder if we couldn't take that "hold down to show manipulator" approach.
(I still prefer the pure-hotkey approach the Blender takes without manipulators, though.)
RMB for scrubbing actually works really well. I'm not sure why Sebastian harps on it as a bad thing: RMB scrub is a lot better than RMB select from a user-confusion standpoint. It's a little non-standard, but fast to pick up. The only issue might be if we want to introduce RMB context menus down the line. But IMO we can tackle that if/when we get there.
The biggest issue with LMB select, and IMO the only major problem with switching to it, is paint modes. The issue is that in, e.g., Weight Paint mode the user needs to both be able to paint the mesh and select bones. A typical wacom setup, however, sets the pressure-sensitive tip of the stylus as LMB, which means LMB really needs to be used for painting. The other paint modes have similar issues. It's not clear to me what the best way is to deal with this.
Added subscriber: @fahr
Hello Cessen,
I reviewed your youtube videos of your new keycaps and I'm in love with most of it.
I do have a suggestion concerning your use of the alt key. My opinion is that you really shouldn't assign any default functionality to it at all.
There are several reasons for this. First and foremost, the alt key is often used as a modifier for other things. In blender, it's used to emulate middle mouse button, which is actually useful. Many Linux distros, by default, hijack the alt key. Relying on the alt key for default functionality could result in inaccessible features for some.
Additionally, leaving the alt-key alone for the default key map frees it up to allow alternative navigation options for those who want camera navigation to be similar to other apps. For example, one could assign maya-like alt-nav options without disturbing any other keymap. As it is now, if I wanted maya-style navigation, I would have to reassign lasso select (which I use a lot), possibly requiring even more re-assignments in a cascading effect.
Added subscriber: @Januz
I've been using left-click to select for the past month, here's what I found:
@cessen +1 to hotkeys for the manipulators
@fahr I'm not sure this is an issue for most of users. It could be solved by having an "emulated third button" (or Unity-friendly :) ) keymap.
Added subscriber: @GabrielGazzan
I'm in favor of LMB selection too.
I think a good workflow for the Dopesheet/Graph Editor would be:
Review and/or Rework Selection Keymapto Default Keymap: Review and/or Rework SelectionAdded subscriber: @PawelLyczkowski-1
Added subscriber: @liquidape
Added subscriber: @CarstenWartmann
Added subscriber: @xrg
Added subscriber: @michaelknubben
Added subscriber: @marcog
Added subscriber: @ErickNyanduKabongo
Added subscriber: @AditiaA.Pratama
Added subscriber: @Bollebib
Added subscriber: @tommy5
Hi, in my keyconfigs, i use doubleclick to set 3d cursor. It works well.
@tommy5 Sounds good to me!
(as posted elsewhere earlier:)
The only issue I see there is that when you're placing your cursor on another mesh, you're always going to select the component underneath on the first click, losing your initial selection. I'd vote against this, personally.
@michaelknubben I thought that you either LMB click, or LMB double click, but I tested this and you are right, currently it would select first.
This is almost always the case.
Unless you add a small delay (as is done in sticky key hotkeys), which might result in some missed selections, you're going to want to use the double-click where a single-click isn't disruptive. This is why doubleclick to launch a program works well, or double-click to loop-select edges.
Can it be put in the Shift+S menu? Something such as Shift+S -> "Cursor to Mouse" and next spot you click is where it places it. Could potentially even be a modal tool, that you have to ESC out of like Circle Select.
Double-Click I think should "Select Linked." Click once, select a face or whatever, double click select the entire object. If double-click does a loop-select it won't work with the preselection highlighting add-on.
@michaelknubben Yep, you're right, It does select first. Never noticed that, that tells you how much its used. For me, it's usually Cursor to selection and sometimes i set manually XYZ coo. in N panel
@xrg that's exactly what I was thinking too.
Is the 3D cursor used so often to have such a prominent key? It would be better in the snap menu, and the RMB could be used for useful menus (like add).
How often do you add meshes, though? Not often enough for it to take up rmb, I think. The spacebar-menu plugin is a much better fit, although a more context-sensitive menu on rmb with the spacebar menu remaining on spacebar would be much better still.
Basically, have RMB open something like the Face menu when you're in face-selection, Edge menu when in edge-selection etc.
The problem with those current menus is that you can run face-specific tools even in vert-selection mode, when your selection encompasses a face, and that you'd be missing out on the Specials menu, so it would have to be a reorganised menu.
@Januz If it's used, it's typically used repeatedly in a short amount of time, to position it correctly, so it being just an entry in a menu is no good.
@xrg +1 for double LMB click - Select Linked.
Yes, I also like double-click for select linked.
It would have to respect the conventions of regular selection than it currently does, though, as it adds by default, without holding shift.
I'd also want to change those conventions (no toggle, but actual add and remove actions), but that's a seperate discussion :D
@michaelknubben I meant add as an example. RMB menus would depend on mode and give quick access to often used tools/ops (like giving you quick access to specials in edit mode, etc.)
@PawelLyczkowski-1 Then a modal dialog like @xrg mentioned would work better. You click on "Set 3Dcursor" and LMB lets you position the cursor anywhere you want until you hit esc or enter.
Any way to set the double click in the keymap? I can't add to my selection, but I'm fairly new to the keymap editor so I might just be missing something.
@michaelknubben https://db.tt/oUbvQlwY
Thanks, but I'd already done that. I meant that I can select linked by double-clicking, but I can't find a way to add to my selection. Removing works fine, though.
I don't know if it's been suggested before, but what about making the 3D cursor selectable (like an object)? Then the user could use G to position it, along with the axis locks/shift/snapping/numinput/etc. That would be free the LMB and it might even make it easier to use.
Added subscriber: @mont29
Added subscriber: @00Ghz
The 3D Cursor Object sounds like a good idea. Through just as an extra I would like it to remember the normal of whatever surface is attached to so new objects can be aligned perfectly to the surface. :)
Added subscriber: @ideasman42
Maybe of interest regarding cursor grabbing:
http://lists.blender.org/pipermail/bf-committers/2004-July/006863.html
Probably design and situation is different, just to note it was done once before.
Added subscriber: @BartekMoniewski
I knew someone must have thought about it before :)
I can see the biggest issue with it from that thread: having to deselect objects so they're not grabbed with the cursor. Adding an op for modal set is probably the best solution (it can still have lock axis, snapping, etc).
I wrote it in another task, but this really belongs here:
After having cursor placement on Alt-RMB for a while now (and a context menu on RMB) I like this solution less and less - this is an important function, hiding it under obscure shortcuts that use modifier keys would be very bad for discoverability/learning curve.
So I'm starting to think that a Cursor Placement Tool could be a good addition to such a shortcut.
Workflow Example:
Now I think the shorcut alt - RMB would work as shorcut for that tool.
A cursor placement tool would lead to a tremendously slow workflow and would not be beneficial at all imho, forcing tons of unneeded clicks.
Just look at this video and think about having to click the placement tool-> position-> do something-> placement tool-> position-> do something...pain. 3d cursor video
We have draggable 3d cursor now, just need a snapping in object and edit mode. (key + secondary mouse button to activate snap still the best and quicker option imho)
https://developer.blender.org/rB26eae6315c05526021b93d9e32b064208a9d7ab8
@marcog Sorry, I formulated my example badly - a direct shortcut for placing the cursor would be still available (like Alt-RMB that @00Ghz mentioned). I just think that a mouse button + modifier key would have too low discoverability. With a tool, a user could after a time switch to the shortcut that would be described in the tool's tooltip. Such a solution would follow a paradigm I described here .
Also - the motivation for this type of cursor placement is a RMB menu. I'm testing one (rRMB) for a while now and it just works.
this is an important function, hiding it under obscure shortcuts that use modifier keys would be very bad for discoverability/learning curve.
I think I disagree @plyczkowski. I don't disagree that it's harder to discover, it is. But I'm not so sure that's a bad thing. Currently the cursor is almost too easy to discover, leading to annoyance and problems when the user doesn't yet know what the cursor does. And let's face it, NO ONE coming to Blender for the first time knows what the cursor does.
By putting cursor placement on ALT/SHIFT+LMB/RMB we keep it very easy to access, but out of the way of new users and vital mouse functions (like selection).
However, with that said, having a Cursor Placement tool would make the act of snapping much simpler. For example, pressing ALT+RMB Drag to start placing the cursor, and then having to hold CTRL to snap (assuming snap state is off) just sounds awful.
Nah, when the Cursor Placement tool would be active, a simple LMB would place it. So, activate the tool via button, press and hold LMB to drag cursor, add Ctrl to make the cursor snap to elements.
Scratch the shortcut using RMB though, that made no sense. We need something with the left mouse button. Maybe something like - press q (for example) to activate the CP tool (and place the cursor via LMB), but hold q to enter it temporarily, and exit the tool when q is released?
Cursor snap to elements will be very nice feature. This will replace many cases of using shift+S menu.
well even now you could snap the cursor based on depth of the 3D view and it will attach to whatever is underneath it, although it is not very smart, like snap to center.
Most of the time I snap it one vertex. THen to edge loops (snap to center) and that probably need to be run via snap menu.
You can assign individual shortcuts to each of the Shift + S functions.
I have Ctrl +
for Cursor to Selected, Shift +for Selected to cursor, and Ctrl + shift + ` for Selection to GridSaves you quite some steps.
Added subscriber: @DataDay
Added subscriber: @Luarvik
Added subscriber: @zeauro
I know that many people don't use a lot 3d Cursor with LMB because it is not precise.
But it is quick. For this reason, 3D Cursor is interesting for modeling tools and it is used as a reference for some modeling tools.
Spin, Bend, Warp tools would become slower modeling tools if 3D Cursor placement needs, each time you have to use it, an On/Off activation.
http://youtu.be/jnSK7162mNw?t=2m9s
We already need a shortcut to use 3D cursor as a pivot.
interest of 3D cursor as a pivot transformation is that it can be used for a multiple objects selection.
I think that it would be acceptable to have 3D Cursor move item in shift S menu if it will be a built-in pie menu.
I agree a toggle action is only acceptable if we have an hold/release keymap.
Button seems a bad choïce.
Added subscriber: @TARDISMaker-2
Added subscriber: @btolputt
I'm going into feature request territory here, under the assumption 'if something deserves to be done, it deserves to be done well'.
Here's my suggestion; Put it on a hotkey, let's take q as an example (completely random, don't pay too much attention to it for now):
If it's modal, we can use other hotkeys as well, but more importantly: the user can set their own.
I might for instance want this:
In addition to all of that I don't mind @PawelLyczkowski-1's suggestion of making it a tool at all, as long as hotkey-activation as I describe will still be possible.
I use the addon 'Enhanced 3d cursor', and a lot of this has been implemented already. I couldn't go back, the dragging and snapping make a big difference in usability!
Here is one to decrease the amount of hotkeys: combine Box, Circle and Lasso select into a single Area select, activated with LMB click-and-drag in the 3d view, with a menu of the chosen type on the header. Shift add to selection, Ctrl remove from selection.
I really, really like having paint-select be standard when dragging within the mesh, box or lasso select when dragging outside of the mesh.
Even if this isn't the default behaviour, I'd like to be able to set this up. Here's a gif of how I've got selection set up in another program:
Always one key for adding to a selection, one key for subtracting from a selection, and without modifier keys the new selection overrides the old one.
Here's how that works with multi-selection in that setup:
Again, I'm not suggesting this as a default, but a system that's flexible to allow this to be setup through the keymap would have my preference.
edit: ofcourse, even with this setup I'd keep it possible to invoke box/circle/lasso select through a hotkey, so those who prefer using them to select things inside of a mesh aren't limited. This was just a perfect way for me to make selection very fast, and make use of the --formerly useless-- empty space. The context-sensitivity of this system made it very easy to adjust to.
Just wanted to leave a small update here to say that @PawelLyczkowski-1 and I are actively working on the first version of the new keymap. The goal is to have a simple version ready for active testing during 2.74 dev.
Thanks to everyone that's submitted feedback and ideas. At this point we need to step away from the committee and actually build a first version.
Added subscriber: @DuarteRamos
Added subscriber: @ManuJarvinen
Added subscriber: @EjnarBrendsdal
Nice discussion on the curser snap, pivot etc.
As for solution to transform widgit obscuring selection:
The widget only works with click-drag.
Why not allow selecting what's behind the widget when only single-clicking?
@EjnarBrendsdal That actually sounds like it could work. Maybe Julian can prototype this behavior.
Added subscriber: @JulianEisel
@PawelLyczkowski-1, you can already try that by setting 3D Manipulator operator (view3d.manipulator) to event type "Tweak".
I think this would be a great candidate project to move forward for the great Blender 2.8 development leap.
I am all for left-click select, but that is easy for a user to change if he wants to; my main concern about any new keymap is that modifier keys are used consistently.
In many parts of Blender [Shift] key is already used as some sort of "Plus" or "Add" or "Augment" of an operator, while [Alt] is the "reverse" or "opposite" operation say like:
[ H] hides [Alt+H] unhides or
[ P] parents while [Alt+P] clears parent
[ G] modes [Alt+G] clears transform or
[ M] moves to layer [Shift+M] moves to several layers, etc. you get the point.
This should be made as consistent as possible across all tools and operators over all editors, including obviously all selection modes, so that if one either enters the lasso select mode, circle select, border select or regular Click Select, [Shift] would always exclusively add to current selection, [Alt] would only remove from current selection, and maybe use [Ctrl] to toggle (?), conflicts with loop and ring select o others in other editors may arise and would have to be addressed.
Anyway whatever you choose to go with, the important thing is to make it consistent so an unsuspecting user would know what to press.
I posted a proposal about it in the wiki some time ago)
Added subscriber: @AndersonOmori
This is task being linked as a record that we are moving to left-mouse-select default.
(As far as I can see - neither Ton or any active core developers posted on this).
"That being said, I think there is some agreement that we will make left click select the default, Ton agreed with it as well as long as we have a well supported way of switching to right click select."
- Brecht
It's been mentioned/linked in the BA forums by multiple developers / team members now and the preliminary test scripts/keymaps seem based on that presumption too (though digging them all up would take some time).
(Note: This was posted in response to the original comment, not the edited one above)
I was searching exactly for that quote myself, but you beat me to it.
I read that too some time ago, now I did not check my sources and I cannot verify that Ton actually said that, I just assumed it is true and he did give his blessing. :)
Anyway left click select as default or not is a huge change and one that is bound to be both controversial and troublesome, I was more concerned about consistency
The entire new keymap is going to be a huge change, controversial, and troublesome. ;)
For what it's worth, I don't think we're going to find a public statement by Ton on the matter. He has stayed out of (public) discussion on the new keymap since the creation of the UI Team. There might be an IRC log with his commentary or a private email, but he's been pretty scarce on the tracker, blog, and forums about controversial issues like this.
That said, I don't think anyone is actually questioning Brecht's honesty here. If he says Ton agreed with it - I'm pretty sure that Ton agreed with Brecht on the matter (at least at the time). Whether he does now is something else, but doesn't seem to be what Campbell was asking about.
@ideasman42
For me one of the bigger roadblocks is the dope sheet. You have either selection or scrubbing with LMB, and no possibility of area select with LMB-click-on-empty-and-drag.
That's why I would go with a more standard solution regarding dopesheet scrubbing (maybe along a dopesheet and timeline merge), a separate area for scrubbing with a handle:
Let me know if I should open a separate design task for that. I'm not animating that often lately, a pro would have to speak about that.
@PawelLyczkowski-1, there are quite some conflicts, which is biggest depends on your POV, did anyone collect them all?
There is:
http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/UserInterface#Left_Mouse_selection_conflicts_with_defaults - but its not some comprehensive list (just noting that its an issue).
Not that I'm aware of.
I guess you're referring to my recent post on BA , worded like this:
It's obvious that there's quite some lack of communication within the UI team and to the outside, and I'd say this is a case where bad communication got in the way of a final decision making process. Other than Brecht's old comment here, things weren't really communicated to the outside, but whenever we (UI team members) talked about plans regarding keymap revamp etc, we handled it as pretty much given that we'll switch to LMB default selection (at least it seemed like this to me).
However, my BA comment was a bit too firm about it, let me put it a bit more vague: Yes, common opinion from UI team members and users involved appears to be LMB selection as default. There was never really made an 'official' decision about it, but most members agree on it and current plans aim towards this.
Maybe it's time to actually make an 'official' decision about LMB/RMB selection default and which conditions need to be met in case of a change. This discussion will go on forever if not.
This comment was removed by @ideasman42
Best wait until Ton comes back from holidays first :)
@ideasman42 Thought the same, just forgot to mention ;)
For what it's worth, my understanding of the consensus over many discussion was that we'd move to LMB in the new keymap by default but with the ability to switch instantly as preferred. Technically this is already doable in the current keymap, but there's lots of conflicts and problems. Of of my goals with this new keymap is to resolve those conflicts such that LMB/RMB switch actually works as it should.
If that is successful then it really doesn't matter which mouse button is used, so far as user preference goes.
Even if LMB-select doesn't become the default, better support for LMB setups would be very welcome. I've mostly forgotten how I built my keymap but I remember it took a lot of fiddling (and Paweł's addon).
Absolutely @januz. So long as we successfully use Action / Selection inputs everywhere then it should not be an issue. Most likely we'll run into a few hard-coded areas that'll need resolved, but that'll be tackled when we get to it.
This is a sensible of course, but its a bit strange to announce a decision has been made regarding a design that doesn't exist.
The new keymap needs to be created, evaluated, iterated on... after that a decision would be made.
Disagree that it "doesn't matter" - documentation & educational material tend to follow defaults, add-on developers will choose keys which work best with the default too (currently configuring key-maps for add-ons isn't working well, this needs to be addressed too).
Yup agreed, which is really where we are at now. At the end of the day the keymap may get rejected and that's okay; but as it is right now the goal has been to create one that uses LMB default.
I think it's pretty obvious that I've done poor job of communicating on this and keeping everyone in the loop, so my apologies for that. Admittedly, this is partly influenced by the overwhelming amount of discussion in other areas which can, and has had a stymieing result on progress.
As it stands right now I'm still trying to finalize my initial version of the new keymap, at which point I'll put it here for more iterative work and discussion.
Actually, I always think it a good thing to establish the fundamentals of any planned design changes. Given it was possibly the feature that attracted the most attention & controversy in the lead-up to the establishment of the UI Team & these tracker tasks - I would think the planned setup for the left mouse button pretty fundamental.
I'm actually confused as to why people seem upset/concerned that the UI Team made their goals for the LMB input clear. What is wrong with the UI Team stating upfront that they intend to change the default?
Added subscriber: @JasonSchleifer
Removed subscriber: @JasonSchleifer
@btolputt it was more of an issue of miscommunication with goals and intents. I've updated both the parent task and this one to better reflect actual goals and status.
Does this mean that the UI Team no longer intends for the defaults to have left-click as select?
Asking about intent here, not for a guaranteed outcome.
@btolputt, of course agreeing on design direction is good (before going ahead and finalizing the design).
However from reading these posts it wasn't clear to me exactly what was agreed on.
And when asking for details... there were still open topics to resolve.
The reason I am replying here is (for all I knew) this would be committed to master right after 2.76 release, with some edits to resolve the major keymap conflicts... and tag all other remaining keymap conflicts as TODO's.
There are many open-tasks, and I don't follow all closely.
So the task is still in the design phase and WIP, thats fine but that should be communicated.
Added subscriber: @bugaevc
Added subscriber: @dongyfeng
As a beginner user, I like LMB select. But RMB select has one clear advantage over LMB select that I simply cannot ignore: be able to select vertices/edges/polygons even if the transform manipulator is on the way. In a ideal world, I have both the LMB select AND be able to select object/components without worry about transform manipulator. Here is my proposal on how to achieve it:
For experienced/current Blender user:
For beginner Blender user:
This approach works for Extrude as well: first select some polygons then press E to enter Extrude Tool, there will be a manipulator shown at the selected faces. I can either press Z key to immediate extrude the faces and LMB to confirm or I can drag the manipulator to extrude and release the mouse to confirm.
Pros this approach:
Cons of this approach:
The point of the manipulator is to avoid having to use a hotkey, and to give beginners an easy way to get used to the interface. Making it show up when you press one of the transform keys, kind of (imo) get's rid of the purpose of having them there.
Also worth mentioning that it sounds like you're trying to turn the transforms into a full on modal mode where it's probably not really necessary.
Just so you know, you can disable the manipulator. On the default Key Combination, just press Ctrl+Space, and it will get rid of it. There's also a button in the header of the 3D view that does exactly the same thing.
Manipulator can act as a visual aid for hot key users. When I use G/S/R to transform, I don't know which axis I want to transform. So every time I have to look at left bottom of the 3d viewport to check if I input the right axis.
Yes and why not?
Maybe I can eliminate the second hotkey to better align with the current workflow.
In Step 4:
Added subscriber: @JasonSchleifer
Added subscriber: @ACap99
Changed status from 'Open' to: 'Archived'
There were various Blender keymap changes in 2.8 to improve consistency, with no further changes planned to shortcuts.
For bigger changes, the industry standard keymap is still under development: T5496, and for left-click select there will also be changes to accommodate the tool system. But this is also handled in other tasks.