Tool System Proposal #53047

New Issue

Campbell Barton · 2017-10-11T10:43:43+02:00

Campbell Barton commented

2017-10-11 10:43:43 +02:00

About This Proposal

This document is mostly concerned with the end functionality and internal design,
some UI aspects are not set-in-stone and won't be covered in detail here.

This document mixes functionality with implementation details (normally I try to avoid this), however in this case I would like to get feedback from other developers on how this is integrated.
Python is not mentioned in this document, all functionality will be accessible from Python. There is nothing preventing scripts to define their own tools.
Another design tasks exists to handle details of how existing operators fit into a tool system #53101

Motivation

While using keyboard shortcuts is efficient, this isn't easily accessible for users who don't memorize them,
and while some tools can be accessed from the tool-bar, this doesn't work well for tools that depend on
pointer position, eg:

Drawing tools (grease pencil, 3D curve drawing...).

When drawing is not a *Mode*, accessing each time from the toolbar isn't convenient.

Transform Tools

When accessing from a pointer with absolute positioning especially.

Note that the current keyboard-oriented workflow will still be a first-class citizen,
A tool system will be added without disturbing the workflow of users who prefer key shortcuts which are more efficient.

Example Use Cases

Extrude Tool

Activating the tool could show a widget with handles to extrude the region or individual faces.

Drawing Tool

Activating means each stroke can be performed without accessing the tool each time.

Note that grease pencil is becoming it's own mode, it may be able to use the tool system too.
(remove the need for "Continuous Drawing" option).

Select Tools (Circle, Lasso, Border)

Allows for circle select to exit after each stroke - so the user can adjust the view (common request).

Primitive Creation Tool (maybe?)

This would allow clicking and dragging to create primitive shapes (box, sphere, plane... etc).

... adding other examples would be good.

Implementation

Accessing Tools

Tools will most likely be accessed from the toolbar,
we will likely have the button remain pressed while it's active.

Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool.

Some tools may use key bindings to activate them too (we can sort out these details later though).

Active Tool

Each work-space will have an active tool.
This will simply be the name of an operator.
The current interactions (3D cursor placement, accessing the manipulator)

will be exposed as a tool, so from the users perspective there will always be an active tool.

The options for the active tool will be displayed in the top-bar.
Each work-space will only have a single active tool.
We may want to investigate per space-type tools later, see details below.
Setting the active tool won't execute or run a modal handler,

instead, a key-map will be activated that takes priority over the area's keymap.

This will likely be assigned to the operator-type, as we have already for modal key-maps.

//Note that I expect we will have a generic tool key-map that can be used for most tools,
only some will require custom key-maps.//

Internally, activating a tool will use an operator bpy.ops.wm.tool_activate("curve.draw", properties={...}) for example.

Tool Settings

In general we will make use of existing operator properties functionality.

Currently operator types store their last-used properties, this can be used for top-bar properties too.

This is needed since the operator may not be running while the properties are being edited.

As with key bindings for operators, the key-map to activate a tool may include operator properties to be used.

Later on we may want to store tool-settings separately from last-used options,
we might want save these into the file too.

Manipulators

Active tools may have associated manipulators, these can be loosely coupled -
as we have already with operators.

In some cases it makes sense to have the manipulators only available once the tools are running
(spin, bisect tools for example).
In these cases the operator is responsible for manipulators (this is already working in the 2.8 branch).

In other cases we will want a tool to have associates manipulators which is immediately available.
(extrude tool for example).

This can be supported by adding a "manipulator_type" field to the operator-type,
on activating an operator-type as a tool, it's manipulator-type will be registered for the current space-type.
On de-activating the manipulator types will be unregistered with the space types.

Note, this matches how operators already add/remove manipulators when they're used with operators.

This avoids having all manipulators for all possible tools active at once,
with their poll functions continuously checking the active tool.
For C code this may not be much overhead, we will have Python manipulators too.

Known Unknowns

Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined.

Would there need to be an explicit action to hide the redo-operator options and display the tool options?

Editing operator properties of an operator that isn't running means the operator's "check" callback wont run.

This is currently used by some operators to sanitize properties when edited in the toolbar
(disallowing impossible combinations of options).

This is similar to editing properties in the key-map editor (where no sanity checks are done).

So we can just accept properties may be sanitized on first use. Another option could be to support running the
"check" callback without an operator instance

(wary of this since we will be using one callback in quite different ways).

We may want to have per space-type active tool,

this may be complicated unless we have an active area too.

Some applications do this by having the first click activate the area, similar to clicking on a window to focus.
I don't think this would fit well in Blender though.
Some possible solutions:

It may work to store a per space-type tool in the works-space, showing the last used tool-options in the top-bar,

  this avoids having to re-select the tool when entering a space.

  However it means you wouldn't be able to access options from top-bar before using the tool in a different space.

Another possible solution could be to have a way to change space-types from the top bar

(This feels like a weak workaround, just including for completeness)
Should multiple tools be accessible from a single button
(convention in some drawing applications is to click and old to select between variations of the same tool).
Should we show tool options in the-top bar which are not operator options?

We may for example - want to have proportional falloff radius accessible from the top-bar.

This is a tool setting, nevertheless users may expect to see this in the top-bar if its used for transform tools.

(More of a top-bar design issue really)

About This Proposal **** This document is mostly concerned with the end functionality and internal design, some UI aspects are not set-in-stone and won't be covered in detail here. - This document mixes functionality with implementation details (normally I try to avoid this), however in this case I would like to get feedback from other developers on how this is integrated. - Python is not mentioned in this document, all functionality will be accessible from Python. There is nothing preventing scripts to define their own tools. - Another design tasks exists to handle details of how existing operators fit into a tool system #53101 Motivation **** While using keyboard shortcuts is efficient, this isn't easily accessible for users who don't memorize them, and while some tools can be accessed from the tool-bar, this doesn't work well for tools that depend on pointer position, eg: - Drawing tools (grease pencil, 3D curve drawing...). ``` When drawing is not a *Mode*, accessing each time from the toolbar isn't convenient. ``` - Transform Tools ``` When accessing from a pointer with absolute positioning especially. ``` Note that the current keyboard-oriented workflow will still be a first-class citizen, A tool system will be added without disturbing the workflow of users who prefer key shortcuts which are more efficient. Example Use Cases **** - Extrude Tool ``` Activating the tool could show a widget with handles to extrude the region or individual faces. ``` - Drawing Tool ``` Activating means each stroke can be performed without accessing the tool each time. ``` ``` Note that grease pencil is becoming it's own mode, it may be able to use the tool system too. (remove the need for "Continuous Drawing" option). ``` - Select Tools (Circle, Lasso, Border) ``` Allows for circle select to exit after each stroke - so the user can adjust the view (common request). ``` - Primitive Creation Tool (maybe?) ``` This would allow clicking and dragging to create primitive shapes (box, sphere, plane... etc). ``` ... adding other examples would be good. Implementation **** Accessing Tools --------------- Tools will most likely be accessed from the toolbar, we will likely have the button remain pressed while it's active. *Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool.* Some tools may use key bindings to activate them too *(we can sort out these details later though)*. Active Tool ----------- - Each work-space will have an active tool. *This will simply be the name of an operator.* - The current interactions (3D cursor placement, accessing the manipulator) ``` will be exposed as a tool, so from the users perspective there will always be an active tool. ``` - The options for the active tool will be displayed in the top-bar. - Each work-space will only have a single active tool. *We may want to investigate per space-type tools later, see details below.* - Setting the active tool won't execute or run a modal handler, ``` instead, a key-map will be activated that takes priority over the area's keymap. ``` ``` This will likely be assigned to the operator-type, as we have already for modal key-maps. ``` ``` //Note that I expect we will have a generic tool key-map that can be used for most tools, only some will require custom key-maps.// ``` - Internally, activating a tool will use an operator `bpy.ops.wm.tool_activate("curve.draw", properties={...})` for example. Tool Settings ------------- In general we will make use of existing operator properties functionality. Currently operator types store their last-used properties, this can be used for top-bar properties too. This is needed since the operator may not be running while the properties are being edited. As with key bindings for operators, the key-map to activate a tool may include operator properties to be used. Later on we may want to store tool-settings separately from last-used options, we might want save these into the file too. Manipulators ------------ Active tools may have associated manipulators, these can be loosely coupled - as we have already with operators. In some cases it makes sense to have the manipulators only available once the tools are running (spin, bisect tools for example). In these cases the operator is responsible for manipulators *(this is already working in the 2.8 branch)*. In other cases we will want a tool to have associates manipulators which is immediately available. (extrude tool for example). This can be supported by adding a "manipulator_type" field to the operator-type, on activating an operator-type as a tool, it's manipulator-type will be registered for the current space-type. On de-activating the manipulator types will be unregistered with the space types. Note, this matches how operators already add/remove manipulators when they're used with operators. This avoids having all manipulators for all possible tools active at once, with their poll functions continuously checking the active tool. For C code this may not be much overhead, we will have Python manipulators too. Known Unknowns **** - Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined. ``` Would there need to be an explicit action to hide the redo-operator options and display the tool options? ``` - Editing operator properties of an operator that isn't running means the operator's "check" callback wont run. ``` This is currently used by some operators to sanitize properties when edited in the toolbar (disallowing impossible combinations of options). ``` ``` This is similar to editing properties in the key-map editor (where no sanity checks are done). ``` ``` So we can just accept properties may be sanitized on first use. Another option could be to support running the "check" callback without an operator instance ``` *(wary of this since we will be using one callback in quite different ways).* - We may want to have per space-type active tool, ``` this may be complicated unless we have an active area too. ``` ``` Some applications do this by having the first click activate the area, similar to clicking on a window to focus. I don't think this would fit well in Blender though. Some possible solutions: ``` - It may work to store a per space-type tool in the works-space, showing the last used tool-options in the top-bar, ``` this avoids having to re-select the tool when entering a space. ``` ``` However it means you wouldn't be able to access options from top-bar before using the tool in a different space. ``` - Another possible solution could be to have a way to change space-types from the top bar *(This feels like a weak workaround, just including for completeness)* - Should multiple tools be accessible from a single button *(convention in some drawing applications is to click and old to select between variations of the same tool)*. - Should we show tool options in the-top bar which are not operator options? ``` We may for example - want to have proportional falloff radius accessible from the top-bar. ``` ``` This is a tool setting, nevertheless users may expect to see this in the top-bar if its used for transform tools. ``` *(More of a top-bar design issue really)*

