Page MenuHome

Tools, Selection & Gizmo design
Open, Needs Information from UserPublic

Tokens
"Love" token, awarded by sh4dowk4ge."Like" token, awarded by JulienKaspar."Love" token, awarded by Thane5."Like" token, awarded by rboxman."Love" token, awarded by bnzs."Like" token, awarded by amonpaike."Love" token, awarded by manitwo."Love" token, awarded by jonathanl.
Authored By

Description

For 2.8, we've included a new toolbar and widgets system.

We have identified a few ways in which we can make improvements in this area.

This is applicable for tools that rely on selections, in Object and Edit mode.

Motivation

The main issues with the current configuration is:

  • It's too much of a hassle to switch between selection and operation
  • Tools are currently inconsistent, because some tools show gizmos, while others don't

Solution

We can address this like so:

  • By default, when clicking and dragging in the viewport, outside of the gizmo, you will perform a box selection.

The selection type can depend on the current select tool that's in the toolbar foreground:

QUESTION: will we have options for these tools accessible anywhere? or will you need to activate them to change their options?

  • This can be controlled by the Drag setting, which will become accessible for all gizmo-tools:

With the default keymap, user can also hold Alt to do the opposite thing, meaning that although it will select by default, you could still hold Alt and drag to use perform the tool action outside of the gizmo.

All this will make selection much more immediate, without requiring users to jump back and forth between selection tools and action tools.

Implications

To make this work consistently, we will have to include more gizmos for more tools. For normal tools, we cannot rely on clicking and dragging, because that will now box select, so we need something to click and drag on to execute the tool.

We have thus far avoided adding gizmos for so-called 1D tools, which don't represent any axes of input, but just usually represent a single amount. Examples of those are Bevel, Inset, Extrude Along Normals, Extrude Individual, Smooth, Randomize, Shrink/Fatten, Push/Pull, To Sphere.

Below is an example of how the generic amount-gizmo would look like:

Gizmos

Since this only works if selection-based tools have gizmos, here's a compiled table that describes how each tool's gizmo. See T70047: Gizmo support for all tools

Pros/Cons

Gizmo as Dominant Tool Access

This proposal makes gizmos the dominant method of accessing tools by default.

Pros:

  • A gizmo is an obvious place to access the tool.

Cons:

  • Pressing on a small gizmo is less efficient than clicking anywhere on the screen.
  • A gizmo may be off-screen depending on the selection.
  • Tools that depend on the cursor position don't fit so will when activated as gizmos. (Click-Extrude / Bisect / Rip / Poly Build). These will either need to be modified to work differently or not use selection at all.

UNRESOLVED: How will the rip tool know which side to rip from if we can't use the relative mouse location.

Immediate Tool Activation (Alt-LMB)

Pros:

  • The key is currently free by default.

Cons:

  • Inconvenient in the case we want to use other modifiers (Ctrl/Shift). Since we typically want to avoid actions that use too many modifiers.

    eg: If the user has drag set to access the tool, an intersecting border select action would be: Ctrl-Alt-Shift-Drag.
  • Won't work well with tools that already use holding Alt.

    Tools that already use Alt require Alt-Click, Then release and pressing Alt again (feels awkward).
    • Shrink/Fatten.
    • Edge/Vertex Slide.
    • Bend.

UNRESOLVED: How will tools that already use Alt be handled.

Details

Type
Design

Event Timeline

William Reynish (billreynish) lowered the priority of this task from Needs Triage by Developer to Normal.
William Reynish (billreynish) changed Type from Bug to Design.

That particular shade of purple is a non-starter for people with Protanopia and Deutanopia; blends in with the Z axis. A more distinct handle shape and/or pull direction would make the color less relevant, though.

Agree with the comment about color due to said issues. Try a different shape (diamond?) as you'll never find a good set of colors to differentiate.

Generally though, would it be possible to fully decouple selection from gizmo usage so that lasso and circle select can be used?

Adding 1D tool gizmo seems fine.

Having all tools accessible by a 1D gizmo by default is quite a big change, if you have to click on a small area of the screen it makes activating tools much less efficient.

Then this means:

  • Single mouse click to change a tool.
  • Single mouse click on a gizmo to run it.

If some users like this, maybe it's OK but if you need to change the default per tool - I think it's defaulting to a slow workflow without having a convenient way to avoid using it, it could be off by default, or a tool-setting stored per scene.

