Tools, Selection & Gizmo design #66304

New Issue

William Reynish · 2019-07-01T17:48:09+02:00

William Reynish commented

2019-07-01 17:48:09 +02:00

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 #70047 (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:

Won't work with MMB-Emulation (which users seem to want to keep #69323 (Remove/Update "Emulate Middle Mouse" preference)).
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.

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. ![Screenshot 2019-07-01 at 17.37.25.png](https://archive.blender.org/developer/F7558901/Screenshot_2019-07-01_at_17.37.25.png) The selection type can depend on the current select tool that's in the toolbar foreground: ![Screenshot 2019-09-07 at 19.33.10.png](https://archive.blender.org/developer/F7721958/Screenshot_2019-09-07_at_19.33.10.png) > **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: ![Screenshot 2019-09-07 at 19.42.32.png](https://archive.blender.org/developer/F7721973/Screenshot_2019-09-07_at_19.42.32.png) 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: ![Screenshot 2019-09-05 at 17.33.23.png](https://archive.blender.org/developer/F7721955/Screenshot_2019-09-05_at_17.33.23.png) ## Gizmos Since this only works if selection-based tools have gizmos, here's a compiled table that describes how each tool's gizmo. See #70047 (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:** - Won't work with MMB-Emulation *(which users seem to want to keep #69323 (Remove/Update "Emulate Middle Mouse" preference)).* - 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.

William Reynish commented

2019-07-01 17:48:09 +02:00

Added subscriber: @WilliamReynish

Campbell Barton was assigned by William Reynish

2019-07-01 17:48:21 +02:00

Duarte Farrajota Ramos commented

2019-08-04 02:01:17 +02:00

Added subscriber: @DuarteRamos

Asher commented

2019-08-16 00:49:57 +02:00

Added subscriber: @ThatAsherGuy

Asher commented

2019-08-16 01:09:17 +02:00

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.

Roger B commented

2019-09-04 20:49:19 +02:00

Added subscriber: @rboxman

Roger B commented

2019-09-04 20:49:19 +02:00

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?

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?

Campbell Barton commented

2019-09-05 12:13:40 +02:00

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.

Ludvik Koutny commented

2019-09-08 14:43:50 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-09-08 14:43:50 +02:00

In #66304#769703, @ideasman42 wrote:
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.

> In #66304#769703, @ideasman42 wrote: > 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 commented

2019-09-08 22:08:18 +02:00

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.

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](https://archive.blender.org/developer/D4603) 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 changed title from ~~Tools & widgets design update~~ to Tools & Selection design

2019-09-08 23:07:00 +02:00

Campbell Barton commented

2019-09-13 17:43:03 +02:00

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 #69323 (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.

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 #69323 (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.

Hans Goudey commented

2019-09-18 00:19:05 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2019-09-18 00:19:05 +02:00

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.

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.

William Reynish commented

2019-09-18 07:54:25 +02:00

@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.

@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.

David Friedli commented

2019-09-18 08:56:41 +02:00

Added subscriber: @hlorus

Julien Kaspar commented

2019-09-18 12:48:15 +02:00

Added subscriber: @JulienKaspar

William Reynish changed title from ~~Tools & Selection design~~ to Tools, Selection & Gizmo design

2019-09-18 22:38:08 +02:00

Brecht Van Lommel commented

2019-09-29 14:18:24 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-09-29 14:18:24 +02:00

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

David Friedli commented

2019-10-06 19:28:49 +02:00

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

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

Campbell Barton commented

2019-10-23 05:17:02 +02:00

@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.

@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.

Campbell Barton commented

2019-10-23 06:16:06 +02:00

@WilliamReynish 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.

@WilliamReynish 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.

David Friedli commented

2019-10-23 22:53:59 +02:00

In #66304#799967, @ideasman42 wrote:
@hlorus this is basically an entirely separate proposal. Also, is this how Modo works? (IIRC they have tool 'dropping').

I'm not familiar with Modo or any other animation software. What i've described is probably closer to the behavior of some technical softwares, although they don't require a super fast workflow and usually rely on a less immediate interaction where the tool is dropped after the user applys an operation.

Looking at some Modo tutorials it seems that they indeed use click-dragging in the viewport as tool interaction and shortcuts to activate tools.

In #66304#799967, @ideasman42 wrote:
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).

There will definitely be trade-offs. Not sure about the one you mention thought, a modal-operator runs while tweaking a property and ends with the next mouse-click (or release if release confirm = True). A user is probably aware that he's tweaking a property and wouldn't expect to drop the tool when escaping.
Also i think multiple levels that you escape step by step are normal (e.g. color menu inside a popover). If it really turns out to be confusing it's probably a matter of proper UI communication of what is currently active.

The bigger drawbacks i see:

Slowdown because of additional step to access advanced selection
Flashing UI because the tool might change rapidly
Maybe conflict between tool-keymaps and shortcuts to activate tools

> In #66304#799967, @ideasman42 wrote: > @hlorus this is basically an entirely separate proposal. Also, is this how Modo works? *(IIRC they have tool 'dropping')*. I'm not familiar with Modo or any other animation software. What i've described is probably closer to the behavior of some technical softwares, although they don't require a super fast workflow and usually rely on a less immediate interaction where the tool is dropped after the user applys an operation. Looking at some Modo tutorials it seems that they indeed use click-dragging in the viewport as tool interaction and shortcuts to activate tools. > In #66304#799967, @ideasman42 wrote: > 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)*. There will definitely be trade-offs. Not sure about the one you mention thought, a modal-operator runs while tweaking a property and ends with the next mouse-click (or release if release confirm = True). A user is probably aware that he's tweaking a property and wouldn't expect to drop the tool when escaping. Also i think multiple levels that you escape step by step are normal (e.g. color menu inside a popover). If it really turns out to be confusing it's probably a matter of proper UI communication of what is currently active. The bigger drawbacks i see: - Slowdown because of additional step to access advanced selection - Flashing UI because the tool might change rapidly - Maybe conflict between tool-keymaps and shortcuts to activate tools