Campbell Barton self-assigned this 2017-10-11 10:43:43 +02:00

Campbell Barton commented

2017-10-11 10:43:43 +02:00

Changed status to: 'Open'

Campbell Barton commented

2017-10-11 10:43:43 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2017-10-11 10:52:58 +02:00

Added subscribers: @dfelinto, @mont29, @JulianEisel, @pablovazquez

Duarte Farrajota Ramos commented

2017-10-11 18:38:20 +02:00

Added subscriber: @DuarteRamos

Duarte Farrajota Ramos commented

2017-10-11 18:53:29 +02:00

Select Tools (Circle, Lasso, Border)
Allows for circle select to exit after each stroke - so the user can adjust the view (common request).

I was wondering if this was still being considered for 2.8, glad to see it is still on the table. It is one of my last remaining gripes with Blender; not being able to navigate while using an operator/modal/tool is one the few minor annoyances I still have.

I have no knowledge of how it works internally or from a code perspective, but purely from a user point of view looking at the keymap editor structure there seem to currently be a few modal specific keymaps shared across editors, like the Standard Modal Map, Transform Modal Map Eyedroper Modal Map, Gesture Border, View 3D Gesture Circle, among others.

I was wondering if we could similarly have some sort of "top level" modal map that would concern all view (2D or 3D) navigation key maps like moving view, rotating view, zooming in, and maybe fly mode too, under one same category that would force consistency across all Editors like the 3D View, Outliner, Node Editor or UV Image Viewer etc., and would override any other "sub-keymaps" (tools, editor specific, etc) , ensuring the navigation keymaps would always be available at all times, regardless of active tool, operator, or modal.

> Select Tools (Circle, Lasso, Border) > Allows for circle select to exit after each stroke - so the user can adjust the view (common request). I was wondering if this was still being considered for 2.8, glad to see it is still on the table. It is one of my last remaining gripes with Blender; not being able to navigate while using an operator/modal/tool is one the few minor annoyances I still have. I have no knowledge of how it works internally or from a code perspective, but purely from a user point of view looking at the keymap editor structure there seem to currently be a few modal specific keymaps shared across editors, like the *Standard Modal Map*, *Transform Modal Map* *Eyedroper Modal Map*, *Gesture Border*, *View 3D Gesture Circle*, among others. I was wondering if we could similarly have some sort of "top level" modal map that would concern all view (2D or 3D) navigation key maps like moving view, rotating view, zooming in, and maybe fly mode too, under one same category that would **force consistency** across all Editors like the *3D View*, *Outliner*, *Node Editor* or *UV Image Viewer* etc., and would override any other "sub-keymaps" (tools, editor specific, etc) , ensuring the navigation keymaps would always be available at all times, regardless of active tool, operator, or modal.

Campbell Barton commented

2017-10-12 04:24:07 +02:00

@DuarteRamos: this is more a design question for how key-maps interact.

As far as I know we didn't yet make detailed design decisions regarding key-map changes.
For now I'm aiming to make a design which is compatible with the current workflow as well as being customizable.

Not sure a top-level modal map would work well, there are so many modal operators as well as some defined by add-ons.

@DuarteRamos: this is more a design question for how key-maps interact. As far as I know we didn't yet make detailed design decisions regarding key-map changes. For now I'm aiming to make a design which is compatible with the current workflow as well as being customizable. Not sure a top-level modal map would work well, there are so many modal operators as well as some defined by add-ons.

Antonio Vazquez commented

2017-10-13 08:50:51 +02:00

Added subscriber: @antoniov

Julian Eisel commented

2017-10-13 20:04:57 +02:00

I generally like where this is going. It pretty much covers what I had in mind, although you go a bit further:
I actually didn't expect we'd work on having operator settings available before execution during the 2.8 project. In my mind, we'd limit things to supporting manipulators as active tool. This would be a big improvement on its own and should be the first step IMHO.
Is the pre-execution operator/tool settings really something that should to be part of the early 2.8 releases? Not against it really, just wondering if this was considered. I'm a bit afraid it might have too many loose ends.

Anyway, here are my thoughts regarding the current proposal:

Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined.

In other words, accessibility of redo-settings and tool-settings conflict: We probably want them both to be in the top-bar, but they would need to be accessible at the same time. So question is, how to expose them nicely? Could turn out to be a rather major issue.
We could add a toggle button for users to switch between tool and redo settings, or we say executing an operator also activates it as tool. Not sure about those solutions though. I guess ideally we'd solve this on a higher level so that tool and redo settings would be unified. Don't have any more concrete ideas though.

We may want to have per space-type active tool, this may be complicated unless we have an active area too.

This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show?
Conceptually, it would make sense to not have tool-settings in a global place, but in the editors. I.e. they could be placed where we have the operator-redo settings right now. Not sure if this would be a nice solution in regards to usability though. I quite liked the plan of getting rid of this panel. But may be best as initial solution? It would also solve the tool vs. redo settings accessibility issue.

Should we show tool options in the-top bar which are not operator options?

IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global ToolSettings. However I think the ToolSettings should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains.
In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the writeup unfortunately).

Some additional questions:

Do your plans also cover exposing settings for modal operator usage in the top-bar? Or should that be handled separately? (I.e. While loopcut runs, top-bar would show a button to set number of cuts and a checkbox to toggle smoothing.)
You suggest to only activate/deactivate manipulators for operator-types once the operator is activated as tool. While generally making sense, I wonder how could manipulator keymaps be handled with this?