There are missing details for this task.

  • Which tools will this apply to exactly?
    • If you go over each tool there are some where this wont work so well, Rip tool for example will be annoying to use IMHO if it's only accessible via a gizmo.
    • Currently we rely on viewport dragging for spin and shear for example, adding a 1D gizmo wouldn't work on this case, we would need to extend the existing gizmo. It can work, it's just that it involves work not mentioned in this task.
  • How would users control options for border select, would these be exposed in the UI?
  • Would the keymap for border select also be enabled? (modifier keys for different operations). Or only support single action without modifiers?
  • Should the gizmo be locked to the view center if it happens to be outside the view? May be more of an issue if we rely on the gizmo for using the tool.

This task states:

It's too much of a hassle to switch between selection and operation

Currently you can box select by pressing the B-Key, it's not a lot of hassle compared to the overhead introduced by tool switching and having to press on a gizmo to access tools.
Although this should be more discoverable.

Further, switching between tools should not be a hassle, we should really provide a quick way to switch tools by default. Not doing this was a mistake in my opinion, now we try to solve this work workaround that only works for a single selection tool.

I would prefer to focus on faster tool switching then overlaying multiple tools on top of each other in a way that makes adding useful shortcuts to one tool, disable the ability to select in another.

Even if this is supported, it is a limited solution since it doesn't help when users want to do different kinds of selection.

Adding 1D tool gizmo seems fine.
Having all tools accessible by a 1D gizmo by default is quite a big change, if you have to click on a small area of the screen it makes activating tools much less efficient.
Then this means:

  • Single mouse click to change a tool.
  • Single mouse click on a gizmo to run it.

If some users like this, maybe it's OK but if you need to change the default per tool - I think it's defaulting to a slow workflow without having a convenient way to avoid using it, it could be off by default, or a tool-setting stored per scene.
There are missing details for this task.

  • Which tools will this apply to exactly?
    • If you go over each tool there are some where this wont work so well, Rip tool for example will be annoying to use IMHO if it's only accessible via a gizmo.
    • Currently we rely on viewport dragging for spin and shear for example, adding a 1D gizmo wouldn't work on this case, we would need to extend the existing gizmo. It can work, it's just that it involves work not mentioned in this task.
  • How would users control options for border select, would these be exposed in the UI?
  • Would the keymap for border select also be enabled? (modifier keys for different operations). Or only support single action without modifiers?
  • Should the gizmo be locked to the view center if it happens to be outside the view? May be more of an issue if we rely on the gizmo for using the tool. ----

This task states:

It's too much of a hassle to switch between selection and operation

Currently you can box select by pressing the B-Key, it's not a lot of hassle compared to the overhead introduced by tool switching and having to press on a gizmo to access tools.
Although this should be more discoverable.
Further, switching between tools should not be a hassle, we should really provide a quick way to switch tools by default. Not doing this was a mistake in my opinion, now we try to solve this work workaround that only works for a single selection tool.
I would prefer to focus on faster tool switching then overlaying multiple tools on top of each other in a way that makes adding useful shortcuts to one tool, disable the ability to select in another.
Even if this is supported, it is a limited solution since it doesn't help when users want to do different kinds of selection.

Having to even press a key before starting to perform selection is already too much hassle. It was one of those alien concepts that made most people dislike 2.79 and earlier. It should definitely not be more discoverable. In fact it should probably go away and never come back to be honest.

All that's needed for faster switching between tools are proper hotkeys. Right now, tool system lacks many of them and keymap is instead overloaded with functions that are only rarely used and often don't even deserve a default hotkey.

Yes, I do agree overlaying too many tools on top of each other is not a way to go, but ability to select while also using a gizmo based tool is standard in pretty much any other DCC out there. It's one of those kinds of standards addition of made Blender 2.8 so much more popular.

Lastly, users rarely want to do different kinds of selection. Yes, multiple selection modes exist, but if you observe any artist work, be it amateur or professional, you will see them utilizing box selection 99%+ of the time, resorting to other selection modes only very rarely in the rare situations of very complex specific selections.

It's not just that switching selection modes is what people do not do because of it not being very accessible, it's that they do not want to do it. Even if switching between selection modes was more accessible, it's still inferior to the comfort of having just one selection mode that just works well for 99% cases and you don't have to switch it. Helping users "want to do different kinds of selections" is really not a way to go. They do not want to do it, in general, so let's not force them to.

There was an attempt at spacebar tool switch menu in 2.8 alpha, which failed, rightfully so. I would not try to bring anything like that back. Just give the tools proper hotkeys at the expense of more niche features that don't deserve them, and make sure selection always works for any tools that do have a gizmo.

It would be unfortunate to take a step back to the very dark "B to box select" times of Blender 2.79.

Campbell Barton (campbellbarton) triaged this task as Needs Information from User priority.EditedSep 8 2019, 10:08 PM

This task naively lists solutions, without factoring in any tradeoffs.

I would like to see a fairly comprehensive list of pros and cons for these changes as part of the design process and evaluating the changes in general.