Pieter Schiettecatte commented

2019-11-01 17:03:35 +01:00

Added subscriber: @Schiette

Pieter Schiettecatte commented

2019-11-01 17:03:35 +01:00

One thing I'm missing when it comes to intuitive tool switching, is that it's kinda (although you could debate it) an industry standard to use the ESC key to cancel the active tool and switch to selection. This feature is missing from Blender. I think the system would become more intuitive if ESC switched the active tool to selection.

ThinkingPolygons commented

2019-11-01 17:30:00 +01:00

Added subscriber: @ThinkingPolygons

ThinkingPolygons commented

2019-11-01 17:30:00 +01:00

In #66304#804453, @Schiette wrote:
I think the system would become more intuitive if ESC switched the active tool to selection.

This doesn't make sense when using active tools. This is only valid when using the legacy modal tools.

> In #66304#804453, @Schiette wrote: > I think the system would become more intuitive if ESC switched the active tool to selection. This doesn't make sense when using active tools. This is only valid when using the legacy modal tools.

Pieter Schiettecatte commented

2019-11-01 17:47:09 +01:00

It'd still be helpful if we have a quick way to switch back to selection mode (even if we could select drag while in another tool). I will add my comments relating to this in https://developer.blender.org/T69992

xrg commented

2019-11-01 17:52:21 +01:00

Added subscriber: @xrg

xrg commented

2019-11-01 17:52:21 +01:00

With the default keymap, the W key switches back to selection tools like you want (it cycles through them if you already have a selection tool selected, though).

Campbell Barton commented

2019-11-01 19:35:50 +01:00

In #66304#804456, @ThinkingPolygons wrote:
This doesn't make sense when using active tools. This is only valid when using the legacy modal tools.

I wouldn't consider modal tools "legacy", these are not obsolete or being phased out.

> In #66304#804456, @ThinkingPolygons wrote: > This doesn't make sense when using active tools. This is only valid when using the legacy modal tools. I wouldn't consider modal tools "legacy", these are not obsolete or being phased out.

Debuk commented

2019-11-04 11:44:52 +01:00

Added subscriber: @Debuk

Debuk commented

2019-11-04 11:44:52 +01:00

A gizmo as dominant tool access has more pro's than you have listed, eg

it can easily be used to better present and trigger options, that are right now placed in a hidden popup
it reduces the overall number of shortcuts needed in blender

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

With a single edgechain being ripped, I'd have said, present two gizmos points on the both sides of the edgechain and you're good to go. But an increasing amount of seperate chains in a selection will also increase the different possible combinations. And even with adding gizmo points on both sides of every edge chain you almost never will get all combinations possible.

So I think the best solution would be to make the position of the gizmo tweakable. It could be similarly to what has been proposed for the pivot point handling, by using a modifier key to control the position of the gizmo. I assume that unlike the pivot point in this case this gizmo should stick to the surface ( it decides based on 2d projections right? ), like the extrude gizmo does, but while holding the modifier key the position could be set to the viewportcamera-to-mouse raycasthit on the current object, just like the raycast placment of the 3dcursor.

Alternatively to the modifier key, if you use a gizmo somehow comparable to the extrude gizmo (normal-edge with trigger point) use the contact point with the surface to tweak the position and the distant one to trigger the ripping. That way the placement of the gizmo will always fall together with the raycast point.

A gizmo as dominant tool access has more pro's than you have listed, eg - it can easily be used to better present and trigger options, that are right now placed in a hidden popup - it reduces the overall number of shortcuts needed in blender > **UNRESOLVED**: How will the rip tool know which side to rip from if we can't use the relative mouse location. With a single edgechain being ripped, I'd have said, present two gizmos points on the both sides of the edgechain and you're good to go. But an increasing amount of seperate chains in a selection will also increase the different possible combinations. And even with adding gizmo points on both sides of every edge chain you almost never will get all combinations possible. So I think the best solution would be to make the position of the gizmo tweakable. It could be similarly to what has been proposed for the pivot point handling, by using a modifier key to control the position of the gizmo. I assume that unlike the pivot point in this case this gizmo should stick to the surface ( it decides based on 2d projections right? ), like the extrude gizmo does, but while holding the modifier key the position could be set to the viewportcamera-to-mouse raycasthit on the current object, just like the raycast placment of the 3dcursor. Alternatively to the modifier key, if you use a gizmo somehow comparable to the extrude gizmo (normal-edge with trigger point) use the contact point with the surface to tweak the position and the distant one to trigger the ripping. That way the placement of the gizmo will always fall together with the raycast point.

Stanislav Blinov commented

2019-11-12 13:24:00 +01:00

Added subscriber: @Stan_Pancakes

Stanislav Blinov commented

2019-11-12 13:24:00 +01:00

Regarding the rip tool, I think the actual gizmo should just be the move manipulator, as that's the action performed on ripped vertices/edges. The gizmo itself would be positioned/oriented as dictated by transform orientation and pivot. Perhaps an overlay could be introduced: when the tool is active, it would highlight edges along the side that's going to be ripped, with the ability to click a given section to switch the ripped side:

Once the user is satisfied with the direction, they can proceed to use the manipulator to actually rip and move the verts.