Manipulators-groups have their own keymaps that can be edited like normal keymaps (e.g. to execute transform manipulators on select-mouse tweak event). I know this has quite a few usability issues and probably needs to be re-thought, but in general I think this functionality is useful to have.

Now, if manipulator-group-types only get registered on tool activation, users won't be able to edit their keymaps. Given the general usability issues manipulator keymaps have, we can probably ignore this for now, but good to keep in mind.

I generally like where this is going. It pretty much covers what I had in mind, although you go a bit further: I actually didn't expect we'd work on having operator settings available before execution during the 2.8 project. In my mind, we'd limit things to supporting manipulators as active tool. This would be a big improvement on its own and should be the first step IMHO. Is the pre-execution operator/tool settings really something that should to be part of the early 2.8 releases? Not against it really, just wondering if this was considered. I'm a bit afraid it might have too many loose ends. ---- Anyway, here are my thoughts regarding the current proposal: > Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined. In other words, accessibility of redo-settings and tool-settings conflict: We probably want them both to be in the top-bar, but they would need to be accessible at the same time. So question is, how to expose them nicely? Could turn out to be a rather major issue. We could add a toggle button for users to switch between tool and redo settings, or we say executing an operator also activates it as tool. Not sure about those solutions though. I guess ideally we'd solve this on a higher level so that tool and redo settings would be unified. Don't have any more concrete ideas though. >We may want to have per space-type active tool, this may be complicated unless we have an active area too. This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show? Conceptually, it would make sense to **not** have tool-settings in a global place, but in the editors. I.e. they could be placed where we have the operator-redo settings right now. Not sure if this would be a nice solution in regards to usability though. I quite liked the plan of getting rid of this panel. But may be best as initial solution? It would also solve the tool vs. redo settings accessibility issue. > Should we show tool options in the-top bar which are not operator options? IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global `ToolSettings`. However I think the `ToolSettings` should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains. In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the [writeup ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup) unfortunately). --- Some additional questions: * Do your plans also cover exposing settings for modal operator usage in the top-bar? Or should that be handled separately? (I.e. While loopcut runs, top-bar would show a button to set number of cuts and a checkbox to toggle smoothing.) * You suggest to only activate/deactivate manipulators for operator-types once the operator is activated as tool. While generally making sense, I wonder how could manipulator keymaps be handled with this? Manipulators-groups have their own keymaps that can be edited like normal keymaps (e.g. to execute transform manipulators on select-mouse tweak event). I know this has quite a few usability issues and probably needs to be re-thought, but in general I think this functionality is useful to have. Now, if manipulator-group-types only get registered on tool activation, users won't be able to edit their keymaps. Given the general usability issues manipulator keymaps have, we can probably ignore this for now, but good to keep in mind.

Campbell Barton commented

2017-10-15 16:02:54 +02:00

In #53047#465442, @JulianEisel wrote:
I generally like where this is going. It pretty much covers what I had in mind, although you go a bit further:
I actually didn't expect we'd work on having operator settings available before execution during the 2.8 project. In my mind, we'd limit things to supporting manipulators as active tool. This would be a big improvement on its own and should be the first step IMHO.
Is the pre-execution operator/tool settings really something that should to be part of the early 2.8 releases? Not against it really, just wondering if this was considered. I'm a bit afraid it might have too many loose ends.

Am fine with not having pre-execution operator/tool settings.
In this it's just one less case to support, however I think users will want this - changing circle select before selecting as simple example.

Anyway, here are my thoughts regarding the current proposal:

Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined.

In other words, accessibility of redo-settings and tool-settings conflict: We probably want them both to be in the top-bar, but they would need to be accessible at the same time. So question is, how to expose them nicely? Could turn out to be a rather major issue.
We could add a toggle button for users to switch between tool and redo settings, or we say executing an operator also activates it as tool. Not sure about those solutions though. I guess ideally we'd solve this on a higher level so that tool and redo settings would be unified. Don't have any more concrete ideas though.

We may want to have per space-type active tool, this may be complicated unless we have an active area too.

This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show?
Conceptually, it would make sense to not have tool-settings in a global place, but in the editors. I.e. they could be placed where we have the operator-redo settings right now. Not sure if this would be a nice solution in regards to usability though. I quite liked the plan of getting rid of this panel. But may be best as initial solution? It would also solve the tool vs. redo settings accessibility issue.

Should we show tool options in the-top bar which are not operator options?

IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global ToolSettings. However I think the ToolSettings should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains.
In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the writeup unfortunately).

Nothing to add to 3 comments above, AFAICS this is on-going design which may be more clear once we have basics in-place.

Some additional questions:

Do your plans also cover exposing settings for modal operator usage in the top-bar? Or should that be handled separately? (I.e. While loopcut runs, top-bar would show a button to set number of cuts and a checkbox to toggle smoothing.)

Had no plans for this, would rather handle it separately though it's worth keeping the possibility in mind.

You suggest to only activate/deactivate manipulators for operator-types once the operator is activated as tool. While generally making sense, I wonder how could manipulator keymaps be handled with this?

Manipulators-groups have their own keymaps that can be edited like normal keymaps (e.g. to execute transform manipulators on select-mouse tweak event). I know this has quite a few usability issues and probably needs to be re-thought, but in general I think this functionality is useful to have.

Now, if manipulator-group-types only get registered on tool activation, users won't be able to edit their keymaps. Given the general usability issues manipulator keymaps have, we can probably ignore this for now, but good to keep in mind.

I don't see this being a problem at all, manipulator keymaps control keys used when you interact directly with the manipulators,

I expect we will end up having tools using mainly one or the other...

Either the tool shows a manipulator which is the primary way of using the tool (manipulators keymap gets priority when active).

Or the tool has its own keymap - drawing for example. and there is no need to worry about manipulators.

> In #53047#465442, @JulianEisel wrote: > I generally like where this is going. It pretty much covers what I had in mind, although you go a bit further: > I actually didn't expect we'd work on having operator settings available before execution during the 2.8 project. In my mind, we'd limit things to supporting manipulators as active tool. This would be a big improvement on its own and should be the first step IMHO. > Is the pre-execution operator/tool settings really something that should to be part of the early 2.8 releases? Not against it really, just wondering if this was considered. I'm a bit afraid it might have too many loose ends. > Am fine with _not_ having pre-execution operator/tool settings. In this it's just one less case to support, however I think users will want this - changing circle select before selecting as simple example. > ---- > Anyway, here are my thoughts regarding the current proposal: >> Behavior for options shown on the top-bar when an operator is run outside the tool system (current redo panel) isn't well defined. > In other words, accessibility of redo-settings and tool-settings conflict: We probably want them both to be in the top-bar, but they would need to be accessible at the same time. So question is, how to expose them nicely? Could turn out to be a rather major issue. > We could add a toggle button for users to switch between tool and redo settings, or we say executing an operator also activates it as tool. Not sure about those solutions though. I guess ideally we'd solve this on a higher level so that tool and redo settings would be unified. Don't have any more concrete ideas though. > >>We may want to have per space-type active tool, this may be complicated unless we have an active area too. > This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show? > Conceptually, it would make sense to **not** have tool-settings in a global place, but in the editors. I.e. they could be placed where we have the operator-redo settings right now. Not sure if this would be a nice solution in regards to usability though. I quite liked the plan of getting rid of this panel. But may be best as initial solution? It would also solve the tool vs. redo settings accessibility issue. > >> Should we show tool options in the-top bar which are not operator options? > IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global `ToolSettings`. However I think the `ToolSettings` should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains. > In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the [writeup ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup) unfortunately). > Nothing to add to 3 comments above, AFAICS this is on-going design which may be more clear once we have basics in-place. > --- > Some additional questions: > > * Do your plans also cover exposing settings for modal operator usage in the top-bar? Or should that be handled separately? (I.e. While loopcut runs, top-bar would show a button to set number of cuts and a checkbox to toggle smoothing.) Had no plans for this, would rather handle it separately though it's worth keeping the possibility in mind. > * You suggest to only activate/deactivate manipulators for operator-types once the operator is activated as tool. While generally making sense, I wonder how could manipulator keymaps be handled with this? > > Manipulators-groups have their own keymaps that can be edited like normal keymaps (e.g. to execute transform manipulators on select-mouse tweak event). I know this has quite a few usability issues and probably needs to be re-thought, but in general I think this functionality is useful to have. > > Now, if manipulator-group-types only get registered on tool activation, users won't be able to edit their keymaps. Given the general usability issues manipulator keymaps have, we can probably ignore this for now, but good to keep in mind. I don't see this being a problem at all, manipulator keymaps control keys used when you interact directly with the manipulators, I expect we will end up having tools using mainly one or the other... Either the tool shows a manipulator which is the primary way of using the tool (manipulators keymap gets priority when active). Or the tool has its own keymap - drawing for example. and there is no need to worry about manipulators.

