Tools Workflow #37554

New Issue

William Reynish · 2013-11-20T16:12:54+01:00

William Reynish commented

2013-11-20 16:12:54 +01:00

One of the main UI issues in Blender is the workflow of tools. There are a number of issues, some of them nicely outlined by Brecht at the Blender Conference.

Main identified issues:

Modal toolbar items (Such as Grab, Rotate, Scale**) immediately execute from the current cursor position**, rendering them almost useless when accessed from the toolbar or menu
Operator 'redo'-panel (Tool Settings)is for tools in all areas of Blender, but is only accessible in the 3D View, and only inside the toolbar (invisible when toolbar is closed)
Some tools are non-modal (Subdivide, Spin, Poke), yet others are modal (Transform, Knife Cut, Loop Cut etc). How do we distinguish them?
3D manipulators are disconnected from their tools. The manipulators for Translate, Rotate, Scale are not associated with the Grab, Rotate and Scale tools, and there are only manipulators available for these three tools.
Modal Tool Options allows user to change behavior of some modal operators, but they're poorly displayed in the 3D View header, making them quite hidden. How can we display these to the user better?

@PawelLyczkowski-1 and I have started finding solutions to these issues, here:

http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tools_Workflow

We've both presented solutions that are almost exactly the same.

¨The main concept that we've both outlined is that when enabling a tool, it should not immediately begin to register cursor movement to control the tool, but wait for users to interact with it in the 3D VIew (or any given editor)

Concrete example: Extrude

Before:

User clicks Extrude in the toolbar
Blender immediately registers the cursor position relative to the item
User moves cursor around but is constrained by the screen area.
User gives up :) Many extrusions are impossible or difficult because of this

After:

User clicks Extrude in the toolbar
Manipulators appear on the selected item (vertes, edge or face)
The user is then free to drag anywhere in the 3D View to perform a free-form extrusion, or use the manipulators to extrude from the normal, or type numerical input in the tool settings pane

Advantages:

Tools can be invoked from the toolbar and still work (yay)
Things like Paint Selection and Greace Pencil would co-exist better in this system, because you may need multiple 'strokes'
Unifies manipulators and tools, and enables manipulators for more than just Grab, Rotate and Scale (and cleans up the GUI at the same time)

I think these issues are some of the most important fundamental user-facing problems we have in Blender, and makes many basic tools very difficult to use. This design topic is for discussing the issues and solutions presented.

One of the main UI issues in Blender is the workflow of tools. There are a number of issues, some of them nicely outlined by Brecht at the Blender Conference. **Main identified issues:** - **Modal toolbar items** (Such as Grab, Rotate, Scale**) immediately execute from the current cursor position**, rendering them almost useless when accessed from the toolbar or menu - **Operator 'redo'-pane**l (Tool Settings)**is for tools in all areas of Blender**, but is **only accessible in the 3D View**, and only inside the toolbar (invisible when toolbar is closed) - Some tools are non-modal (Subdivide, Spin, Poke), yet others are modal (Transform, Knife Cut, Loop Cut etc). How do we distinguish them? - **3D manipulators** are **disconnected from their tools**. The manipulators for Translate, Rotate, Scale are not associated with the Grab, Rotate and Scale tools, and there are only manipulators available for these three tools. - **Modal Tool Options** allows user to change behavior of some modal operators, but they're poorly displayed in the 3D View header, making them quite hidden. How can we display these to the user better? @PawelLyczkowski-1 and I have started finding solutions to these issues, here: http://wiki.blender.org/index.php/Dev:Ref/Proposals/UI/Tools_Workflow We've both presented solutions that are almost exactly the same. ¨The main concept that we've both outlined is that when enabling a tool, it should *not* immediately begin to register cursor movement to control the tool, but wait for users to interact with it in the 3D VIew (or any given editor) **Concrete example: Extrude** **Before:** - User clicks Extrude in the toolbar - Blender immediately registers the cursor position relative to the item - User moves cursor around but is constrained by the screen area. - User gives up :) Many extrusions are impossible or difficult because of this **After:** - User clicks Extrude in the toolbar - Manipulators appear on the selected item (vertes, edge or face) - The user is then free to drag anywhere in the 3D View to perform a free-form extrusion, or use the manipulators to extrude from the normal, or type numerical input in the tool settings pane **Advantages:** - Tools can be invoked from the toolbar and still work (yay) - Things like Paint Selection and Greace Pencil would co-exist better in this system, because you may need multiple 'strokes' - Unifies manipulators and tools, and enables manipulators for more than just Grab, Rotate and Scale (and cleans up the GUI at the same time) I think these issues are some of the most important fundamental user-facing problems we have in Blender, and makes many basic tools very difficult to use. This design topic is for discussing the issues and solutions presented.

William Reynish commented

2013-11-20 16:12:54 +01:00

Changed status to: 'Open'

William Reynish commented

2013-11-20 16:12:54 +01:00

Added subscriber: @billrey

Jonathan Williamson commented

2013-11-20 18:19:20 +01:00

Added subscriber: @JonathanWilliamson

Jonathan Williamson commented

2013-11-20 18:19:20 +01:00

The toolbar issue is the biggest problem I believe, and your proposals solve this. No doubt about that. However, there's one big disadvantage to going the route you're suggesting. We will lose the ability to quickly activate and tweak operators with hotkeys.

For example, when modeling, using E you can extrude a selection multiple times in a very short period of time. This lends to a very, very fast modeling workflow when using hotkeys.

Your proposal, unless I'm misunderstanding it, will affectively remove this functionality. Now you will press a hotkey (or button or menu item) to activate the tool, and then you may interact with the tool. This is the way many other packages work, and it makes good sense and is quite effective. But it's also significantly slower.

That being said, I don't think I'm all that opposed to it, as it really does solve a lot of problems and will likely greatly improve the learning curve.

This lack of quick hotkey operations can also be solved by offering Quick versions of some common tools. Similar to the Quick Loop addon from a while back. For tools like Extrude, you have the regular tool version, and then Quick Extrude which is hotkey driven only. This then allows both functionality, but should be limited to only crucial tools (transform, extrude, etc).