This patch combined with D4603: Keymap Preferences: Use Shortcuts for Tools has implications which aren't mentioned anywhere (as far as I know).

Perhaps we should have a meeting about this to try figure out what the end goal for the tool-system should be.

William Reynish (billreynish) renamed this task from Tools & widgets design update to Tools & Selection design.Sep 8 2019, 11:07 PM

It could be good to address some of the issues raised by this task and not leave this is an unknown state,

It proposes to use Alt-LMB as a dominant way of accessing tools. Yet, according to T69323: Remove/Update "Emulate Middle Mouse" preference, many users replied that they want to keep the ability to use this shortcut to emulate middle mouse buttons.

And again, this misses pros/cons tradeoffs for other changes.

You propose using the average normal for the direction of some of the gizmos. I'm curious what you'd propose doing about situations where the average normal doesn't make sense. For example, the average normal of a cube or a sphere would be zero, and anything close to that would have a nonsensical gizmo direction. Maybe more individual handles would work?

Also, I think it would be nice to avoid adding a "Drag" setting to every gizmo tool. It solves the problem, but in a pretty clunky way. I would support unifying such an option if it existed.

@Hans Goudey (HooglyBoogly) when there is no valid average normal, the gizmo just points upwards. This already works - check the Extrude gizmo.

The Drag setting would be shared so you don’t have to set it individually for each tool.

William Reynish (billreynish) renamed this task from Tools & Selection design to Tools, Selection & Gizmo design.Sep 18 2019, 10:38 PM

From the last UI meeting, I believe this is not planned for 2.81 so moving to the next.

In the context of selection based tools i would like to point out that, with the addition of the toolsystem, there are two ways of interaction in parallel. (This was already mentioned here: https://lists.blender.org/pipermail/bf-committers/2019-July/050018.html by Campbell)

This yields some issues as it splits the userbase. Currently there's a big difference between using operators or tools so that beginners have a hard time if they want to use operators for a faster workflow. On the other hand advanced users can't really take advantage of gizmos in their usual workflow.

I think this is far from ideal and in the long run it should be avoided having two systems in parallel. Instead the focus should be to bring the toolsystem workflow closer to what has been proven to work well. So that the toolsystem gives a fluid workflow for both GUI and shortcut based interaction. That would then mean that direct access to modal operators would be replaced where a tool is available.

To reach such a state i would like to propose following changes:

Make tools temporary
Selection based tools are often not repeatedly executed in a row like draw based tools.

As they rely heavily on a selection they should concentrate around that given selection rather than allowing to rapidly apply the action to different selections.

It seems that such tools don't work too well with the paradigm of an active tool, thus tools should rather be a temporary state that a user leaves to make a new selection.

That means:
-when a tool is active you can only make basic selections (click, shift click)
-for advanced selection (box, lasso, circle) the user has to escape the current tool first
-viewport dragging for tool action
-the tool keeps tweaking the same action
-a new action is started by clicking a "plus" gizmo/button or by starting the same tool again

Basic tool keymap
When a tool doesn't have to always co-exist but is rather temporary it can take over some of the most accessible keys while it is active:
-ESC to end a tool
-ENTER or the tool's shortcut key to retrigger the action
-TAB to switch to the next property if there are more than one editable properties
-absorb numeric keys as property input

Shortcut based tool interaction
To further improve the workflow, let tools be directly activated by shortcut and let them behave slightly different when activated by a shortcut.

-where a tool is available pressing the shortcut switches to the appropriate tool rather than the modal operator

-switching to a tool by shortcut can directly invoke the tweaking of the primary property when there's already a valid selection (similar to modal operators)

-switching to a tool if there's no valid selection, simply activates it without any action

-switching to the already active tool applies the modification and triggers the action again

@David Friedli (hlorus) this is basically an entirely separate proposal. Also, is this how Modo works? (IIRC they have tool 'dropping').

One thing I like about it is it doesn't rely on gizmos (viewport dragging for tool access), which IMHO is a weak part of the current proposal (even if it's configurable).

Having said that, your proposal is going in a very different direction, which has it's own trade-offs - for example, a tool being something you exit when modal-operators are also a mode you exit - giving the user multiple levels of action enter/exit to contend with (which I suspect would get confusing).

Currently I'm working on a branch that implements this task. So I'd like to finish that first, then re-evaluate the design.

@William Reynish (billreynish) this proposal doesn't cover the tool-options for the fallback tool (circle select radius, add/subtract ... etc).

IIRC it did come up in chat, I'm testing it out now and it ends up taking too much space in the top-bar (as well as being a bit confusing).

Suggestion:

  • Use small popover in the top-bar to the RHS of the option to select as a secondary option.
  • Use expanded UI in side-bar and properties editor.