Satish Goda commented

2017-10-17 15:22:04 +02:00

Added subscriber: @satishgoda1

Lsscpp commented

2017-10-18 10:54:30 +02:00

Added subscriber: @lsscpp

Albert commented

2017-10-22 11:25:42 +02:00

Added subscriber: @wevon-2

Albert commented

2017-10-22 11:25:42 +02:00

My two cents.
Hi Campbell, I see that in your "Tool System Proposal" you have everything in mind.

Having worked with other software that uses tools, I think the Blender (selection-> action) + (shortcuts) workflow is the fastest, and I would not change it. Temporarily calling a tool from another tool (example: selection from transformation) is enough to not mix keyboard shortcuts. LMB could make this call, as until now with the selection, the problem is that it is not sensitive to pressure, and can not be transferred to the tools of painting and sculpture.

On the other hand I think eliminating the "Modes" and replacing it with a permanend tool actived, makes sense. Anyway the "Modes" I think could work as a system to have the tools organized.

Finally, I think we have to differentiate between the parameters of the tools, and the parameters that are generated when using the tools. These should allow to modify the action of the tool completely, once completed the action of the tool. For example: Tools like "Knife Topology" should allow you to move the cut points (if the mesh is not very dense).
In this way some tools dependent on a previous selection, such as the transformation or the extrusion, could modify its influence after its execution (besides the "Falloff"), As long as this option was previously in the tool, as for example : grow, or extend to linked. As if it were a filter or selection interpretation.
Tools like ZBrush ZModeler allow to alter the selection in the execution of the tool, but do not postpone it, I think it would be a great improvement to be able to do it.
Here a small model of the exposed.

Thanks for your attention.

