I use Alt W pie-menu.
I think I will continue to prefer that kind of switch to Alt Tool access.
There is a need for a switch between active tool and active select tool.
There is a need to ba able to change select tool without quitting an active tool.
There is a need to communicate if it is active tool that is used or select tool.
But there is no need of a popover showing 4 items detailing 4 selection tools to communicate that.
There could be a simple option checkbox or a 2 items buttons switch (Active Tool/Select Tool) in tool settings bar.
RCS have been denatured by the automatic deselection when click is done on nothing.
If Select & Tweak preference was not deselecting current selection, it would be a lot more powerful.
We could have a useful tweak + any other selection tool available as active select tool.
Only the choice of Selection Tool preference provides shortcuts to be able to disable Deselect on Nothing option. But it forces to switch active selection tool to be able to use Tweak tool.
So, whatever the preference is now, we have to switch current active tool.
There is no more superiority of RCS over LCS (except when active tool is a select tool).
But I suppose that Selection Tool preference would be a better default.
All preferences are making sense and should be kept for people using RCS.
IMO, that would make more sense to suppress Translate, Rotate, Scale tools and only keep a unique Transform tool with different modes or to suppress Transform tool and use only object gizmos, than to touch RCS preferences.
Looks like things are just going to get overcomplicated, so Iâd say better leave things as they are. I never saw anyone complaining about that fallback popup panel. Letâs not look for trouble.
I myself Iâm an active tool guy, I donât want my tools to perform box selections or anything else. Click and drag anywhere is the best way to activate the tool. When I need to select stuff, I use a selection tool. So the active tool option is the one I use.
Now, things could be better here if sticky keys were already implemented. Thatâs why this patch is very important â D7055 Experimental preference to support holding keys to transform, tap to activate the tool why on earth it was abandoned?
Also using Alt to activate the tools makes no sense.
Right click and drag to activate the tool? Are you serious? That would be the worst thing ever. Almost on the same level of RCS or the N panel.
Again, better leave things as they are, letâs not fix whatâs not broken.
Same here. Box select is not a thing because of other DCC apps, but because of operating systems in which it is default. You canât get this out of your muscle memory easily after 20+ years of using a computer.
Personally Iâm fine with this living in preferences.
To me the drop down menu is flawed. If I cycle my selection tool to be the lasso tool then switch to rotate tool, then using the drop down menu and switching to the box select for example, it will switch my lasso select tool back to box select. This is not desirable as when I switch back to my lasso tool I find that I need to cycle through to find it again. The drop down menu should behave like an override. Otherwise it could be just a tick box that that uses the current selection tool on drag.
Yes, this is the point I was trying to make. Common user expectation in 3D software as well as outside of it is that one is able to box select in any space where selecting multiple entities is a thing.
So I was trying to explain that the ideal, simple scenario would be that LMB drag always selects, regardless of the tool user is in, and if users want to change that behavior, they should change it selectively for the tools where it makes sense to them. Having global switch, albeit in user preferences, still doesnât sound right, because perhaps youâd want to be able to click drag in the extrude tool, but you still expect selection in move tool. If this behavior is switched globally, for all tools, then itâs the opposite extreme, and doesnât really solve much.
I think you were pretty clear already, I mean I got what you said. I deliberately meant âshare this behaviour across toolsâ because I donât think it would harm the experience much to have a consistent behaviour for fallback tool. In fact I think the current way is unnecessarily complicated and unpredictable : I like to have the fallback set to âbox selectâ for all tools, that way I always know whatâs happening when I click and drag anywhere in the viewport. But itâs hard to judge since most tool gizmos are so botched, I barely use them outside of the regular transform tools.
For me having it in the preferences as a single option (that applies to all tools) works. I prefer not having it in the editor as it clutters things up.
@Hologram Maybe I should add an explanation of the fallback feature in the top. That would clear things up.
Custom keymaps are another topic. Right now none of these preferences are available for imported keymaps anyway. And any of these keymap preferences pose a danger to highly altered ketymaps.
@RonanDucluzeau Thanks for the feedback! Itâs good to hear that some users are also heavily using the Alt + W pie menu.
And thanks to everyone else. Good to hear that the âActive Toolâ fallback setting is also heavily used (Even toggled).
If these settings are used for good reasons by users then itâs a good enough reason they shouldnât be removed.
If I cycle my selection tool to be the lasso tool then switch to rotate tool, then using the drop down menu and switching to the box select for example, it will switch my lasso select tool back to box select
@LudvikKoutny This is also exactly my worry. Perhaps it would be best to at least decouple the fallback setting from the active selection tool.
Iâm also an Alt + W menu user. Iâm not a fan of switching between multiple functions with one key. If I press W a couple of times I often go too far, and have to press it a few times more to get to the function I wanted to activate.
For the same reason B and C are used - because of a direct access, compatible with fast selection modes alternating, so you can carve complex selections fast without paying attention to any kind of UI lists, piemenus, selection modes and submodes.
Alt+W is not even an easily accessible shortcut.
Cycling on W has never been compatible with human motor skills since it was introduced in 3ds max.
I have to say that is not a problem with an azerty keyboard. I donât mind if shortcut was changed. Keymap is customizable. But I would like to preserve the pie-menu and the ability to change fallback tool on the fly.
Canât they be shown directly in tool settings bar instead of inside a popover ?
Currently when Fallback tool is changed using pie-menu, Active Select tool is also modified in toolbar.
So, indication of what tool is used is displayed there.
But yes. If the goal is to avoid any use of keyboard, removing the popover means that user has to cclick to change active tool to desired select tool to configure it before going back to wanted active tool.
So, yes. In that case, all buttons are needed. Is it necessary to have them all in a popover ?
If a row of icons is acceptable for submodes, why canât it be the same for choice of fallback tool ?
But the popover is there because some active tool have a lot of settings.
Couldnât we leave the menu item as is, and just enforce its function to be exact to that of what Photoshop does?
I hate the cycling of âselection modesâ with pressing W. Often I only want to use Box Select, but as some have stated. I sometimes accidentally press W one time too many, ending up on tweak, or lasso selection, etc.
This is what we should do if it saves the effort and headaches. Press W to activate âSelectâ. Whatever the selection is set to, (Box) by default. No matter how many times you press W, it doesnât change. If the user wants to change the selection type. Hover your mouse over the selection icon, and click and hold to see the additional selection types. From there, select the alternative youâd like to replace (box) with.
Problem solved!
If you want box, lasso, or any of the others. Hover your mouse over the icon again, click and hold to see the types. Choose it, and that will replace previous, and will âremainâ the default.
Now Iâll ask everyone, does this seem fair and logical and feasible and less complicated?
Not really. Workstyles for all users will most likely differ too much from your personal experience here. For example I switch between tweak and box frequently and also pfefer Alt+W to select.
Before that I cycled through by several w presses and - yes I overshot often but still better than moving the mouse away from the center of interest for me. And especially better than a click-hold. Those I rarely use because they feel so slow. Already annoys me the few times I switch the modal tools even though itâs fine there).
Yes, moving mouse from the point of interest is incredibly costly, especially during working with complex repetative constructive geometry like in architecture, where everything looks quite similar - walls, windows, beams and columns has no eyes or mouths like in character modeling to define your point of interest, they are all visually sterile, similar, and there are lots of them.
Thus, switching UI elements and even shaking the mouse when using the pie menu is very distracting and requires more concentration due to the loss of the point of interest marked with the mouse cursor.
You both do realize the proposal I made was to bring a resolution on a global universal language level, right?
I am pretty sure anyone who has touched 3D, has spent some decent amount in time in Photoshop, and any other 2D Image editing application that shares a common UI language for tool selections.
Correct me if I am mistaken here, but, doesnât Blender alreadyâŚ
Offer âAssign shortcut Keyâ as a right click function? So if you want to tap a keyboard key for cycling through selection types. That is feasible.
Did I say âAway with those pie menuâs for quick selection typesâ? Obviously those require minimal mouse gestures for quick selections. No matter what you do in Blender, youâll have to move your mouse and click something to activate at some moment. (So I donât know what your points were about thatâŚbecause that point was completely redundant.)
If said proposal Iâve made still rubs you both wrong when re-evaluating the recommendation. I will question you both as to where your intentions are, considering your replies offered no alternatives could have a said better common language solution. Because Iâm open to it. Rather than making common community statements that reside in oppositional terms.
Well, it was time when lots of stuff, including quite obsolete concepts, was pushed without reconciling, no wonder they cause conflicts and heavy fractioning.
Discussing and analysing issues is ok for development process.
It is important to understand and take into account conditions that form the preference for a particular solutions.