The toolbar issue is the biggest problem I believe, and your proposals solve this. No doubt about that. However, there's one big disadvantage to going the route you're suggesting. We will lose the ability to quickly activate and tweak operators with hotkeys. For example, when modeling, using **E** you can extrude a selection multiple times in a very short period of time. This lends to a very, very fast modeling workflow when using hotkeys. Your proposal, unless I'm misunderstanding it, will affectively remove this functionality. Now you will press a hotkey (or button or menu item) to activate the tool, and then you may interact with the tool. This is the way many other packages work, and it makes good sense and is quite effective. But it's also significantly slower. That being said, I don't think I'm all that opposed to it, as it really does solve a lot of problems and will likely greatly improve the learning curve. This lack of quick hotkey operations can also be solved by offering **Quick** versions of some common tools. Similar to the **Quick Loop** addon from a while back. For tools like Extrude, you have the regular tool version, and then Quick Extrude which is hotkey driven only. This then allows both functionality, but should be limited to only crucial tools (transform, extrude, etc).

Brecht Van Lommel commented

2013-11-20 18:30:49 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2013-11-20 18:30:49 +01:00

Does this only affect the tools when executed form the toolbar and menu, or also when pressing shortcut keys in the view?

Fuzzy for me here is how modal these tools would be exactly. Modal tools while running right now block any other access to the user interface or to shortcut keys for activating other tools, rather the shortcut keys are reserved for actions within the tool (like constraining along some axis).

The solution that fits the easiest with the current design is to press Extrude and keep it totally modal, you can only click on the widget in the 3D view and extrude once basically, then the tool is done. If you can still do other things in the UI while this tool is active or after you've done it once, you're changing the object > action > setting paradigm for these tools and making it work almost like e.g. paint program tools. You then get questions like:

How do you select things with this widget in the way?
What happens with modal tool shortcut keys that conflict with shortcut keys to activate other tools or do other things?
What happens when you change selection, does the extrude tool stay active somehow and track what the user is doing to update its widget position, and get disabled when exiting the relevant mode?
Do tool settings affect the previous or future actions of the tool, are they editable before you click the widget?

Does this only affect the tools when executed form the toolbar and menu, or also when pressing shortcut keys in the view? Fuzzy for me here is how modal these tools would be exactly. Modal tools while running right now block any other access to the user interface or to shortcut keys for activating other tools, rather the shortcut keys are reserved for actions within the tool (like constraining along some axis). The solution that fits the easiest with the current design is to press Extrude and keep it totally modal, you can only click on the widget in the 3D view and extrude once basically, then the tool is done. If you can still do other things in the UI while this tool is active or after you've done it once, you're changing the object > action > setting paradigm for these tools and making it work almost like e.g. paint program tools. You then get questions like: * How do you select things with this widget in the way? * What happens with modal tool shortcut keys that conflict with shortcut keys to activate other tools or do other things? * What happens when you change selection, does the extrude tool stay active somehow and track what the user is doing to update its widget position, and get disabled when exiting the relevant mode? * Do tool settings affect the previous or future actions of the tool, are they editable before you click the widget?

Paweł Łyczkowski commented

2013-11-21 00:35:53 +01:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2013-11-21 00:35:53 +01:00

Tool modes should be provided for all operations that need to be in the toolbar, and that use mouse position for a starting point - to fix the broken ones. This does not mean that the instant operation mode should be removed, although it would be advisable to minimize the amount of operators that would have both modes (tool mode and instant operation mode).

Changing the cursor would be the main indication to the user that he is in a tool mode, along with the tool name in the Redo Panel.

This is how I would envision the tool mode for Extrude:
If nothing selected - clicking on an element would start to extrude it, working as currently, with the exception that you stay in the tool after confirming extrusion with left click. RMB to end.
If something selected - clicking selection, after extruding selection stays, tool does not close, user can extrude the same selection again. RMB to end.

The addition of the tool mode does not change the current behaviour of the hotkeys (instant operation mode), although the tool mode of these operations would be accessed by using modifier+hotkey (Alt-E for Extrude Tool).

Later on it can be also decided on a per operation basis whether a tool mode or an instant operation mode is preferable. I can see some examples where switching to tool mode could be beneficial (Loop Cut and Slide).

Tool modes should be provided for all operations that need to be in the toolbar, and that use mouse position for a starting point - to fix the broken ones. This does not mean that the instant operation mode should be removed, although it would be advisable to minimize the amount of operators that would have both modes (tool mode and instant operation mode). Changing the cursor would be the main indication to the user that he is in a tool mode, along with the tool name in the Redo Panel. This is how I would envision the tool mode for Extrude: If nothing selected - clicking on an element would start to extrude it, working as currently, with the exception that you stay in the tool after confirming extrusion with left click. RMB to end. If something selected - clicking selection, after extruding selection stays, tool does not close, user can extrude the same selection again. RMB to end. The addition of the tool mode does not change the current behaviour of the hotkeys (instant operation mode), although the tool mode of these operations would be accessed by using modifier+hotkey (Alt-E for Extrude Tool). Later on it can be also decided on a per operation basis whether a tool mode or an instant operation mode is preferable. I can see some examples where switching to tool mode could be beneficial (Loop Cut and Slide).

William Reynish commented

2013-11-21 10:31:22 +01:00

@JonathanWilliamson: Hotkey use could stay the same as now, or it could invoke tools in the same way as the toolbar. Not really sure what makes the most sense. Having hotkeys activate tools in a different way from using tools in the toolbar might be a bit weird, but may make sense to keep the speed of the current system when using hotkeys?

@brecht: I don't think it changes the object > action > setting paradigm. First you click select, say, a face (object) then click Extrude (action), then drag out the extrusion (setting). Same as now, the main difference being that the user is not forced to perform the action immediately from the initial placement on the screen. The other different being that the user can skip dragging on the screen entirely and directly type in numerical values into the 'tool settings' pane.

Making tools completely block the entire UI while interacting with them doesn't fit this paradigm. As for the 'tool options' while transforming (x, y, z to constrain etc), those would be unified with the Tool Settings (Operator 'redo').

Currently, Extrude works like this:
As the user clicks Extrude or hits the E-key the user is forced into 'extrude from normal' mode, and the entire UI is blocked. Then afterward the user can change extrusion settings. This is a weird two-step process.

Proposed version of Extrude:
The user clicks Extrude, then the user can immediately access the tool settings or directly drag out extrusions in the 3D View. The tool settings reflect the extrusion made and visa versa.