My two cents. Hi Campbell, I see that in your "Tool System Proposal" you have everything in mind. Having worked with other software that uses tools, I think the Blender (selection-> action) + (shortcuts) workflow is the fastest, and I would not change it. Temporarily calling a tool from another tool (example: selection from transformation) is enough to not mix keyboard shortcuts. LMB could make this call, as until now with the selection, the problem is that it is not sensitive to pressure, and can not be transferred to the tools of painting and sculpture. On the other hand I think eliminating the "Modes" and replacing it with a permanend tool actived, makes sense. Anyway the "Modes" I think could work as a system to have the tools organized. Finally, I think we have to differentiate between the parameters of the tools, and the parameters that are generated when using the tools. These should allow to modify the action of the tool completely, once completed the action of the tool. For example: Tools like "Knife Topology" should allow you to move the cut points (if the mesh is not very dense). In this way some tools dependent on a previous selection, such as the transformation or the extrusion, could modify its influence after its execution (besides the "Falloff"), As long as this option was previously in the tool, as for example : grow, or extend to linked. As if it were a filter or selection interpretation. Tools like ZBrush ZModeler allow to alter the selection in the execution of the tool, but do not postpone it, I think it would be a great improvement to be able to do it. Here a small model of the exposed. ![Tools_Low.jpg](https://archive.blender.org/developer/F1058762/Tools_Low.jpg) Thanks for your attention.

Juri Unt commented

2017-10-23 09:13:22 +02:00

Added subscriber: @JuriUnt

Juri Unt commented

2017-10-23 09:13:22 +02:00

This comment was removed by @JuriUnt

*This comment was removed by @JuriUnt*

Campbell Barton commented

2017-10-23 12:33:45 +02:00

Quoting from: juri3d

In #53047#466893, @JuriUnt wrote:
Attached is a visual example how Houdini, Maya and Max have it. Subjectively think that viewport gizmo+text is best option as it is immediate and clear instead of hiding in cluttered panels/toolbars that require time to activate/find and confuse new users.. Option to script such viewport manipulators in python (e.g as seen in Maya) would also be very welcome.

@JuriUnt, please don't post screenshots of other applications, we can't host this info since other apps hold copyright on their interfaces. re-posting without screenshot. Image just showed other applications overlaying settings on their view-port.

Quoting from: juri3d > In #53047#466893, @JuriUnt wrote: > Attached is a visual example how Houdini, Maya and Max have it. Subjectively think that viewport gizmo+text is best option as it is immediate and clear instead of hiding in cluttered panels/toolbars that require time to activate/find and confuse new users.. Option to script such viewport manipulators in python (e.g as seen in Maya) would also be very welcome. *@JuriUnt, please don't post screenshots of other applications, we can't host this info since other apps hold copyright on their interfaces. re-posting without screenshot. Image just showed other applications overlaying settings on their view-port.*

xan2622 commented

2017-10-23 12:56:59 +02:00

Added subscriber: @xan2622

xan2622 commented

2017-10-23 12:56:59 +02:00

But at least, he can still post a link of this image ? (if the image is hosted elsewhere : https:*imgur.com/ , http:*pasteall.org/pic/ ), correct ?

But at least, he can still post **a link** of this image ? (if the image is hosted elsewhere : https:*imgur.com/ , http:*pasteall.org/pic/ ), correct ?

Okavango commented

2017-10-27 15:58:01 +02:00

Added subscriber: @Okavango

Okavango commented

2017-10-27 15:58:01 +02:00

Hi guys, hi @ideasman42

i just discovered this task and 'Active tool' test section in 2.8 branch tools panel. I especially took notice of the 'cage scale' widget prototype.

It just so happens i made a script with something similar a few months ago, maybe you could use it for ideas, a UI tool that scales the selection with a cage and handles.

You can test it in 2.79 by installing the addon and activating the tools from tool shelf panel. The addon is here: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Object/NP_Station

If you decide to test it, make a selection, activate point_scale from the T panel and follow the onscreen instructions. Some other tools from that set might also be interesting for this topic, let me know what you guys think.

Hi guys, hi @ideasman42 i just discovered this task and 'Active tool' test section in 2.8 branch tools panel. I especially took notice of the 'cage scale' widget prototype. It just so happens i made a script with something similar a few months ago, maybe you could use it for ideas, a UI tool that scales the selection with a cage and handles. You can test it in 2.79 by installing the addon and activating the tools from tool shelf panel. The addon is here: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Object/NP_Station If you decide to test it, make a selection, activate point_scale from the T panel and follow the onscreen instructions. Some other tools from that set might also be interesting for this topic, let me know what you guys think.

Okavango commented

2017-10-29 14:24:31 +01:00

This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show?

In other words, does global tool bar settings introduce a 'globally active tool' along with 'per - area active tool'? If so, is the active tool the one whose editor is active (mouse pointer is over it's area)?

Perhaps adjusting the contents of the top bar to follow the active area and it's active tool? That would mean changing the contents of the top bar (tool settings) based on the position of the pointer at all times, as pointer activates different areas, even while no operator is running. Too hectic? Maybe worth a test?

On side note, in the addon i linked, in the create section you can also examine some basic primitive creation tools that i saw you guys mention earlier. Maybe it sparks some thoughts. Without real manipulators though, but with some cursor info-badges...

> This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show? In other words, does global tool bar settings introduce a 'globally active tool' along with 'per - area active tool'? If so, is the active tool the one whose editor is active (mouse pointer is over it's area)? Perhaps adjusting the contents of the top bar to follow the active area and it's active tool? That would mean changing the contents of the top bar (tool settings) based on the position of the pointer at all times, as pointer activates different areas, even while no operator is running. Too hectic? Maybe worth a test? On side note, in the addon i linked, in the create section you can also examine some basic primitive creation tools that i saw you guys mention earlier. Maybe it sparks some thoughts. Without real manipulators though, but with some cursor info-badges...

Campbell Barton commented

2017-10-30 04:49:41 +01:00

In #53047#468184, @Okavango wrote:

This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show?

In other words, does global tool bar settings introduce a 'globally active tool' along with 'per - area active tool'? If so, is the active tool the one whose editor is active (mouse pointer is over it's area)?

Some applications do this, however it only works if you explicitly activate an area.
(I recall 3D-Studio used to do this). Blender uses sloppy focus for areas - this would have to change if we want the top-bar to show a single area that isn't directly below the topbar.

Note that this is a problem other applications struggle with.
QtCreator for example, has this problem - where the file-view syncs with the active document, that conflicts with multiple windows (where selecting the window changes the active document, therefor the file-view).

As for your 3D-cage, it looks like you've put a lot of thought into it. I'd be interested to see if there are ideas we can use.
For example - we may want to support rotation too.
Although for now I'm mainly working on basics, so might not get around to this soon.

> In #53047#468184, @Okavango wrote: >> This is possibly another major issue. To clarify: You might want to keep different tools active in different editors, i.e. the extrude tool active in the 3D View, the transform tool active in the UV Editor. The top-bar is global though, so which tool-settings to show? > > In other words, does global tool bar settings introduce a 'globally active tool' along with 'per - area active tool'? If so, is the active tool the one whose editor is active (mouse pointer is over it's area)? Some applications do this, however it only works if you explicitly activate an area. (I recall 3D-Studio used to do this). Blender uses sloppy focus for areas - this would have to change if we want the top-bar to show a single area that isn't directly below the topbar. Note that this is a problem other applications struggle with. QtCreator for example, has this problem - where the file-view syncs with the active document, that conflicts with multiple windows (where selecting the window changes the active document, therefor the file-view). ---- As for your 3D-cage, it looks like you've put a lot of thought into it. I'd be interested to see if there are ideas we can use. For example - we may want to support rotation too. Although for now I'm mainly working on basics, so might not get around to this soon.

Jonathan Williamson commented

2017-10-31 14:21:53 +01:00

Added subscriber: @JonathanWilliamson

Jonathan Williamson commented

2017-10-31 14:21:53 +01:00

Tool Settings

In #53047#465442, @JulianEisel wrote:

Should we show tool options in the-top bar which are not operator options?

IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global ToolSettings. However I think the ToolSettings should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains.
In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the writeup unfortunately).

I see this as the one major problem we have with the current top bar/tool settings and tool system. It works great for most tools, but not so well for those tools that're editor-specific (knife, extrude, uv pack, etc). I don't have any good proposals to improve this. My only current thought is that it may be worth considering keeping the tool settings in editor-specific headers rather than tied to the top bar.

Either way, putting the tool settings in a header or top bar enables us to remove the Operator panel from the toolshelf, which I think should absolutely happen. Most of the time it just wastes space and gets in the way.

Accessing Tools

Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool.

@ideasman42 this is working pretty well in the 2.8 branch already, but I have a question. How do you plan to distinguish between tools that exist in both ways? For example, will Extrude exist both as a push button and as a active tool?

## Tool Settings > In #53047#465442, @JulianEisel wrote: >> Should we show tool options in the-top bar which are not operator options? > IMHO that shouldn't be needed, so no. Currently non-operator tool options are either local to the editor, or they are part of the global `ToolSettings`. However I think the `ToolSettings` should be rethought long-term-ish. Quite a few of them should be local, e.g. the proportional editing falloff you mentioned. For a user, it doesn't make much sense that changing the falloff in the 3D View also changes it in the Node Editor. Same with many other settings it contains. > In regards to the global sculpt/paint settings, during the 2.8 UI workshop we agreed on keeping them in the tool-shelf for the time being (we forgot to mention that in the [writeup ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup) unfortunately). I see this as the one major problem we have with the current top bar/tool settings and tool system. It works great for most tools, but not so well for those tools that're editor-specific (knife, extrude, uv pack, etc). I don't have any good proposals to improve this. My only current thought is that it may be worth considering keeping the tool settings in editor-specific headers rather than tied to the top bar. Either way, putting the tool settings in a header or top bar enables us to remove the Operator panel from the toolshelf, which I think should absolutely happen. Most of the time it just wastes space and gets in the way. ## Accessing Tools >Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool. @ideasman42 this is working pretty well in the 2.8 branch already, but I have a question. How do you plan to distinguish between tools that exist in both ways? For example, will Extrude exist both as a push button *and* as a *active* tool?

Campbell Barton commented

2017-10-31 14:52:00 +01:00

In #53047#468544, @JonathanWilliamson wrote:
##Accessing Tools

Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool.

@ideasman42 this is working pretty well in the 2.8 branch already, but I have a question. How do you plan to distinguish between tools that exist in both ways?

They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing).

For example, will Extrude exist both as a push button and as a active tool?

This is more general issue. To begin with, tools can be defined and used anywhere, longer term we need to choose where we want to use them.

We might choose to use tools mainly in the 101 template, keeping default blender configuration mostly as is.

Or we may choose a set of tools that work well with the default config, and use then for as long as they don't conflict with Blender's workflow (experienced users will press the EKey to extrude for example).

Either way we can play this by ear. And if there are too many conflicts - not even use the tool-system by default, and allow templates to enable it (Blender-101 config for eg)

A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? (I don't think we want that) but we may want to support this for Blender101.

This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts.

I was thinking this could be done using a leader-key (if you're familiar with vim).

We could for example use spacebar as the leader key for setting tools. SpaceBar,E would set the extrude tool.

> In #53047#468544, @JonathanWilliamson wrote: > ##Accessing Tools >>Note that tools that can be activated will need to be presented separately from regular push-buttons, otherwise it's too confusing which buttons run immediately and which activate a tool. > > @ideasman42 this is working pretty well in the 2.8 branch already, but I have a question. How do you plan to distinguish between tools that exist in both ways? They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing). > For example, will Extrude exist both as a push button *and* as a *active* tool? This is more general issue. To begin with, tools can be defined and used anywhere, longer term we need to choose where we want to use them. We might choose to use tools mainly in the 101 template, keeping default blender configuration mostly as is. Or we may choose a set of tools that work well with the default config, and use then for as long as they don't conflict with Blender's workflow (experienced users will press the EKey to extrude for example). Either way we can play this by ear. And if there are too many conflicts - not even use the tool-system by default, and allow templates to enable it (Blender-101 config for eg) ---- A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? *(I don't think we want that)* but we may want to support this for Blender101. This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts. I was thinking this could be done using a leader-key (if you're familiar with vim). We could for example use spacebar as the leader key for setting tools. SpaceBar,E would set the extrude tool.

Jonathan Williamson commented

2017-10-31 15:44:28 +01:00

They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing).

I just spent a while testing this with @venomgfx. It's really excellent. We both agreed that keeping both tool versions in the toolshelf is overkill. The tool shelf is really only useful for Active tools (at least for any tool that requires input).

At this point I'd lean towards removing the normal operator versions from the toolshelf and see how well it works with just Active tools.

A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? (I don't think we want that) but we may want to support this for Blender101.

By default I'd definitely suggest we keep the existing hotkey-operators, but then enable users to add hotkeys for toggling Active Tools.

This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts.

Perhaps we do this like Sculpt Brushes, whereby the key sets the Active Tool and accepts a param for specifying the tool?

Some more questions

What does it take to enable Active mode for new tools? For example, if Smooth were to be made active, is it simple or does it require a lot of refactoring?

Will we be able to extend the tooltips to show the tooltip for the specific tool? E.g. show Knife tooltip when hovering on Active: Knife.

Any plans to support Action+Selection on the same mouse while a tool is active? We do this in my retopology add-on and it works pretty well, but it can get tricky.

> They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing). I just spent a while testing this with @venomgfx. It's really excellent. We both agreed that keeping both tool versions in the toolshelf is overkill. The tool shelf is really only useful for Active tools (at least for any tool that requires input). At this point I'd lean towards removing the normal operator versions from the toolshelf and see how well it works with just Active tools. > A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? (I don't think we want that) but we may want to support this for Blender101. By default I'd definitely suggest we keep the existing hotkey-operators, but then enable users to add hotkeys for toggling Active Tools. > This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts. Perhaps we do this like Sculpt Brushes, whereby the key sets the Active Tool and accepts a param for specifying the tool? ### Some more questions What does it take to enable Active mode for new tools? For example, if Smooth were to be made active, is it simple or does it require a lot of refactoring? Will we be able to extend the tooltips to show the tooltip for the specific tool? E.g. show Knife tooltip when hovering on Active: Knife. Any plans to support Action+Selection on the same mouse while a tool is active? We do this in my retopology add-on and it works pretty well, but it can get tricky.

Jonathan Williamson commented

2017-10-31 15:46:20 +01:00

I see this as the one major problem we have with the current top bar/tool settings and tool system. It works great for most tools, but not so well for those tools that're editor-specific (knife, extrude, uv pack, etc). I don't have any good proposals to improve this. My only current thought is that it may be worth considering keeping the tool settings in editor-specific headers rather than tied to the top bar.

Quick followup on this. After testing through it with @venomgfx I no longer see this as an issue. Since you're invariably working in a single editor at a time (not possible to use two tools) the global aspect is actually quite nice. It keeps it consistent and makes for easier muscle memory training.

> I see this as the one major problem we have with the current top bar/tool settings and tool system. It works great for most tools, but not so well for those tools that're editor-specific (knife, extrude, uv pack, etc). I don't have any good proposals to improve this. My only current thought is that it may be worth considering keeping the tool settings in editor-specific headers rather than tied to the top bar. Quick followup on this. After testing through it with @venomgfx I no longer see this as an issue. Since you're invariably working in a single editor at a time (not possible to use two tools) the global aspect is actually quite nice. It keeps it consistent and makes for easier muscle memory training.

Campbell Barton commented

2017-10-31 15:57:27 +01:00

In #53047#468573, @JonathanWilliamson wrote:

They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing).

I just spent a while testing this with @venomgfx. It's really excellent. We both agreed that keeping both tool versions in the toolshelf is overkill. The tool shelf is really only useful for Active tools (at least for any tool that requires input).

At this point I'd lean towards removing the normal operator versions from the toolshelf and see how well it works with just Active tools.

A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? (I don't think we want that) but we may want to support this for Blender101.

By default I'd definitely suggest we keep the existing hotkey-operators, but then enable users to add hotkeys for toggling Active Tools.

This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts.

Perhaps we do this like Sculpt Brushes, whereby the key sets the Active Tool and accepts a param for specifying the tool?

This sounds similar to using a leader-key. However its done, pressing a key can accept input for a second key with nice popup showing key->tool mapping. Even if this is a menu.

Some more questions

What does it take to enable Active mode for new tools? For example, if Smooth were to be made active, is it simple or does it require a lot of refactoring?

This depends a lot on what kinds of behavior you want to change. Many operators in blender just don't work very usefully when made into tools, especially when they don't operate on the data under the cursor ... so it depends entirely on how you want interactions to change.

Will we be able to extend the tooltips to show the tooltip for the specific tool? E.g. show Knife tooltip when hovering on Active: Knife.

Right, tools will need custom code to create more comprehensive tips (that can list multiple shortcuts).

Any plans to support Action+Selection on the same mouse while a tool is active? We do this in my retopology add-on and it works pretty well, but it can get tricky.

For some tools I think this makes sense. Have concerns about making this default/used-everywhere though.

The examples I've seen that work well - sketchup for example - selecting an entire surface is a single click because of how the geometry is defined. For blender it's more common to have many elements making up a shape, so splitting select+action makes more sense.

This is a big topic - am sure we will re-visit it. :)

> In #53047#468573, @JonathanWilliamson wrote: >> They could draw differently and in general they shouldn't be mixed in with regular operator buttons (they should get their own panel, at least be visually separated. placing them next to regular operators will be too confusing). > > I just spent a while testing this with @venomgfx. It's really excellent. We both agreed that keeping both tool versions in the toolshelf is overkill. The tool shelf is really only useful for Active tools (at least for any tool that requires input). > > At this point I'd lean towards removing the normal operator versions from the toolshelf and see how well it works with just Active tools. > >> A related issue you didn't raise, is should the EKey enable the extrude tool instead of activating extrude? (I don't think we want that) but we may want to support this for Blender101. > > By default I'd definitely suggest we keep the existing hotkey-operators, but then enable users to add hotkeys for toggling Active Tools. > >> This raises the question - how we support using key bindings to set tools, since we will probably want to switch tools via keyboard shortcuts. > Perhaps we do this like Sculpt Brushes, whereby the key sets the Active Tool and accepts a param for specifying the tool? > This sounds similar to using a leader-key. However its done, pressing a key can accept input for a second key with nice popup showing key->tool mapping. Even if this is a menu. > ### Some more questions > What does it take to enable Active mode for new tools? For example, if Smooth were to be made active, is it simple or does it require a lot of refactoring? This depends a lot on what kinds of behavior you want to change. Many operators in blender just don't work very usefully when made into tools, especially when they don't operate on the data under the cursor ... so it depends entirely on how you want interactions to change. > > Will we be able to extend the tooltips to show the tooltip for the specific tool? E.g. show Knife tooltip when hovering on Active: Knife. Right, tools will need custom code to create more comprehensive tips (that can list multiple shortcuts). > > Any plans to support Action+Selection on the same mouse while a tool is active? We do this in my retopology add-on and it works pretty well, but it can get tricky. For some tools I think this makes sense. Have concerns about making this default/used-everywhere though. The examples I've seen that work well - sketchup for example - selecting an entire surface is a single click because of how the geometry is defined. For blender it's more common to have many elements making up a shape, so splitting select+action makes more sense. This is a big topic - am sure we will re-visit it. :)

Jonathan Williamson commented

2017-10-31 16:06:33 +01:00

In #53101 @ideasman42 brought up as an example of difficult Design Considerations:

To pick a different example, say we add edit-mesh Edge Rotate as a tool:
Having to select, then click anywhere on the screen to rotate the edge - is awkward.
Single click to rotate the edge under the cursor fits in with what I think users expect.

I think this can be solved by enabling Manipulator display on Activation. Tools like Edge Crease, Extrude, Transform, etc, don't work well went they're activated by just clicking in space. They work much more clearly when they have specific manipulators that clearly indicate to the user what they should do.

Bisect on the other hand is a good example of a tool that should show the manipulator after click+drag, just like you have it now @campbellbarton.

This manipulator then also helps keep the user aware of which tool is active.

In #53101 @ideasman42 brought up as an example of difficult Design Considerations: > To pick a different example, say we add edit-mesh Edge Rotate as a tool: > Having to select, then click anywhere on the screen to rotate the edge - is awkward. > Single click to rotate the edge under the cursor fits in with what I think users expect. I think this can be solved by enabling Manipulator display on Activation. Tools like Edge Crease, Extrude, Transform, etc, don't work well went they're activated by just clicking in space. They work much more clearly when they have specific manipulators that clearly indicate to the user what they should do. Bisect on the other hand is a good example of a tool that should show the manipulator *after* click+drag, just like you have it now @campbellbarton. This manipulator then also helps keep the user aware of which tool is active.

Brecht Van Lommel commented

2017-10-31 21:17:21 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-10-31 21:17:21 +01:00

Personally I would prefer tools should be an extension of the existing operator system, letting operators draw into the relevant editors and override handling of keyboard and mouse inputs there. The last operator and active tool would be the same thing and their settings would be shown in the top bar. Operators like Extrude could have an "interactive" mode where they work like a tool, which may be always used in 101, or when clicking in the toolbar instead of pressing the shortcut.

How would tool input work if we make LMB select the default? I guess we would either need a default select tool, or we use RMB for performing the tool actions. I guess the latter is bad if our intention is to make things more consistent with other applications.

Personally I would prefer tools should be an extension of the existing operator system, letting operators draw into the relevant editors and override handling of keyboard and mouse inputs there. The last operator and active tool would be the same thing and their settings would be shown in the top bar. Operators like Extrude could have an "interactive" mode where they work like a tool, which may be always used in 101, or when clicking in the toolbar instead of pressing the shortcut. How would tool input work if we make LMB select the default? I guess we would either need a default select tool, or we use RMB for performing the tool actions. I guess the latter is bad if our intention is to make things more consistent with other applications.

Campbell Barton commented

2017-11-01 07:41:45 +01:00

In #53047#468708, @brecht wrote:
Personally I would prefer tools should be an extension of the existing operator system, letting operators draw into the relevant editors and override handling of keyboard and mouse inputs there.

Initially I tried doing this but found that a tool is more like a minor-mode, since...

It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select.
We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into.
We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists).
In rare cases one operator might be accessed by different tools TRANSFORM_OT_transform(mode='BONE_ROLL') for eg. Realize in this example we might be better off making bone roll into its own operator.

Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator.

Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a wait_for_input option which isn't much hassle).

This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator.

If I misunderstand or this can be made to work somehow I'm not against it either.

The last operator and active tool would be the same thing and their settings would be shown in the top bar.

Sounds good, if we can avoid this it's less confusing for everyone :)

Still not sure exactly how it should work - You select a tool (curve drawing for eg) then access subdivide from a menu - does this de-activate the draw tool?

Operators like Extrude could have an "interactive" mode where they work like a tool, which may be always used in 101, or when clicking in the toolbar instead of pressing the shortcut.

Currently the difference with "interactive" mode is defined by checking the manipulator preference. It can be changed if we want to layout.operator_context = 'INTERACTIVE_DEFAULT' ... or something similar.

How would tool input work if we make LMB select the default? I guess we would either need a default select tool, or we use RMB for performing the tool actions. I guess the latter is bad if our intention is to make things more consistent with other applications.

Currently all tools use ACTIONMOUSE, if we want to use LMB for select AFAICS select then needs to be a tool as well.
If we wanted to behave as other applications do, border select might be the default tool, with a click event bound to select.

Am personally not a fan of this, but think its something we could support with the current design via templates.

> In #53047#468708, @brecht wrote: > Personally I would prefer tools should be an extension of the existing operator system, letting operators draw into the relevant editors and override handling of keyboard and mouse inputs there. Initially I tried doing this but found that a tool is more like a minor-mode, since... - It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select. - We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into. - We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists). - In rare cases one operator might be accessed by different tools `TRANSFORM_OT_transform(mode='BONE_ROLL')` for eg. Realize in this example we might be better off making bone roll into its own operator. ``` Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator. ``` - Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a `wait_for_input` option which isn't much hassle). ``` This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator. ``` If I misunderstand or this can be made to work somehow I'm not against it either. > The last operator and active tool would be the same thing and their settings would be shown in the top bar. Sounds good, if we can avoid this it's less confusing for everyone :) Still not sure exactly how it should work - You select a tool (curve drawing for eg) then access subdivide from a menu - does this de-activate the draw tool? > Operators like Extrude could have an "interactive" mode where they work like a tool, which may be always used in 101, or when clicking in the toolbar instead of pressing the shortcut. > Currently the difference with "interactive" mode is defined by checking the manipulator preference. It can be changed if we want to `layout.operator_context = 'INTERACTIVE_DEFAULT'` ... or something similar. > How would tool input work if we make LMB select the default? I guess we would either need a default select tool, or we use RMB for performing the tool actions. I guess the latter is bad if our intention is to make things more consistent with other applications. Currently all tools use `ACTIONMOUSE`, if we want to use LMB for select AFAICS select then needs to be a tool as well. If we wanted to behave as other applications do, border select might be the default tool, with a click event bound to select. Am personally not a fan of this, but think its something we could support with the current design via templates.

Okavango commented

2017-11-01 10:22:00 +01:00

As for your 3D-cage, it looks like you've put a lot of thought into it. I'd be interested to see if there are ideas we can use.
For example - we may want to support rotation too.
Although for now I'm mainly working on basics, so might not get around to this soon.

Thanks. Only be advised, those tools are also just a test, to see if some of the procedures i saw work elsewhere could be ported to Blender in some shape. Could hit a design patent issue, most of the functions of the scale cage resemble similar ones in other apps. Some commercial, some open source (eg. inkscape has something similar).

The one feature they don't have and the one that i've been missing is the one you mentioned - fast aligning of the cage. I was thinking, upon activating the manipulator there could be a keyboard shortcut to go into align mode with a LMB click on a random edge, with preselection highlight and cage rotation preview - align shortcut / preview / LMB click - and you're back to standard mode, waiting for the handle selection. Didn't have the time to write it though.

Anyway, great work and sorry for the off- topic. I see this task is dedicated to other questions, i won't raise this here anymore.

> As for your 3D-cage, it looks like you've put a lot of thought into it. I'd be interested to see if there are ideas we can use. > For example - we may want to support rotation too. > Although for now I'm mainly working on basics, so might not get around to this soon. Thanks. Only be advised, those tools are also just a test, to see if some of the procedures i saw work elsewhere could be ported to Blender in some shape. Could hit a design patent issue, most of the functions of the scale cage resemble similar ones in other apps. Some commercial, some open source (eg. inkscape has something similar). The one feature they don't have and the one that i've been missing is the one you mentioned - fast aligning of the cage. I was thinking, upon activating the manipulator there could be a keyboard shortcut to go into align mode with a LMB click on a random edge, with preselection highlight and cage rotation preview - align shortcut / preview / LMB click - and you're back to standard mode, waiting for the handle selection. Didn't have the time to write it though. Anyway, great work and sorry for the off- topic. I see this task is dedicated to other questions, i won't raise this here anymore.

Brecht Van Lommel commented

2017-11-01 17:59:51 +01:00

I don't have good answers for these. But to me it seems that having an operator and tool system running side by side kind of pushes the problem to the users. If you can have e.g. both a circle select tool and circle select operator active, that seems very confusing. I think Blender should explicitly prevent that kind of thing, by design.

In #53047#468743, @ideasman42 wrote:

It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select.

The tool could either ignore this modifier key, or use it to set initialize a tool property to invert the selection. Though maybe I'm not understanding the issue.

We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into.

We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists).

In rare cases one operator might be accessed by different tools TRANSFORM_OT_transform(mode='BONE_ROLL') for eg. Realize in this example we might be better off making bone roll into its own operator.

Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator.

I don't have a good overview of what these cases are. But for something like a paint tool, perhaps sampling colors or drawing should just not show operator redo properties, and the active tool would stick.

If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace.

Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a wait_for_input option which isn't much hassle).

This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator.

Personally I don't believe in this design/developer team distinction, and think that it's better to avoid the abstraction layer since any non-trivial design changes require a developer anyway.

I don't have good answers for these. But to me it seems that having an operator and tool system running side by side kind of pushes the problem to the users. If you can have e.g. both a circle select tool and circle select operator active, that seems very confusing. I think Blender should explicitly prevent that kind of thing, by design. > In #53047#468743, @ideasman42 wrote: > - It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select. The tool could either ignore this modifier key, or use it to set initialize a tool property to invert the selection. Though maybe I'm not understanding the issue. > - We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into. > - We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists). > - In rare cases one operator might be accessed by different tools `TRANSFORM_OT_transform(mode='BONE_ROLL')` for eg. Realize in this example we might be better off making bone roll into its own operator. > > Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator. I don't have a good overview of what these cases are. But for something like a paint tool, perhaps sampling colors or drawing should just not show operator redo properties, and the active tool would stick. If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace. > - Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a `wait_for_input` option which isn't much hassle). > > This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator. Personally I don't believe in this design/developer team distinction, and think that it's better to avoid the abstraction layer since any non-trivial design changes require a developer anyway.