Regarding the rip tool, I think the actual gizmo should just be the move manipulator, as that's the action performed on ripped vertices/edges. The gizmo itself would be positioned/oriented as dictated by transform orientation and pivot. Perhaps an overlay could be introduced: when the tool is active, it would highlight edges along the side that's going to be ripped, with the ability to click a given section to switch the ripped side: ![rip_gizmo_overlay.gif](https://archive.blender.org/developer/F8047590/rip_gizmo_overlay.gif) Once the user is satisfied with the direction, they can proceed to use the manipulator to actually rip and move the verts.

Debuk commented

2019-11-12 15:44:08 +01:00

@Stan_Pancakes: I really like the idea of the overlay.

But I am not sure if the transform gizmo fits to the algorithm. The chosen gizmo has to be restricted to how the rip tool works. The transform gizmo isnt bound to the surface, you could place it in the center of a cube, and if ripping side calculation is simpler then the standard transform gizmo won't fit in terms of its degrees of freedom. I already asked how mouse position gets interpreted with this tool, no answer yet. Testing it revealed some strange cases as can be seen here ( animated gif):

@Stan_Pancakes: I really like the idea of the overlay. But I am not sure if the transform gizmo fits to the algorithm. The chosen gizmo has to be restricted to how the rip tool works. The transform gizmo isnt bound to the surface, you could place it in the center of a cube, and if ripping side calculation is simpler then the standard transform gizmo won't fit in terms of its degrees of freedom. I already asked how mouse position gets interpreted with this tool, no answer yet. Testing it revealed some strange cases as can be seen here ( animated gif): ![rip.gif](https://archive.blender.org/developer/F8048943/rip.gif)

Stanislav Blinov commented

2019-11-12 16:57:09 +01:00

@Debuk, yes, for the proposed solution with overlays the decisionmaking for rip would need to be augmented: existing behavior with the modal operator makes some sense (although still is often puzzling, esp. when ripping multiple disjointly-selected areas), but my proposal suggests making this decision an explicit and editable step, which shouldn't be based on gizmo position at all.
As for the gizmo, I think it should be the move one (or, in an ideal world, a switchable between move, rotate and scale), as that is what the operation does: edge split, "smart" selection and move. Proposed in #70047 the gizmo is just a circle, whereas a user expecting to move something should generally expect the move gizmo (IMHO).

@Debuk, yes, for the proposed solution with overlays the decisionmaking for rip would need to be augmented: existing behavior with the modal operator makes some sense (although still is often puzzling, esp. when ripping multiple disjointly-selected areas), but my proposal suggests making this decision an explicit and editable step, which shouldn't be based on gizmo position at all. As for the gizmo, I think it should be the move one (or, in an ideal world, a switchable between move, rotate and scale), as that is what the operation does: edge split, "smart" selection and **move**. Proposed in #70047 the gizmo is just a circle, whereas a user expecting to move something should generally expect the move gizmo (IMHO).

Debuk commented

2019-11-12 23:51:59 +01:00

@Stan_Pancakes Sorry I completely overread that you meant the overlay to be individually editable before ripping. My proposals further above are assuming the rip tool itself isn't changed and is based on a single reference point (screenspace, surfacebound raycasted point or whatever) Still I'm not sure if this is beyond of scope for this topic, but it's a nice idea to have the side choices editable. It makes the setup more complex, but offers much more versatile selection options.

But even if it is really changed, predictable and useful initial choices for the sides should still be there:

So assuming that the objects pivot point would be the reference point, then (for 2-manifold cases) the closest face of the 2 adjacent faces of an edge could get the movable ripped off side, a simple distance comparison in 3d space of the face midpoints would be sufficient here. That should be quite similar to what choices are made most of the time currently.
Allowing to tweak the pivot point position could update the initial choice for all edges.
Allowing to change the choice from all closest sides to all most distant sides, would be a nice option

And if the riptool is changed in its selection part then updating the movement part also comes to mind. For selections that are placed on arbitrary parts on volumetric closed meshes, with heavily differing normal directions moving everything along the same movement vector isnt useful.

Options for move along normals and individual inplane movements would be really reasonable extensions here.

@Stan_Pancakes Sorry I completely overread that you meant the overlay to be individually editable before ripping. My proposals further above are assuming the rip tool itself isn't changed and is based on a single reference point (screenspace, surfacebound raycasted point or whatever) Still I'm not sure if this is beyond of scope for this topic, but it's a nice idea to have the side choices editable. It makes the setup more complex, but offers much more versatile selection options. But even if it is really changed, predictable and useful initial choices for the sides should still be there: - So assuming that the objects pivot point would be the reference point, then (for 2-manifold cases) the closest face of the 2 adjacent faces of an edge could get the movable ripped off side, a simple distance comparison in 3d space of the face midpoints would be sufficient here. That should be quite similar to what choices are made most of the time currently. - Allowing to tweak the pivot point position could update the initial choice for all edges. - Allowing to change the choice from all closest sides to all most distant sides, would be a nice option And if the riptool is changed in its selection part then updating the movement part also comes to mind. For selections that are placed on arbitrary parts on volumetric closed meshes, with heavily differing normal directions moving everything along the same movement vector isnt useful. - Options for move along normals and individual inplane movements would be really reasonable extensions here.

Stanislav Blinov commented

2019-11-13 09:08:58 +01:00

@Debuk ...which is why I am proposing to make it into the move manipulator :) That's already subject to pivot point and transform orientation settings. With current modal rip operator, you always move in view plane, and have to rely on hotkeys for axes. With a manipulator (+individual origins +normal orientation) you would just pull the Z handle.

Debuk commented

2019-11-13 09:47:26 +01:00

My whole last comment was based on taking up your idea of using the move manipulator, so once again I agree on move gizmo being a good choice for an advanced rewrite and also on the z axis as normal movement handle. If that will be decided it's all fine and dandy and I'm with you.

I'd say I prefer the move manipulator with the additional plane handles as it fits best for inplane movements.
Also the control method still needs a modifier key or something similar to distinguish between moving parts individually oriented (eg along normals) or unified for all selection islands. Perhaps you meant that with "manipulator (+individual origins +normal orientation)"