Notes: Nothing would be blocked. The user can switch to other tools freely, rotate the viewport or do as he/she pleases. The user would not be forced to do an 'extrude from normal' as one does now.

Blender currently has two types of tools: The types that let you just invoke them (Subdivide) and then play with the associated settings, and the type that blocks the entire UI (Extrude), and only after setting it can you tweak its settings. There is no good reason why they should be different. For example, it might be useful for users to be able to directly drag in the 3D View while subdividing to set the number of subdivisions.

This paradigm unifies both types of tools to use a single interaction method:

Select something
Invoke tool

Click & drag to set or type in numerical values in the tool settings

Additionally, it unifies manipulators with their respective tools (paving way for manipulators on more tools), and it unifies the odd 'header hotkey tool settings' in tools such as Knife with the Tool Settings proper.

@JonathanWilliamson: Hotkey use could stay the same as now, or it could invoke tools in the same way as the toolbar. Not really sure what makes the most sense. Having hotkeys activate tools in a different way from using tools in the toolbar might be a bit weird, but may make sense to keep the speed of the current system when using hotkeys? @brecht: I don't think it changes the object > action > setting paradigm. First you click select, say, a face (*objec*t) then click Extrude (*action*), then drag out the extrusion (*setting*). Same as now, the main difference being that the user is not forced to perform the action immediately from the initial placement on the screen. The other different being that the user can skip dragging on the screen entirely and directly type in numerical values into the 'tool settings' pane. Making tools completely block the entire UI while interacting with them doesn't fit this paradigm. As for the 'tool options' while transforming (x, y, z to constrain etc), those would be unified with the Tool Settings (Operator 'redo'). **Currently, Extrude works like this:** As the user clicks Extrude or hits the E-key the user is forced into 'extrude from normal' mode, and the entire UI is blocked. Then afterward the user can change extrusion settings. This is a weird two-step process. **Proposed version of Extrude:** The user clicks Extrude, then the user can immediately access the **tool settings** *or* **directly drag out extrusions** in the 3D View. The tool settings reflect the extrusion made and visa versa. **Notes:** Nothing would be blocked. The user can switch to other tools freely, rotate the viewport or do as he/she pleases. The user would not be forced to do an 'extrude from normal' as one does now. Blender currently has two types of tools: The types that let you just invoke them (Subdivide) and then play with the associated settings, and the type that blocks the entire UI (Extrude), and only after setting it can you tweak its settings. There is no good reason why they should be different. For example, it might be useful for users to be able to directly drag in the 3D View while subdividing to set the number of subdivisions. This paradigm unifies both types of tools to use a single interaction method: - Select something - Invoke tool # Click & drag to set *or* type in numerical values in the tool settings Additionally, it unifies manipulators with their respective tools (paving way for manipulators on more tools), and it unifies the odd 'header hotkey tool settings' in tools such as Knife with the Tool Settings proper.

Paweł Łyczkowski commented

2013-11-21 12:28:22 +01:00

@billrey

The user clicks Extrude, then the user can immediately access the tool settings or directly drag out extrusions in the 3D View. The tool settings reflect the extrusion made and visa versa.

The user would not be forced to do an 'extrude from normal' as one does now.

I don't quite yet get this. What does "directly drag out extrusions" mean? Is the user only able to drag out extrusions on single faces for example? Does he click, move mouse, click to confirm to extrude, or click-and-hold, move mouse, release?

I did some research today - the workflow I described above is quite common. It has some Cons though: You can't change the selection while in tool mode, and you can't access the rest of the interface.

To allow for changing the selection during tool mode, LMB would have to be freed up - this can be achieved by introducing little widgets in the 3dview in the center of each selection island, or a single widget in the center of the whole selection. Clicking on the widget would start the extrude operation for the selection island, or in the second case - for the whole selection. The operation would work as currently. LMB to confirm and stay in tool mode, selection unchanged. RMB to cancel, selection unchanged. RMB in tool mode to end tool mode, selection unchanged.

Con to the whole tool concept - we lose the numerical inputs in the Redo Panel. 3ds max solves this by always providing both modes if possible - tool mode where you can do multiple organic (non-numerical) changes, and an instant operation mode with numerical controls. The latter is provided in the GUI as a little button next to the tool button.

@billrey >The user clicks Extrude, then the user can immediately access the tool settings or directly drag out extrusions in the 3D View. The tool settings reflect the extrusion made and visa versa. >The user would not be forced to do an 'extrude from normal' as one does now. I don't quite yet get this. What does "directly drag out extrusions" mean? Is the user only able to drag out extrusions on single faces for example? Does he click, move mouse, click to confirm to extrude, or click-and-hold, move mouse, release? I did some research today - the workflow I described above is quite common. It has some Cons though: You can't change the selection while in tool mode, and you can't access the rest of the interface. To allow for changing the selection during tool mode, LMB would have to be freed up - this can be achieved by introducing little widgets in the 3dview in the center of each selection island, or a single widget in the center of the whole selection. Clicking on the widget would start the extrude operation for the selection island, or in the second case - for the whole selection. The operation would work as currently. LMB to confirm and stay in tool mode, selection unchanged. RMB to cancel, selection unchanged. RMB in tool mode to end tool mode, selection unchanged. Con to the whole tool concept - we lose the numerical inputs in the Redo Panel. 3ds max solves this by always providing both modes if possible - tool mode where you can do multiple organic (non-numerical) changes, and an instant operation mode with numerical controls. The latter is provided in the GUI as a little button next to the tool button.

Josiah Jack commented

2013-11-21 13:15:20 +01:00

Added subscriber: @WilliamJack

Josiah Jack commented

2013-11-21 13:15:20 +01:00

@PawelLyczkowski-1: I believe @billrey's use case would be the following:

Button Workflow:

Select element (or not).
Click tool button in shelf or invoke from menu to "pick up" the tool.
(select element if you haven't) Click and drag in 3D view OR Click and drag on tool specific widget that has now appeared if or after a selection to perform action.
OR
Enter values in tool properties panel in the tool shelf.

Hotkey Workflow:
(Same as current usage)

Select element
Press hotkey
Move mouse
Click to accept
Tweak in the tool properties panel on the tool shelf.

New hotkey workflow when nothing is selected:

Press hotkey
....Behaves the same as if user invokes from a menu or button as above in Button Workflow.

@PawelLyczkowski-1: I believe @billrey's use case would be the following: Button Workflow: 1. Select element (or not). 2. Click tool button in shelf or invoke from menu to "pick up" the tool. 3. (select element if you haven't) Click and drag in 3D view OR Click and drag on tool specific widget that has now appeared if or after a selection to perform action. OR Enter values in tool properties panel in the tool shelf. Hotkey Workflow: (Same as current usage) 1. Select element 2. Press hotkey 3. Move mouse 4. Click to accept 5. Tweak in the tool properties panel on the tool shelf. New hotkey workflow when nothing is selected: 1. Press hotkey ....Behaves the same as if user invokes from a menu or button as above in Button Workflow.

Josiah Jack commented

2013-11-21 13:39:59 +01:00

Sorry for the double post but....
This paradigm of having the tool active (pick it up and then set it down) lends another possibility. Typically, the user would be able to hit enter or click an Accept button in the tool shelf to "set the tool down" and deactivate it. If the user wanted to keep the tool active, they could either press a modifier key with enter (e.g. SHIFT+ENTER) to perform the action and keep the tool active so the user could for instance chain extrude an edge loop. Also a check box could be added next to the Accept button to "Keep tool active" for infinite uses in a row until the user presses ESCAPE or clicks a cancel button in the tool panel.

Sorry for the double post but.... This paradigm of having the tool active (pick it up and then set it down) lends another possibility. Typically, the user would be able to hit enter or click an Accept button in the tool shelf to "set the tool down" and deactivate it. If the user wanted to keep the tool active, they could either press a modifier key with enter (e.g. SHIFT+ENTER) to perform the action and keep the tool active so the user could for instance chain extrude an edge loop. Also a check box could be added next to the Accept button to "Keep tool active" for infinite uses in a row until the user presses ESCAPE or clicks a cancel button in the tool panel.

Aditia A. Pratama commented

2013-11-21 14:04:24 +01:00

Added subscriber: @AditiaA.Pratama

Bintang Senja Pratama commented

2013-11-21 15:06:45 +01:00

Added subscriber: @BintangSenja

William Reynish commented

2013-11-21 15:15:50 +01:00

@WilliamJack:

Button Workflow:
- Select element (or not).
- Click tool button in shelf or invoke from menu to "pick up" the tool.
- (select element if you haven't) Click and drag in 3D view OR Click and drag on tool specific widget that has now appeared if or after a selection to perform action.
- OR Enter values in tool properties panel in the tool shelf.**

Yes indeed, that is what I meant.

I'm a bit indifferent to the idea that it should work even if no items are selected (adding a select step). I don't think that's really necessary, although it's an interesting idea.

You'd be able to perform all the same extrusions, extrude multiple faces etc. It all works with the selected items, exactly as it does now.

@WilliamJack: *Button Workflow:* *- Select element (or not).* *- Click tool button in shelf or invoke from menu to "pick up" the tool.* *- (select element if you haven't) Click and drag in 3D view OR Click and drag on tool specific widget that has now appeared if or after a selection to perform action.* *- OR Enter values in tool properties panel in the tool shelf.*** Yes indeed, that is what I meant. I'm a bit indifferent to the idea that it should work even if no items are selected (adding a select step). I don't think that's really necessary, although it's an interesting idea. You'd be able to perform all the same extrusions, extrude multiple faces etc. It all works with the selected items, exactly as it does now.

Brecht Van Lommel commented

2013-11-21 15:29:17 +01:00

@billrey: it's still not clear to me. When you click to start such a tool, I think you would end up in some kind of mode and I'm trying to figure out what that mode is exactly.

For example if left clicking in the 3D view will no longer select but extrude instead, or for a transform tool pressing X will no longer delete but instead constrain something along the X axis, etc, then it's certainly blocking some other part of the interface temporarily. And so you need a clear way to communicate that a user is in this mode, and a clear way to end that mode.

If the user immediately (except maybe some view navigation) does the extrude in the 3D view after clicking in the toolbar, then the mode can be ended and it's clear. But since it's non blocking they can go do something else too, maybe in some completely unrelated editor, and when they come back they are still in this extrude mode and their mouse buttons and shortcut keys don't work as usual.

So that's why it's unclear to me how this can be non-blocking. If you do the 'expected' thing and extrude immediately in the 3D view it may as well have been blocking the rest of the interface (because you didn't use it anyway), and if you do something else you have this kind of persistent tool like an image editor.

Or maybe you envision this more like the transform manipulators, where selecting the tool will show e.g. an "extrude manipulator" on the selection, which doesn't block anything more than the existing transform manipulators. That's more like a light kind of 'mode'.

@billrey: it's still not clear to me. When you click to start such a tool, I think you would end up in some kind of mode and I'm trying to figure out what that mode is exactly. For example if left clicking in the 3D view will no longer select but extrude instead, or for a transform tool pressing X will no longer delete but instead constrain something along the X axis, etc, then it's certainly blocking some other part of the interface temporarily. And so you need a clear way to communicate that a user is in this mode, and a clear way to end that mode. If the user immediately (except maybe some view navigation) does the extrude in the 3D view after clicking in the toolbar, then the mode can be ended and it's clear. But since it's non blocking they can go do something else too, maybe in some completely unrelated editor, and when they come back they are still in this extrude mode and their mouse buttons and shortcut keys don't work as usual. So that's why it's unclear to me how this can be non-blocking. If you do the 'expected' thing and extrude immediately in the 3D view it may as well have been blocking the rest of the interface (because you didn't use it anyway), and if you do something else you have this kind of persistent tool like an image editor. Or maybe you envision this more like the transform manipulators, where selecting the tool will show e.g. an "extrude manipulator" on the selection, which doesn't block anything more than the existing transform manipulators. That's more like a light kind of 'mode'.

Jonathan Williamson commented

2013-11-21 15:35:14 +01:00

@brecht @billrey I suspect this is going to be one of those implementations that's really difficult to really grasp and see all implications as just static proposals. Is there someone that'd be willing to code a single, sample tool to test all of this? The extrude tool is perhaps one of the most important, and most common, and so seeing a sample extrude tool using this proposal would go a long ways towards clearing everything up.

William Reynish commented

2013-11-21 15:59:06 +01:00

@brecht: As @JonathanWilliamson mentions, it's the kind of thing that's hard to explain without making a working propotype.

I guess you could call it a 'mode', but I'd rather think of it as an 'active tool'. This may be semantics, but with a mode you usually mean that things change. That suddenly things work in a different way.

With any given tool, I don't think you'd want things like shortcuts to change. Like you say, it'd be confusing if suddenly X no longer deletes, but constrains on an axis instead. If each tool could entirely replace or override the keymap, that'd be very confusing.

Instead, as you say, one could think of it more like simply enabling transform manipulators, which isn't really a mode I don't think.

So, keeping with the example of Extrude:

User clicks Extrude
Manipulators appear on the selected item(s), the Tool Settings panel appears in a non-overlapping, non-blocking areas with Extrude settings.
Changing the Extrude settings in the tool settings allows you to create extrusions numerically, or, the user drags the manipulator, it extrudes out too.
No keymaps or anything else changes. The user can freely alernate between tweaking the extrusion visually in the 3D View, or numerically in the tool settings pane (There's no first extrude out, then tweak)

An alternate version of the workflow would be that users can click-and-drag anywhere in the 3D View to pull the extrusion around when that tool is active. It's more modal, because the tool takes over the left mouse button, but it means the tool can work even without manipulators, and allows for a larger target hit area.

@brecht: As @JonathanWilliamson mentions, it's the kind of thing that's hard to explain without making a working propotype. I guess you could call it a 'mode', but I'd rather think of it as an 'active tool'. This may be semantics, but with a mode you usually mean that things change. That suddenly things work in a different way. With any given tool, I don't think you'd want things like shortcuts to change. Like you say, it'd be confusing if suddenly X no longer deletes, but constrains on an axis instead. If each tool could entirely replace or override the keymap, that'd be very confusing. Instead, as you say, one could think of it more like simply enabling transform manipulators, which isn't really a mode I don't think. So, keeping with the example of Extrude: - User clicks Extrude - Manipulators appear on the selected item(s), the Tool Settings panel appears in a non-overlapping, non-blocking areas with Extrude settings. - Changing the Extrude settings in the tool settings allows you to create extrusions numerically, or, the user drags the manipulator, it extrudes out too. - No keymaps or anything else changes. The user can freely alernate between tweaking the extrusion visually in the 3D View, or numerically in the tool settings pane (There's no first extrude out, then tweak) An alternate version of the workflow would be that users can click-and-drag anywhere in the 3D View to pull the extrusion around when that tool is active. It's more modal, because the tool takes over the left mouse button, but it means the tool can work even without manipulators, and allows for a larger target hit area.

Brecht Van Lommel commented

2013-11-21 16:15:11 +01:00

If a python coder wants to prototype this to help us figure out the design, that would be great. Do we have anyone in mind or reading this? Otherwise we can mail bf-python to ask.

(Also marked this as low priority not because it's not important, but because it will not be for the next release).

If a python coder wants to prototype this to help us figure out the design, that would be great. Do we have anyone in mind or reading this? Otherwise we can mail bf-python to ask. (Also marked this as low priority not because it's not important, but because it will not be for the next release).

Jonathan Williamson commented

2013-11-21 16:17:28 +01:00

@brecht I can ask Patrick Moore, he is the coder I'm working with on Contours. He's quite busy though, so probably doubtful.

Paweł Łyczkowski commented

2013-11-21 16:32:55 +01:00

@JonathanWilliamson You can see various implementations of this idea in other apps.

Click and drag in 3D

That way you loose the constrain options.

For example if left clicking in the 3D view will no longer select but extrude instead, or for a transform tool pressing X will no longer delete but instead constrain something along the X axis, etc, then it's certainly blocking some other part of the interface temporarily.

It is indeed convoluted. For instance what happens to the Manipulator when we are in a tool mode that uses it's own manipulator(s)? It should be hidden, but that way the icon to show the Manipulator greys out or does nothing when clicked and we have a mess.

Possible solution - let through only the navigation events, like how the Knife tool works currently, and maybe the ability to click and change the tool settings in GUI elements (not with shortcuts as currently).

Another solution - ignore the Manipulator problem state above, or make the Manipulator a part of a Transform tool. Use tools that use two states - dormant and active. When in dormant state, navigation and selection operations are allowed in the 3d View, other operators are not (hotkeys for them do not work). This state is indicated with a mouse cursor in the 3d View and a tool name and settings in the top bar, as in Brecht's mockup, or in the Redo panel if that does not work out. When the mouse leaves the 3d View area it goes back to it's normal appearance, and the rest of the GUI can be interacted with. When the user clicks on the widget (no click-and-drag) tool goes into active mode that works as currently (to mode you are in when in the middle of the Extrude operation). Here you can use XYZ hotkeys and numbers. After LMB to confirm, tool goes back to dormant mode. The content of the tool settings would be settings like how the tool will behave, and, separated, settings for the last operation.

@JonathanWilliamson You can see various implementations of this idea in other apps. >Click and drag in 3D That way you loose the constrain options. >For example if left clicking in the 3D view will no longer select but extrude instead, or for a transform tool pressing X will no longer delete but instead constrain something along the X axis, etc, then it's certainly blocking some other part of the interface temporarily. It is indeed convoluted. For instance what happens to the Manipulator when we are in a tool mode that uses it's own manipulator(s)? It should be hidden, but that way the icon to show the Manipulator greys out or does nothing when clicked and we have a mess. Possible solution - let through only the navigation events, like how the Knife tool works currently, and maybe the ability to click and change the tool settings in GUI elements (not with shortcuts as currently). Another solution - ignore the Manipulator problem state above, or make the Manipulator a part of a Transform tool. Use tools that use two states - dormant and active. When in dormant state, navigation and selection operations are allowed in the 3d View, other operators are not (hotkeys for them do not work). This state is indicated with a mouse cursor in the 3d View and a tool name and settings in the top bar, as in Brecht's mockup, or in the Redo panel if that does not work out. When the mouse leaves the 3d View area it goes back to it's normal appearance, and the rest of the GUI can be interacted with. When the user clicks on the widget (no click-and-drag) tool goes into active mode that works as currently (to mode you are in when in the middle of the Extrude operation). Here you can use XYZ hotkeys and numbers. After LMB to confirm, tool goes back to dormant mode. The content of the tool settings would be settings like how the tool will behave, and, separated, settings for the last operation.

William Reynish commented

2013-11-21 16:43:43 +01:00

@PawelLyczkowski-1:

"Click and drag in 3D, That way you loose the constrain options."

You wouldn't loose constraint options, because they'd be available in the tool settings, rather than the 'secret header tool hotkey thing'

"For instance what happens to the Manipulator when we are in a tool mode that uses it's own manipulator(s)?"

Don't quite understand. You mean what happens to the old manipulators? They would conflict with this paradigm. Solution: Remove them.

Your other solution: Sounds interesting. It's a bit hard to follow though, sounds more modal and blocking?

@PawelLyczkowski-1: "Click and drag in 3D, That way you loose the constrain options." You wouldn't loose constraint options, because they'd be available in the tool settings, rather than the 'secret header tool hotkey thing' "For instance what happens to the Manipulator when we are in a tool mode that uses it's own manipulator(s)?" Don't quite understand. You mean what happens to the old manipulators? They would conflict with this paradigm. Solution: Remove them. Your other solution: Sounds interesting. It's a bit hard to follow though, sounds more modal and blocking?

Paweł Łyczkowski commented

2013-11-21 16:59:20 +01:00

they'd be available in the tool settings, rather than the 'secret header tool hotkey thing'

Nice addition. But the X Y Z and numerical input hotkeys are part of what makes Blender such a fast modeler. I would hate to see them go.

>they'd be available in the tool settings, rather than the 'secret header tool hotkey thing' Nice addition. But the X Y Z and numerical input hotkeys are part of what makes Blender such a fast modeler. I would hate to see them go.

Jonathan Williamson commented

2013-11-21 17:01:25 +01:00

I agree with @plyczkowski. The modal XYZ hotkeys are crucial to Blender's speed. They need to stay. That doesn't mean we can't have other manipulators and such though.

William Reynish commented

2013-11-22 00:46:46 +01:00

@JonathanWilliamson, @PawelLyczkowski-1: I guess they could stay while dragging (sort of like it is now).

@JonathanWilliamson, @PawelLyczkowski-1: I guess they could stay *while dragging* (sort of like it is now).

Bartosz Moniewski commented

2013-11-22 01:34:04 +01:00

Added subscriber: @BartekMoniewski

Josiah Jack commented

2013-11-22 03:04:42 +01:00

@JonathanWilliamson & @billrey:
Absolutely the tool specific hotkeys would and should be available while using the tool, which should be Click on manipulator handle and release, then move mouse to perform action along manipulator's path, curve, etc.

(off topic)
'secret header tool hotkey thing'

lol so that's what it's called! Even after using blender for almost 4 years now I still can't remember that it even exists. I only recently discovered that C during vertex slide lets you move it infinitely along the same ray. Blender is awesome.

@JonathanWilliamson & @billrey: Absolutely the tool specific hotkeys would and should be available while using the tool, which should be Click on manipulator handle and release, then move mouse to perform action along manipulator's path, curve, etc. (off topic) 'secret header tool hotkey thing' lol so that's what it's called! Even after using blender for almost 4 years now I still can't remember that it even exists. I only recently discovered that C during vertex slide lets you move it infinitely along the same ray. Blender is awesome.

William Reynish commented

2013-12-01 16:57:31 +01:00

@WilliamJack:

Yes that's totally the official name :)

Joke aside, it's really obscure. It was a hack added in the pre-2.5 days to provide settings for tools. Only later, for 2.5, the non-modal Tool Settings concept was added. That's some tools still use the old system, and some use the new.

These can be nicely unified in a more coherent tools system.

@WilliamJack: Yes that's totally the official name :) Joke aside, it's really obscure. It was a hack added in the pre-2.5 days to provide settings for tools. Only later, for 2.5, the non-modal Tool Settings concept was added. That's some tools still use the old system, and some use the new. These can be nicely unified in a more coherent tools system.

Jonathan Williamson commented

2013-12-01 17:00:35 +01:00

@billrey, I've always called it the "Modal Header Options". This is definitely something that needs addressed.

Diego Gangl commented

2013-12-07 00:05:02 +01:00

Added subscriber: @Januz

DataDay commented

2013-12-17 23:58:44 +01:00

Added subscriber: @DataDay

hewi commented

2014-01-09 23:19:23 +01:00

Added subscriber: @hewi

michael knubben commented

2014-01-13 13:27:19 +01:00

Added subscriber: @michaelknubben

michael knubben commented

2014-01-13 13:27:19 +01:00

Purely as an example here's something I set up in NVIL that could be a solution:

Every tool can be a mode (you call a tool, use it on the mesh by clicking and dragging, and exit) or an immediate action (mouse-movement is immediately used to change a value. Like 'distance' for the Extrude tool.
In NVIL I call the mode by pressing and releasing the hotkey, and get the immediate action by instead holding down the hotkey and moving the mouse. Releasing the hotkey exits the tool. This works kind of like 'Release Confirms' in Blender, although that currently does not work for every tool.

Whatever we end up going for, I hope it doesn't mean abandoning the current system, as it's one of the advantages I think Blender has over Max/Modo/etc. as far as modeling-speed goes.
And similarly, I think things like the paint/marquee-selection are bad because they're so unlike the rest of Blender and feel tacked on.

Purely as an example here's something I set up in NVIL that could be a solution: Every tool can be a mode (you call a tool, use it on the mesh by clicking and dragging, and exit) or an immediate action (mouse-movement is immediately used to change a value. Like 'distance' for the Extrude tool. In NVIL I call the mode by pressing and releasing the hotkey, and get the immediate action by instead holding down the hotkey and moving the mouse. Releasing the hotkey exits the tool. This works kind of like 'Release Confirms' in Blender, although that currently does not work for every tool. Whatever we end up going for, I hope it doesn't mean abandoning the current system, as it's one of the advantages I think Blender has over Max/Modo/etc. as far as modeling-speed goes. And similarly, I think things like the paint/marquee-selection are bad because they're so unlike the rest of Blender and feel tacked on.

Bryce C commented

2014-02-13 12:47:38 +01:00

Added subscriber: @BC369

Bryce C commented

2014-02-13 12:47:38 +01:00

Has this been solved?

I don't know anything about programming but maybe the solution could be to code it in a sequence? Clicking on the toolbar button would select the tool. Clicking on the mesh would activate the tool. Drag the mouse to desired result. Click again to deactivate the tool.

For hotkey use select the mesh. Press the hotkey and the code automatically advances through tool selection----> to tool activation. Drag the mouse to desired result. Click again to deactivate the tool.

Here's a mockup of how this could work....

Has this been solved? I don't know anything about programming but maybe the solution could be to code it in a sequence? Clicking on the toolbar button would select the tool. Clicking on the mesh would activate the tool. Drag the mouse to desired result. Click again to deactivate the tool. For hotkey use select the mesh. Press the hotkey and the code automatically advances through tool selection----> to tool activation. Drag the mouse to desired result. Click again to deactivate the tool. Here's a mockup of how this could work.... ![Slide1.PNG](https://archive.blender.org/developer/F77125/Slide1.PNG) ![Slide2.PNG](https://archive.blender.org/developer/F77127/Slide2.PNG)

Bartosz Moniewski commented

2014-02-13 13:15:40 +01:00

Thats very interesting approach @BC369! In your scenario shortcut usage can stay almost the same which is nice for experienced users.
Question is where to display tool options. In terms of using toolbar your placement is good because options popup under tool button we recently used and that tell user yo tweak them. But on the other hand we have Redo panel with similar functionality and this options will be doing mess with buttons placement in toolbar. Especialy when using shortcuts.

I think interactive Topbar(redo panel + info bar) can solve this. Once user enable extrude tool by button topbar should display all the parameters and "Accept" button. Also informations of modal tools like knife or bevel should go there. Most of modal tools that use cursor placement (extrude, bevel) and are triggered by button instead of hotkey can use single-axis gizmo to set its main value.

Thats very interesting approach @BC369! In your scenario shortcut usage can stay almost the same which is nice for experienced users. Question is where to display tool options. In terms of using toolbar your placement is good because options popup under tool button we recently used and that tell user yo tweak them. But on the other hand we have Redo panel with similar functionality and this options will be doing mess with buttons placement in toolbar. Especialy when using shortcuts. I think interactive Topbar(redo panel + info bar) can solve this. Once user enable extrude tool by button topbar should display all the parameters and "Accept" button. Also informations of modal tools like knife or bevel should go there. Most of modal tools that use cursor placement (extrude, bevel) and are triggered by button instead of hotkey can use single-axis gizmo to set its main value.

Paweł Łyczkowski commented

2014-02-13 19:23:36 +01:00

@BC369 You described what is already in my section in the proposal, except for the tool settings appearing below the button, which is not a good idea (because then settings would appear in different places instead of one - under various buttons, and in the Redo panel - which is against UI design principles), and for the tool deactivating after use, which is also not a good idea (because some tools would be used in fast sequences, like the Move tool, and that would mean finding and clicking a button after every move).

Josiah Jack commented

2014-02-17 04:00:34 +01:00

I believe the Redo panel should be a separate "editor" in the way the Outliner is. I also believe it should be located in the bottom right corner of the Default Layout.
Please see my mockup here: ToolSettings
Since the user typically has to scroll a lot in the properties panel anyways, I don't believe this would be too disruptive. Also, this would then be immediately obvious that it is a globally relevant panel. This would be much better than leaving it in the 3d Viewport, I believe.

A redesign of the layout of the buttons within this panel might be necessary for this to be fully effective, but as it is support for scrolling is already present.

In future releases, this area could also have tabs for history similar to the way photoshop has a history.

What do you think?

I believe the Redo panel should be a separate "editor" in the way the Outliner is. I also believe it should be located in the bottom right corner of the Default Layout. Please see my mockup here: [ToolSettings ](https://dl.dropboxusercontent.com/u/20160676/ToolSettings_Redo_Operator_Panel_Mockup001.jpg) Since the user typically has to scroll a lot in the properties panel anyways, I don't believe this would be too disruptive. Also, this would then be immediately obvious that it is a globally relevant panel. This would be much better than leaving it in the 3d Viewport, I believe. A redesign of the layout of the buttons within this panel might be necessary for this to be fully effective, but as it is support for scrolling is already present. In future releases, this area could also have tabs for history similar to the way photoshop has a history. What do you think?

Josiah Jack commented

2014-02-17 04:07:47 +01:00

@BC369 I really like this concept, however I believe it would be best to have the tool options/settings in the tool settings editor. See my comment above. I think it would be interesting to have this work flow, especially if a face would be highlighted on mouse-over similarly to the Knife tool. However, you lose the ability to select multiple faces. Perhaps a solution like the way Solidworks handles extrusion: SOLIDWORKS EXTRUSION (52sec Video)

(Actually, as an aside, Solidwork's tool flow is similar to what we are discussing. As an engineer myself, I recommend viewing some of their how to videos for some ideas of industry standard tool flows, however I believe that the workflow is way way slower than Blender. )

@BC369 I really like this concept, however I believe it would be best to have the tool options/settings in the tool settings editor. See my comment above. I think it would be interesting to have this work flow, especially if a face would be highlighted on mouse-over similarly to the Knife tool. However, you lose the ability to select multiple faces. Perhaps a solution like the way Solidworks handles extrusion: [SOLIDWORKS EXTRUSION (52sec Video) ](https://www.youtube.com/watch?v=IDbwBWiSxHU) (Actually, as an aside, Solidwork's tool flow is similar to what we are discussing. As an engineer myself, I recommend viewing some of their how to videos for some ideas of industry standard tool flows, however I believe that the workflow is way way slower than Blender. )

Bryce C commented

2014-02-17 09:06:26 +01:00

josiahjack previously I was not aware of plyczkowski proposal but after reviewing it I think he's got the right idea. Though I do really like your idea of having a separate tool setting window. Kind of reminds me of Cinema 4D's Attributes window

Bartosz Moniewski commented

2014-02-17 10:54:42 +01:00

Idea oh having tool settings window was already discussed here: #37450
Horizontal bar for this is better idea because its easier to fit it in different layouts.

Idea oh having tool settings window was already discussed here: #37450 Horizontal bar for this is better idea because its easier to fit it in different layouts.

Sybren A. Stüvel commented

2015-10-25 11:25:47 +01:00

Added subscriber: @dr.sybren

Chris Offner commented

2016-04-03 01:01:16 +02:00

Added subscriber: @chrisoffner3d

Julian Eisel commented

2016-12-20 22:43:35 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2016-12-20 22:43:35 +01:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2016-12-20 22:43:35 +01:00

Julian Eisel self-assigned this 2016-12-20 22:43:35 +01:00

Julian Eisel commented

2016-12-20 22:43:35 +01:00

In the 2.8 UI workshop we agreed on a way to solve the issues mentioned here, basically by implementing the main proposals made here.

Modal toolbar items (Such as Grab, Rotate, Scale**) immediately execute from the current cursor position**, rendering them almost useless when accessed from the toolbar or menu

Just like in the initial proposal, we want to solve this using manipulators. Selecting a tool from the toolbar would activate its manipulators.

Operator 'redo'-panel (Tool Settings)is for tools in all areas of Blender, but is only accessible in the 3D View, and only inside the toolbar (invisible when toolbar is closed)

We want to introduce a global, horizontal top-bar that would show the tool settings.

Some tools are non-modal (Subdivide, Spin, Poke), yet others are modal (Transform, Knife Cut, Loop Cut etc). How do we distinguish them?

This point is not explicitly tackled by our proposed solutions but I don't think it's really an issue for users and their workflows. I also think the separation becomes less important with the manipulator based workflow.

3D manipulators are disconnected from their tools. The manipulators for Translate, Rotate, Scale are not associated with the Grab, Rotate and Scale tools, and there are only manipulators available for these three tools.

In fact the manipulators are just a different way to invoke the operators/tools, but this connection is not really visible for users. The new manipulator oriented tool workflow (of course the shortcut oriented one will still be there) should make the connection clearer.

Modal Tool Options allows user to change behavior of some modal operators, but they're poorly displayed in the 3D View header, making them quite hidden. How can we display these to the user better?

The top-bar would display these options during modal operations.

For more info, read the workshop write-up . Closing this task as resolved since we now know which direction we're aiming for. To define the final designs for the proposed changes, we're better off creating new tasks with more limited scopes. Thanks everyone!

In the 2.8 UI workshop we agreed on a way to solve the issues mentioned here, basically by implementing the main proposals made here. > - **Modal toolbar items** (Such as Grab, Rotate, Scale**) immediately execute from the current cursor position**, rendering them almost useless when accessed from the toolbar or menu Just like in the initial proposal, we want to solve this using manipulators. Selecting a tool from the toolbar would activate its manipulators. > - **Operator 'redo'-pane**l (Tool Settings)**is for tools in all areas of Blender**, but is **only accessible in the 3D View**, and only inside the toolbar (invisible when toolbar is closed) We want to introduce a global, horizontal top-bar that would show the tool settings. > - Some tools are non-modal (Subdivide, Spin, Poke), yet others are modal (Transform, Knife Cut, Loop Cut etc). How do we distinguish them? This point is not explicitly tackled by our proposed solutions but I don't think it's really an issue for users and their workflows. I also think the separation becomes less important with the manipulator based workflow. > - **3D manipulators** are **disconnected from their tools**. The manipulators for Translate, Rotate, Scale are not associated with the Grab, Rotate and Scale tools, and there are only manipulators available for these three tools. In fact the manipulators are just a different way to invoke the operators/tools, but this connection is not really visible for users. The new manipulator oriented tool workflow (of course the shortcut oriented one will still be there) should make the connection clearer. > - **Modal Tool Options** allows user to change behavior of some modal operators, but they're poorly displayed in the 3D View header, making them quite hidden. How can we display these to the user better? The top-bar would display these options during modal operations. For more info, read the [workshop write-up ](https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup). Closing this task as resolved since we now know which direction we're aiming for. To define the final designs for the proposed changes, we're better off creating new tasks with more limited scopes. Thanks everyone!

Bartosz Moniewski commented

2016-12-21 00:24:20 +01:00

The new manipulator oriented tool workflow (of course the shortcut oriented one will still be there)

So operators like Grab, Scale, Rotate, Extrude or Bevel will behave like today when we execute them via shortcut in viewport. Right?
Are there any proposals/docs about separating this behaviors?

> The new manipulator oriented tool workflow (of course the shortcut oriented one will still be there) So operators like Grab, Scale, Rotate, Extrude or Bevel will behave like today when we execute them via shortcut in viewport. Right? Are there any proposals/docs about separating this behaviors?

Julian Eisel commented

2016-12-21 00:45:08 +01:00

So operators like Grab, Scale, Rotate, Extrude or Bevel will behave like today when we execute them via shortcut in viewport. Right?
Are there any proposals/docs about separating this behaviors?

Nothing really specific on this point, but I do recommend to read this -> https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Tool_Workflow
It was never even considered an option to drop the shortcut driven workflow. It was always clear that a solution to the mentioned problems would have to co-exist with the shortcut workflow.

> So operators like Grab, Scale, Rotate, Extrude or Bevel will behave like today when we execute them via shortcut in viewport. Right? > Are there any proposals/docs about separating this behaviors? Nothing really specific on this point, but I do recommend to read this -> https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Tool_Workflow It was never even considered an option to drop the shortcut driven workflow. It was always clear that a solution to the mentioned problems would have to co-exist with the shortcut workflow.

Bartosz Moniewski commented

2016-12-21 00:54:23 +01:00

Thanks for clarifying. I was asking because I actually have brief idea how this might be solved, but since this task is closed I'm not sure where to post it. Should I send it to mailing lists or start new design task under someones permission?

Julian Eisel commented

2016-12-21 01:04:37 +01:00

We should probably prepare some location to leave feedback about the doc at. I'll check on this tomorrow and keep you posted.

Julian Eisel commented

2016-12-31 18:12:31 +01:00

@BartekMoniewski, there doesn't seem a real need for a discussion platform just for the doc, so for general feedback it's best to give it here -> https://code.blender.org/2016/12/highlights-of-workflow-workshop/. If you have a more drafted proposal, feel free to mail to bf-interface first. We can then check on creating a separate design task if needed.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Tools Workflow #37554

Click & drag to set or type in numerical values in the tool settings