Albert commented

2017-11-02 15:25:12 +01:00

This comment was removed by @wevon-2

*This comment was removed by @wevon-2*

Campbell Barton commented

2017-11-03 04:34:47 +01:00

In #53047#468881, @brecht wrote:
I don't have good answers for these. But to me it seems that having an operator and tool system running side by side kind of pushes the problem to the users. If you can have e.g. both a circle select tool and circle select operator active, that seems very confusing. I think Blender should explicitly prevent that kind of thing, by design.

Agree, for the moment I don't see a problem to keep developing the tool-system and postpone some decisions.
(some of these seem more related to the top-bar).
OTOH - if once we're waiting on decisions like this. We will need to make a decision on how these things fit together.

In #53047#468743, @ideasman42 wrote:

It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select.

The tool could either ignore this modifier key, or use it to set initialize a tool property to invert the selection. Though maybe I'm not understanding the issue.

A problem with this is the tool is checking for modifier keys in its invoke (effectively hard coding the keymap).

We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into.

We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists).

In rare cases one operator might be accessed by different tools TRANSFORM_OT_transform(mode='BONE_ROLL') for eg. Realize in this example we might be better off making bone roll into its own operator.

Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator.

I don't have a good overview of what these cases are. But for something like a paint tool, perhaps sampling colors or drawing should just not show operator redo properties, and the active tool would stick.

