Page MenuHome

Tools, Selection & Gizmo design
Closed, ResolvedPublicDESIGN

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

Description

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

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

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

Motivation

The main issues with the current configuration is:

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

Solution

We can address this like so:

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

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

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

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

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

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

Implications

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

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

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

Gizmos

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

Pros/Cons

Gizmo as Dominant Tool Access

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

Pros:

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

Cons:

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

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

Immediate Tool Activation (Alt-LMB)

Pros:

  • The key is currently free by default.

Cons:

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

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

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

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

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Suggestion:

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

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

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

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

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

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

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

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

I think the system would become more intuitive if ESC switched the active tool to selection.

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

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

xrg (xrg) added a subscriber: xrg (xrg).EditedNov 1 2019, 5:52 PM

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

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

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

Debuk (Debuk) added a subscriber: Debuk (Debuk).EditedNov 4 2019, 11:44 AM

A gizmo as dominant tool access has more pro's than you have listed, eg
-it can easily be used to better present and trigger options, that are right now placed in a hidden popup
-it reduces the overall number of shortcuts needed in blender

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

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

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

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

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

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

Debuk (Debuk) added a comment.EditedNov 12 2019, 3:44 PM

@Stanislav Blinov (radcapricorn): I really like the idea of the overlay.

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

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

Debuk (Debuk) added a comment.EditedNov 12 2019, 11:51 PM

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

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

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

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

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

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

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

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

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

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

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

Nice feature, but there's an issue with how Rotate and Scale tools work in Tweak mode:

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

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

Thanks.

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

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

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

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


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

Asher (ThatAsherGuy) added a comment.EditedDec 15 2019, 2:51 AM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Giuseppe Bufalo (Peps) currently I'm focusing on getting the proposed task finalized.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If only selection was on another mouse key!

/me chuckles

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Stanislav Blinov (radcapricorn) What you are discussing here is *completely* unrelated to this design task. Please move to somewhere different.

Thanks.

@Stanislav Blinov (radcapricorn) What you are discussing here is *completely* unrelated to this design task. Please move to somewhere different.

Thanks.

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

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

-- (zgorg) added a comment.EditedJan 4 2020, 11:54 PM

@Harley Acheson (harley)

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

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

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

@Ludvik Koutny (rawalanche) That is by design, otherwise you would not be able to zoom with the scroll wheel while certain tools are active.