I don't know if I missed some discussion on what is "subject to pivot point and transform orientation settings", so could you link to that if there has been discussed something apart from the discussion over at the devtalk forum( where I've already been participating)

My whole last comment was based on taking up your idea of using the move manipulator, so once again I agree on move gizmo being a good choice for an advanced rewrite and also on the z axis as normal movement handle. If that will be decided it's all fine and dandy and I'm with you. I'd say I prefer the move manipulator with the additional plane handles as it fits best for inplane movements. Also the control method still needs a modifier key or something similar to distinguish between moving parts individually oriented (eg along normals) or unified for all selection islands. Perhaps you meant that with "manipulator (+individual origins +normal orientation)" I don't know if I missed some discussion on what is "subject to pivot point and transform orientation settings", so could you link to that if there has been discussed something apart from the discussion over at the devtalk forum( where I've already been participating)

Stanislav Blinov commented

2019-11-13 12:52:15 +01:00

The way the Rip works right now is, after splitting the edges, it initiates the TRANSFORM_OT_translate operator, that is, move. Which, of course, respects other settings, like the current pivot point and transform orientation. So, if pivot point is set to Individual Origins, and the orientation is set to Normal, after pressing V you can hit Z, and the ripped off vertices will move along the normal, (each ripped region - along its own normal, thanks to Individual Origins). This is something one wouldn't be able to do with a "simple" (circle) gizmo without resorting to hotkeys, but will be able to do easily with the full manipulator (yes, I also mean the one with planes as well).

Asher commented

2019-12-07 16:10:23 +01:00

Stupid question: What's the thought process behind using fallback tools instead of fallback operators? There are some issues in 6ffcddc10a with how tool settings are updated when a fallback tool is active (play around with the bevel tool and toggling 'Vertex Only'), but I'm not sure how to weigh the current implementation against a one that relies on theoretical a wrapper operator for box/brush/lasso select that sits outside the tool keymaps.

Stupid question: What's the thought process behind using fallback tools instead of fallback operators? There are some issues in 6ffcddc10a with how tool settings are updated when a fallback tool is active (play around with the bevel tool and toggling 'Vertex Only'), but I'm not sure how to weigh the current implementation against a one that relies on theoretical a wrapper operator for box/brush/lasso select that sits outside the tool keymaps.

slowburn commented

2019-12-11 23:41:22 +01:00

Added subscriber: @slowburn

slowburn commented

2019-12-13 22:53:06 +01:00

Nice feature, but there's an issue with how Rotate and Scale tools work in Tweak mode:
tweak problem.mp4
Basically if you click and drag on an object area where the transform gizmo will appear you get a different action than clicking outside of it. This results in a very inconsistent and confusing behaviour. I think Tweak mode should ignore the gizmo when you click+drag on a new object for Scale/Rotate tools and just perform a corresponding action in screen space. Scale intensity will probably have to be adjusted because it's way too strong if you happen to click near the object's center.

Nice feature, but there's an issue with how Rotate and Scale tools work in Tweak mode: [tweak problem.mp4](https://archive.blender.org/developer/F8217561/tweak_problem.mp4) Basically if you click and drag on an object area where the transform gizmo will appear you get a different action than clicking outside of it. This results in a very inconsistent and confusing behaviour. I think Tweak mode should ignore the gizmo when you click+drag on a new object for Scale/Rotate tools and just perform a corresponding action in screen space. Scale intensity will probably have to be adjusted because it's way too strong if you happen to click near the object's center.

William Reynish commented

2019-12-14 18:13:49 +01:00

@slowburn IMO that's clearly a bug. You are welcome to submit a proper bug report for this.

Thanks.

@slowburn IMO that's clearly a bug. You are welcome to submit a proper bug report for this. Thanks.

slowburn commented

2019-12-14 21:26:17 +01:00

@WilliamReynish Ok, I can do that. But since this is still an experimental feature, and this bug happens only when Tool Fallback is enabled, maybe it would be better to discuss such issues in this thread? Reading about the proposed “Tracker Curfew” gave me an impression that the bug tracker is a 'bit' overloaded ATM.

Campbell Barton commented

2019-12-14 22:49:32 +01:00

Stupid question: What's the thought process behind using fallback tools instead of fallback operators?

Because a tool is not just an operator, it's a keymap which may have different actions based on modifier keys. It has modified defaults in it's keymap - and we may want a UI to change a subset of its options.

If we only used an operator, we miss all of this.

It sounds like you hit a bug - is it the same as this one? #72416 (Bevel tool settings fail to apply to next operation, when using the Bevel gizmo).

> Stupid question: What's the thought process behind using fallback tools instead of fallback operators? Because a tool is not just an operator, it's a keymap which may have different actions based on modifier keys. It has modified defaults in it's keymap - and we may want a UI to change a subset of its options. If we only used an operator, we miss all of this. ---- It sounds like you hit a bug - is it the same as this one? #72416 (Bevel tool settings fail to apply to next operation, when using the Bevel gizmo).

Asher commented

2019-12-15 02:51:46 +01:00

@ideasman42 Yep, same bug. Operator properties changed via the tool header are only applied when the operator is called with workspace_tool_type set to DEFAULT. Haven't traced it further, yet, as I'm still trying to wrap my head around what all's happening in WM_event_get_keymap_from_toolsystem.

If we only used an operator, we miss all of this.

If you wrap box select, circle select, and lasso select in an operator that can use an external property group to switch methods and modes, you can cover the bulk of the functionality you're talking about. Here's a basic example I slapped together this afternoon.

@ideasman42 Yep, same bug. Operator properties changed via the tool header are only applied when the operator is called with `workspace_tool_type` set to `DEFAULT`. Haven't traced it further, yet, as I'm still trying to wrap my head around what all's happening in `WM_event_get_keymap_from_toolsystem`. > If we only used an operator, we miss all of this. If you wrap box select, circle select, and lasso select in an operator that can use an external property group to switch methods and modes, you can cover the bulk of the functionality you're talking about. [Here's a basic example I slapped together this afternoon. ](https://github.com/M-Asher/blender-dynamic-fallback)

Giuseppe Bufalo commented

2019-12-16 03:09:40 +01:00

Added subscriber: @giuseppebufalo

Giuseppe Bufalo commented

2019-12-16 03:09:40 +01:00

In #66304#799967, @ideasman42 wrote:
@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.

I made a video how I used to do that in Modo.

So basically you activate the tool and you can change the operation, like for example you can extrude and tweak the extrusion either using the handle or by dragging anywhere in the viewport. If you want to perform a new operation then you hold Shift and drag. Once you’re done you use the Spacebar to drop the tool. The move, rotate, scale and lasso/rectangle selection are also tools and work in the same way. It might look a bit of time consuming but once you get used to it it works very well and it’s consistent.

Here is the video: https://youtu.be/iUjA1sMdV6c

Dropping the tool with space bar is very easy. I tested by assigning the lasso tool a Spacebar shortcut. The only problem is that I shouldn’t be able to use that tool while I am using other tools like for example the move tool because most of the time I drag the move tool by accident.

Off topic: another interesting concept (in Modo) is that all the tools work only on selected elements, and in modo when nothing is selected means that everything is selected. This add more control and consistency across all the tools. (You can see that in the video)

> In #66304#799967, @ideasman42 wrote: > @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. I made a video how I used to do that in Modo. So basically you activate the tool and you can change the operation, like for example you can extrude and tweak the extrusion either using the handle or by dragging anywhere in the viewport. If you want to perform a new operation then you hold Shift and drag. Once you’re done you use the Spacebar to drop the tool. The move, rotate, scale and lasso/rectangle selection are also tools and work in the same way. It might look a bit of time consuming but once you get used to it it works very well and it’s consistent. Here is the video: https://youtu.be/iUjA1sMdV6c Dropping the tool with space bar is very easy. I tested by assigning the lasso tool a Spacebar shortcut. The only problem is that I shouldn’t be able to use that tool while I am using other tools like for example the move tool because most of the time I drag the move tool by accident. Off topic: another interesting concept (in Modo) is that all the tools work only on selected elements, and in modo when nothing is selected means that everything is selected. This add more control and consistency across all the tools. (You can see that in the video)

Campbell Barton commented

2019-12-18 16:04:04 +01:00

@ThatAsherGuy fixed the bevel issue you pointed out #72416
@slowburn fixed the tweak issue you raised #66304#827670

- @ThatAsherGuy fixed the bevel issue you pointed out #72416 - @slowburn fixed the tweak issue you raised #66304#827670

Campbell Barton commented

2019-12-18 16:07:30 +01:00

In #66304#829059, @ThatAsherGuy wrote:
If you wrap box select, circle select, and lasso select in an operator that can use an external property group to switch methods and modes, you can cover the bulk of the functionality you're talking about. Here's a basic example I slapped together this afternoon.

I'm not sure what the benefit of this is though. We can solve this differently, however exposing a secondary tool still needs to have the ability to configure it and use it with modifier keys - that requires an operator, keymap and settings.

Having a dynamic tool fallback will work well for some tools but likely fails in cases tools need to have modified defaults for e.g.

> In #66304#829059, @ThatAsherGuy wrote: > If you wrap box select, circle select, and lasso select in an operator that can use an external property group to switch methods and modes, you can cover the bulk of the functionality you're talking about. [Here's a basic example I slapped together this afternoon. ](https://github.com/M-Asher/blender-dynamic-fallback) I'm not sure what the benefit of this is though. We can solve this differently, however exposing a secondary tool still needs to have the ability to configure it and use it with modifier keys - that requires an operator, keymap and settings. Having a dynamic tool fallback will work well for some tools but likely fails in cases tools need to have modified defaults for e.g.

Campbell Barton commented

2019-12-18 16:09:59 +01:00

@giuseppebufalo currently I'm focusing on getting the proposed task finalized.

If others like to talk about larger changes which go in a different direction - it's fine but not something I'm going to be looking into near term.

@giuseppebufalo currently I'm focusing on getting the proposed task finalized. If others like to talk about larger changes which go in a different direction - it's fine but not something I'm going to be looking into near term.

Asher commented

2019-12-18 17:50:32 +01:00

@ideasman42 I probably have some tunnel vision here, as I'm focusing on click-drag selection instead of the tool system as a whole. The main benefit that I see from an operator-based approach (for selection) is that it would mirror the way Blender handles transformation modes. Using a group of editor-wide settings on the right side of the tool header to change the behavior of five keymap entries in 3D View (Global) feels more approachable and explainable than a system that dynamically changes the active tool keymap in order to access twelve keymap entries spread across four tools.

slowburn commented

2019-12-20 00:30:03 +01:00

@ideasman42 I tried the latest build (12.19) and the problem I described earlier still exists. Only now it depends on whether an object is active (origin is visible as an orange point). And a partial gizmo appears at the world origin before you start dragging:

tweak problem2.mp4
Also, the "correct" behaviour here is somewhat problematic imo: if you need to move objects around you can use the Move or Tweak tool so the ability to move with click+drag with Rotate/Scale tool is redundant and reduces the usefulness of these tools. If you need to scale or rotate a lot of objects separately then doing so with a single click+drag motion is much faster than clicking to select and then dragging the gizmo.

@ideasman42 I tried the latest build (12.19) and the problem I described earlier still exists. Only now it depends on whether an object is active (origin is visible as an orange point). And a partial gizmo appears at the world origin before you start dragging: [tweak problem2.mp4](https://archive.blender.org/developer/F8235462/tweak_problem2.mp4) Also, the "correct" behaviour here is somewhat problematic imo: if you need to move objects around you can use the Move or Tweak tool so the ability to move with click+drag with Rotate/Scale tool is redundant and reduces the usefulness of these tools. If you need to scale or rotate a lot of objects separately then doing so with a single click+drag motion is much faster than clicking to select and then dragging the gizmo.

Campbell Barton commented

2019-12-20 04:02:33 +01:00

@slowburn, fixed this yesterday c14e352d2c, try a newer build.

@slowburn, fixed this yesterday c14e352d2c, try a newer build.

Martin commented

2019-12-25 03:05:57 +01:00

Added subscriber: @Excitedbox

Martin commented

2019-12-25 03:05:57 +01:00

Would it be possible to make the selection tool change to a pointer when you are over a selection?
With the default cross it is hard to see when you are over a vertex, edge, or face, especially on smaller surfaces.

I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own.

Seems that since blender is finally getting the more standardized and intuitive controls people are used to from other programs, that this would be the most simple way to do it.

Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious.

I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn´t change to the tool.

If you made an option to have the shortcut shown in the corner of the tools' buttons as a cheat for beginners, you can make tool switches easier, and help beginners learn the shortcuts too.

As a beginner who has never been able to adjust to blenders controls, I am happy to see the direction it is going. I just used it for the first time and it was much easier and this was the only thing that felt out of place.

Would it be possible to make the selection tool change to a pointer when you are over a selection? With the default cross it is hard to see when you are over a vertex, edge, or face, especially on smaller surfaces. I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own. Seems that since blender is finally getting the more standardized and intuitive controls people are used to from other programs, that this would be the most simple way to do it. Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious. I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn´t change to the tool. If you made an option to have the shortcut shown in the corner of the tools' buttons as a cheat for beginners, you can make tool switches easier, and help beginners learn the shortcuts too. As a beginner who has never been able to adjust to blenders controls, I am happy to see the direction it is going. I just used it for the first time and it was much easier and this was the only thing that felt out of place.

Harley Acheson commented

2019-12-25 03:36:30 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-12-25 03:36:30 +01:00

@Excitedbox - Would it be possible to make the selection tool change to a pointer when you are over a selection? With the default cross it is hard to see when you are over a vertex, edge, or face, especially on smaller surfaces.

That is possible, and there has been a couple requests for that. It might be best to propose that on a public forum and gather other opinions about this and see if there is any consensus.

I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own.

I think i understand what you are requesting - to have the cursor show an addition symbol that indicates selection mode - but can't see how that would "eliminate the need to switch between the different select types, since it would do it on it's own". See next comment...

Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious.

Many newcomers are a little unfamiliar with blender selection modes. Although there are three little buttons up there, there are actually seven modes. Hold down shift and you can enable all of them at once and work that way if that is more convenient.

I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn't change to the tool.

You mean if you click on a tool that is already selected it then changes to the next tool in the sub-list? so if "Selected Box" is already selected you could click once to change it to "Select Circle", again for "Lasso". Sounds interesting. Not sure about selecting "last" though.

If you made an option to have the shortcut shown in the corner of the tools' buttons as a cheat for beginners, you can make tool switches easier, and help beginners learn the shortcuts too.

Agreed. That little triangle in the corner is not very discoverable. Having a popup hint (somewhere) would be nice.

> @Excitedbox - Would it be possible to make the selection tool change to a pointer when you are over a selection? With the default cross it is hard to see when you are over a vertex, edge, or face, especially on smaller surfaces. That is possible, and there has been a couple requests for that. It might be best to propose that [on a public forum ](https://www.blender.org/community/) and gather other opinions about this and see if there is any consensus. > I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own. I think i understand what you are requesting - to have the cursor show an addition symbol that indicates selection mode - but can't see how that would "eliminate the need to switch between the different select types, since it would do it on it's own". See next comment... > Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious. Many newcomers are a little unfamiliar with blender selection modes. Although there are three little buttons up there, there are actually seven modes. Hold down shift and you can enable all of them at once and work that way if that is more convenient. > I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn't change to the tool. You mean if you click on a tool that is already selected it then changes to the next tool in the sub-list? so if "Selected Box" is already selected you could click once to change it to "Select Circle", again for "Lasso". Sounds interesting. Not sure about selecting "last" though. > If you made an option to have the shortcut shown in the corner of the tools' buttons as a cheat for beginners, you can make tool switches easier, and help beginners learn the shortcuts too. Agreed. That little triangle in the corner is not very discoverable. Having a popup hint (somewhere) would be nice.

Piotr Adamowicz commented

2019-12-26 09:27:10 +01:00

Added subscriber: @MadMinstrel

Piotr Adamowicz commented

2019-12-26 09:27:10 +01:00

If only selection was on another mouse key!

/me chuckles

If only selection was on another mouse key! /me chuckles

-- commented

2019-12-28 20:20:00 +01:00

Added subscriber: @zgorg

-- commented

2019-12-28 20:20:00 +01:00

I select with left click and unselect with right (toggle on). I was expecting a 0 tool selected. but even not existing. so I modified the select tool. click on nothing to unselect is by default. this is an heresy when modeling. using G to move is prehistorical. I do a select border with right drag so only on mouse and very quick no need tools for that just a little of logic. I don't see the interest to create some tools from existing functions add shortcuts to call them and pretend it's needed to have less shortcuts. with double middle mouse I can toggle edit. I mean I tried to explain me how people is working in their head. but it seems it's very different from me. but in a while you will the same as me. always like that

I select with left click and unselect with right (toggle on). I was expecting a 0 tool selected. but even not existing. so I modified the select tool. click on nothing to unselect is by default. this is an heresy when modeling. using G to move is prehistorical. I do a select border with right drag so only on mouse and very quick no need tools for that just a little of logic. I don't see the interest to create some tools from existing functions add shortcuts to call them and pretend it's needed to have less shortcuts. with double middle mouse I can toggle edit. I mean I tried to explain me how people is working in their head. but it seems it's very different from me. but in a while you will the same as me. always like that ```

Martin commented

2019-12-29 22:42:38 +01:00

Thanks for your response. I tied to follow your style in my reply I hope that makes it easier to track.

I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own.

I think i understand what you are requesting - to have the cursor show an addition symbol that indicates selection mode - but can't see how that would "eliminate the need to switch between the different select types, since it would do it on it's own". See next comment...

I mean that if the cursor changed to show what you are hovering over (vertex, edge, face) you wouldn´t need those three buttons up top and could make it switch selection modes on it´s own. It would always be clear which will be selected due to the cursor looking different. I think the selection buttons should stay as a way to lock in your select mode but adding this as well would make it a lot more intuitive and easy to use.

Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious.

Many newcomers are a little unfamiliar with blender selection modes. Although there are three little buttons up there, there are actually seven modes. Hold down shift and you can enable all of them at once and work that way if that is more convenient.

I didn´t even know there were more modes. Blender is so hard to use without doing tons and tons of tutorials most features get lost. Blender is just so complex it is impossible for a casual user to learn all the tools and shortcuts. Someone who only uses it every couple months would never be able to remember the hundreds of shortcuts. I think it is heading in the right direction but I think following the lead of other graphical programs such as Photoshop, Krita, Maya etc. would make it a lot easier. Maya for instance can be picked up and at least the modeling of basic shapes can be learned in a few hours due to the massive amount of tool options in the top bar.

I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn't change to the tool.

You mean if you click on a tool that is already selected it then changes to the next tool in the sub-list? so if "Selected Box" is already selected you could click once to change it to "Select Circle", again for "Lasso". Sounds interesting. Not sure about selecting "last" though.

I think this might actually be a bug. If you click and hold on a tool with a pop up sub menu in edit mode and do not select one of the sub menu options even though one is already highlighted making you think that it will be selected. On release it stays on the previous tool instead of switching to the new selection.

Thanks for your response. I tied to follow your style in my reply I hope that makes it easier to track. >> I suggest making the cursor change to a pointer with a small symbol underneath to display which you are selecting (edge, vertex, face). This would also eliminate the need to switch between the different select types, since it would do it on it's own. > > I think i understand what you are requesting - to have the cursor show an addition symbol that indicates selection mode - but can't see how that would "eliminate the need to switch between the different select types, since it would do it on it's own". See next comment... I mean that if the cursor changed to show what you are hovering over (vertex, edge, face) you wouldn´t need those three buttons up top and could make it switch selection modes on it´s own. It would always be clear which will be selected due to the cursor looking different. I think the selection buttons should stay as a way to lock in your select mode but adding this as well would make it a lot more intuitive and easy to use. > >> Right now, having to click the different modes or use a shortcut to switch between selection types is unnecessarily tedious. > > Many newcomers are a little unfamiliar with blender selection modes. Although there are three little buttons up there, there are actually seven modes. Hold down shift and you can enable all of them at once and work that way if that is more convenient. > I didn´t even know there were more modes. Blender is so hard to use without doing tons and tons of tutorials most features get lost. Blender is just so complex it is impossible for a casual user to learn all the tools and shortcuts. Someone who only uses it every couple months would never be able to remember the hundreds of shortcuts. I think it is heading in the right direction but I think following the lead of other graphical programs such as Photoshop, Krita, Maya etc. would make it a lot easier. Maya for instance can be picked up and at least the modeling of basic shapes can be learned in a few hours due to the massive amount of tool options in the top bar. > >> I also suggest that when clicking a tool with a pop out menu that it selects the last option used when just clicking the main item. It is much quicker than having to click and hold to select the last sub option. Right now it just flashes but doesn't change to the tool. > > You mean if you click on a tool that is already selected it then changes to the next tool in the sub-list? so if "Selected Box" is already selected you could click once to change it to "Select Circle", again for "Lasso". Sounds interesting. Not sure about selecting "last" though. I think this might actually be a bug. If you click and hold on a tool with a pop up sub menu in edit mode and do not select one of the sub menu options even though one is already highlighted making you think that it will be selected. On release it stays on the previous tool instead of switching to the new selection.

Martin commented

2019-12-29 22:47:57 +01:00

In #66304#839024, @zgorg wrote:
I select with left click and unselect with right (toggle on). I was expecting a 0 tool selected. but even not existing. so I modified the select tool. click on nothing to unselect is by default. this is an heresy when modeling. using G to move is prehistorical. I do a select border with right drag so only on mouse and very quick no need tools for that just a little of logic. I don't see the interest to create some tools from existing functions add shortcuts to call them and pretend it's needed to have less shortcuts. with double middle mouse I can toggle edit. I mean I tried to explain me how people is working in their head. but it seems it's very different from me. but in a while you will the same as me. always like that

I agree. We are used to these things because every other program uses these controls. Double clicking on something has always been edit or open edit mode. This is the one thing that has kept me from really learning to use blender. I have made at least 6 or 7 tries over the last 15 years but always give up because of the controls and UI. They are working on it now though and I think this version is a big improvement.

> In #66304#839024, @zgorg wrote: > I select with left click and unselect with right (toggle on). I was expecting a 0 tool selected. but even not existing. so I modified the select tool. click on nothing to unselect is by default. this is an heresy when modeling. using G to move is prehistorical. I do a select border with right drag so only on mouse and very quick no need tools for that just a little of logic. I don't see the interest to create some tools from existing functions add shortcuts to call them and pretend it's needed to have less shortcuts. with double middle mouse I can toggle edit. I mean I tried to explain me how people is working in their head. but it seems it's very different from me. but in a while you will the same as me. always like that > I agree. We are used to these things because every other program uses these controls. Double clicking on something has always been edit or open edit mode. This is the one thing that has kept me from really learning to use blender. I have made at least 6 or 7 tries over the last 15 years but always give up because of the controls and UI. They are working on it now though and I think this version is a big improvement.

Harley Acheson commented

2019-12-29 23:28:15 +01:00

@Excitedbox - I didn´t even know there were more modes. Blender is so hard to use...

We've talked about making those mode buttons work differently to make that more obvious. Right now the fact you must hold shift to select multiple modes (or all) hides the fact that you can do so. You can use Blender for years and never realize this.

What I'd like is to make them behave in a way that better leads you to that knowledge. Click on one and it becomes selected, then click on a second and then they are both selected, click on the third and they all are. Click on any selected button and it becomes unselected as long as it is not the only one selected.

With this change anyone first trying the buttons would almost instantly know how they work and that multiples can be selected at once. Then allow usage of Shift, Ctrl, and Alt to give further quick behavior. Ctrl-click can select only the one button and deselect the others (solo). Alt-click could reverse the button selection status.

Probably the biggest reason against such a change is just that there would be no suitable time to do so.

> @Excitedbox - I didn´t even know there were more modes. Blender is so hard to use... We've talked about making those mode buttons work differently to make that more obvious. Right now the fact you must hold shift to select multiple modes (or all) hides the fact that you can do so. You can use Blender for years and never realize this. What I'd like is to make them behave in a way that better leads you to that knowledge. Click on one and it becomes selected, then click on a second and then they are **both** selected, click on the third and they all are. Click on any selected button and it becomes unselected as long as it is not the only one selected. With this change anyone first trying the buttons would almost instantly know how they work and that multiples can be selected at once. Then allow usage of Shift, Ctrl, and Alt to give further quick behavior. Ctrl-click can select only the one button and deselect the others (solo). Alt-click could reverse the button selection status. Probably the biggest reason against such a change is just that there would be no suitable time to do so.

Stanislav Blinov commented

2020-01-01 13:43:18 +01:00

This comment was removed by @Stan_Pancakes

*This comment was removed by @Stan_Pancakes*

William Reynish commented

2020-01-01 15:21:59 +01:00

@Stan_Pancakes What you are discussing here is completely unrelated to this design task. Please move to somewhere different.

Thanks.

@Stan_Pancakes What you are discussing here is *completely* unrelated to this design task. Please move to somewhere different. Thanks.

JT Nelson commented

2020-01-01 17:32:46 +01:00

Added subscriber: @jta

JT Nelson commented

2020-01-01 17:32:46 +01:00

In #66304#840653, @WilliamReynish wrote:
@Stan_Pancakes What you are discussing here is completely unrelated to this design task. Please move to somewhere different.

Thanks.

Please state at least one specific and valid point as to why someone's contribution is "completely unrelated" in your opinion. Such a heavy handed comment comes across as bullying IMO and experience when it is an ultimatum and not backed up by a substantive and stated reason.

> In #66304#840653, @WilliamReynish wrote: > @Stan_Pancakes What you are discussing here is *completely* unrelated to this design task. Please move to somewhere different. > > Thanks. Please state at least one specific and valid point as to why someone's contribution is "*completely* unrelated" in your opinion. Such a heavy handed comment comes across as bullying IMO and experience when it is an ultimatum and not backed up by a substantive and stated reason.

Konstantina Anagnostou commented

2020-01-01 18:39:19 +01:00

Added subscriber: @Constantina32

William Reynish commented

2020-01-01 23:13:28 +01:00

@jta The discussion about which modes we have in Blender and the basic shortcuts in Blender is outside the scope of this design topic. It’s interesting but not related to this, and thus it should be discussed elsewhere.

William Reynish commented

2020-01-03 22:53:00 +01:00

Changed status from 'Needs User Info' to: 'Resolved'

William Reynish closed this issue

2020-01-03 22:53:00 +01:00

-- commented

2020-01-04 23:54:27 +01:00

@Harley

What I'd like is to make them behave in a way that better leads you to that knowledge. Click on one and it becomes selected, then click on a second and then they are both selected, click on the third and they all are. Click on any selected button and it becomes unselected as long as it is not the only one selected.

If it was possible to press several keys at the same time the problem could be solved (1,2,3)
pressing 1 or 2 keys not selected >toggle to these keys and deselect other one
pressing an already selected key if other selected > deselect (pass if wrong)
to extend press the already selected mode + others. or press just others + shift
to expand (less used) press other modes and ctrl or why not double clic on others

@Harley > What I'd like is to make them behave in a way that better leads you to that knowledge. Click on one and it becomes selected, then click on a second and then they are **both** selected, click on the third and they all are. Click on any selected button and it becomes unselected as long as it is not the only one selected. If it was possible to press several keys at the same time the problem could be solved (1,2,3) pressing 1 or 2 keys not selected >toggle to these keys and deselect other one pressing an already selected key if other selected > deselect (pass if wrong) to extend press the already selected mode + others. or press just others + shift to expand (less used) press other modes and ctrl or why not double clic on others

Ludvik Koutny commented

2020-01-09 11:17:58 +01:00

Toolbar version of the Loop Cut is still broken (mouse wheel does not change amount of cuts and the highlight line is thick and aliased compared to hotkey version of the tool where the line is thin an has antialiasing.