+1 (can be an operator flag)

If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace.

I'd like to get the toolsystem further used/developed, and review top-bar code, then maybe have s meeting on this topic.
Currently I don't have a good handle on all aspects of this issue.

Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a wait_for_input option which isn't much hassle).

This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator.

Personally I don't believe in this design/developer team distinction, and think that it's better to avoid the abstraction layer since any non-trivial design changes require a developer anyway.

The difference I was getting at - is templates will exist outside of Blender (like add-ons). Irrespective of how we divide work internally - people will be customizing Blender and how operators are exposed as tools.

Blender 101 is a test-case where we will be trying out things that are not very blender like :) - if we can do this without making hard coded changes to tools, its a good sign that others can customize Blender for their uses too.

> In #53047#468881, @brecht wrote: > I don't have good answers for these. But to me it seems that having an operator and tool system running side by side kind of pushes the problem to the users. If you can have e.g. both a circle select tool and circle select operator active, that seems very confusing. I think Blender should explicitly prevent that kind of thing, by design. > Agree, for the moment I don't see a problem to keep developing the tool-system and postpone some decisions. (some of these seem more related to the top-bar). OTOH - if once we're *waiting* on decisions like this. We will need to make a decision on how these things fit together. >> In #53047#468743, @ideasman42 wrote: >> - It's common for a modifier key to call the operator with different arguments, eg: holding shift drag to circle de-select instead of select. > > The tool could either ignore this modifier key, or use it to set initialize a tool property to invert the selection. Though maybe I'm not understanding the issue. A problem with this is the tool is checking for modifier keys in its invoke (effectively hard coding the keymap). >> - We may want to call different operators based on input when a tool is active. eg, LMB to draw, hold a key to sample or draw using a different method. While not a majority of tools, there are enough cases like this I ran into. >> - We may want a single tool to bind multiple operators, with poll functions falling through to other operators (edit or pass through to create if no data exists). >> - In rare cases one operator might be accessed by different tools `TRANSFORM_OT_transform(mode='BONE_ROLL')` for eg. Realize in this example we might be better off making bone roll into its own operator. >> >> Even ignoring bone-roll, a draw tool might have straight-line option which is an option for a more general draw operator. > > I don't have a good overview of what these cases are. But for something like a paint tool, perhaps sampling colors or drawing should just not show operator redo properties, and the active tool would stick. +1 (can be an operator flag) > > If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace. > I'd like to get the toolsystem further used/developed, and review top-bar code, then maybe have s meeting on this topic. Currently I don't have a good handle on all aspects of this issue. >> - Having tools defined outside the operator allows for more flexibility in the template, so Blender101 can define a tool one way, the default configuration can access it differently (typically with a `wait_for_input` option which isn't much hassle). >> >> This way a tool could be draw/erase, select/deselect, subdivide/dissolve... so the design team can compose tools without needing to hard code them into the operator. > > Personally I don't believe in this design/developer team distinction, and think that it's better to avoid the abstraction layer since any non-trivial design changes require a developer anyway. The difference I was getting at - is templates will exist outside of Blender (like add-ons). Irrespective of how we divide work internally - people will be customizing Blender and how operators are exposed as tools. Blender 101 is a test-case where we will be trying out things that are not very *blender* like :) - if we can do this without making hard coded changes to tools, its a good sign that others can customize Blender for their uses too.

