So is the new layer system.
1 Like
If all the selection tools replaced selection rather than extended selection, we wouldnât need to manually deselect so often in the first place.
2 Likes
âIf all the selection tools replaced selection rather than extended selection, we wouldnât need to manually deselect so often in the first place.â
All selection tools should have the option to add to the selection rather than replace it. You can always deselect all and THEN use a selection tool, but if you want to, for example, select the shortest path between two vertexes as well as your current selection, if the menu item replaces your current selection ⌠then thereâs no way of doing this.
Ideally, there should be an option for every selection type to remove from your current selection as well.
Aye, hold shift to add, hold ctrl to remove from selection. No toggle. 
Cessanâs experimental keymap from a few years back did it this way. I donât know if that keymap is still floating around somewhere or not.
that should depend on whether or not âextend selectionâ or âreplace selectionâ is used more often or more useful for each individual tool, on a tool by tool basis.
For myself, since I can only speak for myself, I use box and circle select much more frequently to extend a selection, rather than clearing the selection beforehand. It usually goes something like:
-clear selection
-box select/circle select a bunch
-move camera
-box select/circle select a bunch
-etc
-do the thing
Ideally, box select would be click and drag and you hold shift/ctrl to add/remove. So your example would look like:
- click-drag to select (no need to deselect prior selections)
- move view
- hold shift and click-drag to select more
- repeat
- do the thing
No need to toggle with the A key. No need to keep hitting B. If there is a case where it does make sense to extend selection, it should, but I donât know what that would be. If everything works consistently and efficiently the user wonât even need to think about selection at all.
2 Likes
click-drag is one of my most hated suggestions. Itâs about as context-ambiguous as you can get in the number of things it could do depending on the specific location of the mouse.
It also goes against the operational nature of the rest of the blender tools.
It also means the standard click-to-select action would have to be performed on release rather than on-down. Something the devs apparently donât want (see the mode pie menu shortcut)
It also removes the incredibly handy guidelines that come up when you activate the box select tool
Further, when the interface is lagging, the box select tool has feedback for every step.
registering the activation of the tool brings up the guidelines,
registering the mouse down input removes the guidelines,
the box updates during, and disappears on release.
How would the drag-select handle the feedback for the all-important mouse-down event? It canât assume youâre trying to box select or select a single point yet, and without feedback you canât tell if you can move the mouse without wrecking the start point yet.
Consistency? whatâs the consistency issue? the selection tools work quite consistently at the moment. If youâre talking about alt-a for selection being consistent with alt-g to clear translation, and alt-r to clear rotation, that consistency is overboard and unnecessary. Not only are they entirely different tools, theyâre different types of tools even.
Generally, tools can be consistent with other tools that do similar things, because they are used similarly. Making unrelated tools work similarly defies the fact that these tools do different things, they work differently and are used differently - and should be treated as such. If you have a legitimately better way of implementing the selection tools then go for it, but right now, all Iâm seeing is loss of functionality, confidence, and speed, in the pursuit of some ideal âconsistentâ design.
Bleh, I typed something out, but I donât care enough to argue about it. Carry on.
Edit: Found Cessanâs video explaining his experimental keymapâselection stuff is at 8:14:
Right, but you can argue that there are more advantages to the new layer system, so itâs an acceptable loss there. The alt + a to deselect change on the other hand seems to be an attempt to fix something that isnât broken. This shortcut wasnât even changed in that experimental keymap that was linked to.
I think the logic behind it was something like âits now consistent with canceling transforms and now you only need to press A to select all when you already have a selectionâ.
My issue with that reasoning is that pressing A twice in a situation when you want to select all after having something selected isnât slow. It wasnât an aspect of blender most users had trouble with, and the people who didnât like it wanted it to work the same as in other apps (ctrl + A to select all, ctrl + shfit + A to deselect all). This change not only doesnât satisfy the few who wanted it changed, but it also makes the keymap harder to learn.
New users absolutely have to learn the âalt + key to resetâ rule in order to properly deselect stuff. It is easier to remember that a single key works for both situations. You didnât need to remember any special combo or even pay attention to what you have selected when it was a toggle. If it doesnât do what you want in the first press, then just press it again. Using A as a toggle makes selection effortless.
When I was first learning blender I just focused on a handful of shortcuts. I didnât memorize every shortcut in the program, so I didnât know about the âalt + key to resetâ rule for a while. That isnât even a strictly enforced rule. A lot of keys use alt and donât reset their state (alt + V, alt + S in edit mode, etcâŚ).
1 Like
I wish that the new left panel tool system would be finally properly accessible from the input editor, so I can do the keymap right myself. I did it for 2.79, but in 2.8, I still canât even begin because most of the tools on the left tool panel just can not be mapped correctly 
2 Likes
Will that work when selecting an item from a menu?
Iâm sure everything in the select menu has a keypress, but⌠apart from a few of them that I use the most, I find myself reading through the menu.
Even a couple weeks in, used to most of the rest of the chances, Iâm still not feeling alt+A to deselect.
Fortunately, itâs easy enough to change, and you donât risk any potential conflicts in doing so. Still, itâd be nicer if they switched back to the previous toggle behavior as the default. Of all the new features and changes present in 2.8, this is the only one where a change, and the justification for it, seem to have been done for the simple sake of it.
2 Likes
In 2.8 (Today´s Build: TB), what´s the shortcut to call upon the quick pie menu: sculpt, vertex paint, texture paint and particle edit ?
Today is Agust 6.
Ps: Question: How in the world are we supposed to have a âcontextâ on tools, when the OTHER MAIN INTERACTION modes are not part of the same roulette on the pie menu? Thanks.
Itâs ctrl + Tab.
I donât know what you mean. That menu lists every mode an object can be in. For example, objects only have particle edit mode when youâve placed a particle system on them.
TAB (like in 2.79) was working well with all âtool´s context: interaction with the meshâ.
CTRL+TAB (in 2.8) has all the context in order, but new users (or users from old) have been frustrated by the âtabâ just showing 2 options. And there´s nothing on the (status bar?) to tell us better.
Now I´ll just wonder how pressing 2 keys is better than 1 at workflow?
By default in 2.79 tab functions as a toggle between the mode you are in and edit mode. Tab only opens a menu with all modes when you are using the default pie menus. Some folks prefer to keep tab as a toggle because they need to jump into edit mode more often than the other modes.
They had it set to work as a toggle with a normal press, but also launch the pie menu when you hold tab and move the mouse at the same time. It seems this caused the artists on the spring team to accidentally switch modes when they didnât want to so they changed it to this.
Personally I think tab should work as a toggle, but we should also get the pie menu when we hold tab down a little longer than normal. They wouldnât have to slow the menu down by much and it would reduce the complexity of the keymap at the same time.
Donât worry, they are still actively experimenting. I think theyâll change the shortcuts that donât work well before 2.8 becomes stable.
Interaction > Maya
Is it fully functional at this time ?
I think the plan is to replace the maya and 3ds max keymaps with the industry standard one. Youâll probably have to wait until that is added.
1 Like
New options were added for selection tools on the top bar (not sure if buildbot has updated yet, though).
If you pick âSetâ it functions like what I was talking about earlier. If âSetâ was the default behavior instead of âAdd,â we wouldnât need to manually deselect very often. Thus the âalt+aâ keybinding would be rather moot.
2 Likes
Exactly as you say. If we were given a way to deselect by clicking on empty space and âSetâ behavior on other selection tools, Alt+A wouldnât matter, because it would be rarely used.
1 Like