Germano Cavalcante commented

2017-11-08 03:45:59 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2017-11-08 03:45:59 +01:00

Good proposal! The Tool System is really a good and practical idea :)
As a suggestion, I propose to leave the tools toggleable. Toggle between active and disabled.
This would prevent the user from choosing a tool as the default. And it could help beginners

Good proposal! The Tool System is really a good and practical idea :) As a suggestion, I propose to leave the tools toggleable. Toggle between active and disabled. This would prevent the user from choosing a tool as the default. And it could help beginners

Przemyslaw Golab (SirPigeonz) commented

2017-11-11 20:14:41 +01:00

Added subscriber: @SirPigeonz

Jonathan Williamson commented

2017-11-14 16:41:50 +01:00

If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace.

I'd like to get the toolsystem further used/developed, and review top-bar code, then maybe have s meeting on this topic. Currently I don't have a good handle on all aspects of this issue.

This is a tricky part to get right. I'm going to test the current implementation a bunch more and then would be keen to do a meeting as well @ideasman42

>>If we need to have both systems, then I think it should probably be the active tool that shows in the top bar instead of the redo properties. Since I guess the hierarchy then is more Mode > Tool > Operator, and anything modal should probably be clearly indicated at the top of the workspace. >I'd like to get the toolsystem further used/developed, and review top-bar code, then maybe have s meeting on this topic. Currently I don't have a good handle on all aspects of this issue. This is a tricky part to get right. I'm going to test the current implementation a bunch more and then would be keen to do a meeting as well @ideasman42

Alberto Velázquez commented

2017-11-18 11:29:47 +01:00

Added subscriber: @AlbertoVelazquez

Alberto Velázquez commented

2017-11-18 11:29:47 +01:00

This idea is really great first step to create some complex tools like topology tools, addons and similar. Tools that need a specific space and hotkeys to be used.

My point of view like user is that it hard to understand in a first moment that you replace the cursor selection tool with other tool. The logic told me that when I press escape I may exit of selected tool and go back to the cursor default functionality. It's a problem in some tools, like polybuild, that change the way that works the select click with shift key.

This idea is really great first step to create some complex tools like topology tools, addons and similar. Tools that need a specific space and hotkeys to be used. My point of view like user is that it hard to understand in a first moment that you replace the cursor selection tool with other tool. The logic told me that when I press escape I may exit of selected tool and go back to the cursor default functionality. It's a problem in some tools, like polybuild, that change the way that works the select click with shift key.

Ray Mairlot commented

2017-11-21 12:15:58 +01:00

Added subscriber: @RayMairlot

Luciano Muñoz Sessarego commented

2018-09-20 21:18:50 +02:00

Added subscriber: @LucianoMunoz

Luciano Muñoz Sessarego commented

2018-09-20 21:18:50 +02:00

I bumbed into this video: https://youtu.be/xiuCqrffpIk?t=191
and shows a little bit how these kind of manipulators could improve experience for text editing aswel, like in this case kerning, just watch a few seconds at the frame I posted.

I bumbed into this video: https://youtu.be/xiuCqrffpIk?t=191 and shows a little bit how these kind of manipulators could improve experience for text editing aswel, like in this case kerning, just watch a few seconds at the frame I posted.

Lapineige commented

2019-02-13 10:07:35 +01:00

Added subscriber: @Lapineige