Feedback Wanted: Removing Drag Fallback UI?

[JulienKaspar]

This is a discussion I want to kick off on deciding on this particular UI element in the header and any preferences that relate to it:
The main question: Should this be removed and why?
Feedback from users who actively use it is highly welcome!

General Issues

This is reasoning behind the question above.
These points are coming from others devs and also from my own experience with using this feature for months:

• This popup mostly just duplicates the tool selection in the toolbar
• These settings are too rarely used to justify having this popup (It’s like a soft preference).
• The “Active Tool” setting is never changed and would be better as a preference (More about that below)
• These settings are not intuitive or self explanatory
• The setting is available in almost every Tool even if it doesn’t do anything (Example: Annotation Tools in left click select)

Still, the functionality behind this feature is useful and it has been part of the LCS keymap since 2.80. Being able to Tweak or do any selection method on click & drag would still be there.
But the Drag UI element in the header itself seems unnecessary.

Alternative to “Active Tool” setting

A preference was added to LCS to make it easier to access the “Active Tool” option from the drag settings above.
By holding Alt and click and dragging it will execute the active tool instead of the current selection tool.
This eliminates the need for that UI element and is more convenient to use.
Leftover tasks like T89989 and T93599 will help making this feature feel better to use.

It’s not available when using the “3 mouse button emulation” though.
So perhaps there should be a toggle preference between
A: Using selection tools as drag fallback and holding Alt to use the active tool by click-dragging anywhere
B: Always just using the Active Tool by click-dragging anywhere

Right Click Select

Since 3.0 the selection drag fallback is also available for right click select if one of the preferences is switched:

This setting is fairly hidden and could potentially just be the default (Since it just extends the default behaviour and makes RCS and LCS a bit more consistent).
Especially the ability to right click drag to box select instead of tweaking is a welcome addition.
I don’t know if there are any arguments against removing this preference then.

Questions

Drag UI

• Should the Drag UI element be removed from the tool settings?
• Do you use different drag options (tweak or box/lasso select) per mode/workspace? Or could this be set in the preferences globally?

Active Tool setting

• Should the “Active Tool” option become a preference instead?
• Or is the “Alt Tool Access” preference perhaps enough to replace that option?

RCS

• Is it acceptable to make the new “Right Mouse Selection Action” preference default in RCS
• If yes does it even make sense to remove that option from the preferences?

[Arunderan]

Apparently there are some use cases where some developers thought this could be useful. Else it would not have been implemented.

But I know of nobody who uses this dropdown boxes (corrected) at all, including me. When you want to do a box select, then you turn on the box select tool. And don’t tweak settings in the lasso tool that you can do box select from there. This feature never made any sense to me.

Still, the functionality behind this feature is useful and it has been part of the LCS keymap since 2.80.

What about custom keymaps? Creating a new keymap usually looses all the settings from the default keymap.

[JulienKaspar]

I’m not sure what checkbox you are referring to. Can you elaborate?

When you want to do a box select, then you turn on the box select tool. And don’t tweak settings in the lasso tool that you can do box select from there. This feature never made any sense to me.

To explain, the reason why this feature exists is so that LCS users are able to (for example) box select without having to switch to a box select tool and without having to constantly press the shortcut B. It makes this basic functionality universally available across almost all active tools.
It is not meant for letting the user box select when using the lasso select tool. It’s only there for tools that are not meant for selecting.

Custom keymaps are also a very different topic.

[Arunderan]

Dropdown box, not checkbox . My fault sorry

To explain, the reason why this feature exists is so that LCS users are able to (for example) box select without having to switch to a box select tool and without having to constantly press the shortcut B . It makes this basic functionality universally available across almost all active tools.

Thanks for the explanation. But you will in my experience win nothing. There can just be one default. Now instead of the hotkey for box select you have to press the hotkey for tweak permanently. Or you permanently adjust this setting since you need for example tweak with another tool. And you have permanently to think about it. This complicates the workflow and slows it down. When you press B then you know it’s now box select. And not, oh, i am in edit mode, here the default is still tweak, while it is box select in object mode.

It is imho a feature that may make sense to some Blender developers. But not to me as a user. As told, the feature never made sense to me. I have no use case for it. It slows me down.

But that’s of course my experience and opinion. Which you asked for. And i look forward to other opinions here

Custom keymaps are also a very different topic.

Well, with removing the feature from the UI and to put it into the default keymap you make it also unavailable for custom keymaps. So for those who relies at this feature this is a very important topic that belongs to this issue.

[LudvikKoutny]

Yes, make it a preference. This is not an isolated issue. This is just single manifestation of problem widespread in Blender. Way too many things which are user preferences are wrongly stored in the state of the file or a tool.

However, please don’t do nonsense like Alt Tool Access. There are already many hardcoded kemyap quirks made just to supplement poor design of Blender’s default keymap, and every additional one just harms third party keymaps.

[quote"]

RCS

• Is it acceptable to make the new “Right Mouse Selection Action” preference default in RCS
• If yes does it even make sense to remove that option from the preferences?
  [/quote]

Why don’t we remove RCS in general? Meaning not removing the ability for it to exist, but removing it from the keymap user preferences, and instead creating a legacy keymap preset that uses right click select?
So we would have following keymaps shipped with Blender:
Blender
Blender Right Click Select
Blender 2.7x
Industry Compatible

What this would help with is that the wonky changes to support legacy RCS would not affect the Blender as a whole, but just the RCS version of the keymap.

Since the LCS option was added to the splash screen few years ago, I suspect that only the very small minority of most jaded users are still using RCS. RCS should no longer be treated as first class citizen user preference, because it then causes big problems, that almost every new improvement to keymaps, and sometimes even tools, needs to have two variants, LCS one and RCS one.

Just imagine if you proposed this very same change but would not have to consider LCS and RCS variants because there would be only one. World would be so much better place.

I mean just look at this:

No newbie users will make sense out of this, and most of experienced users will just ignore it.

Right now, we have multiple bad keymap variants instead of just one good keymap variant.

[LudvikKoutny]

Actually, I have even better idea:

• Remove the drag fallback UI
• Do not introduce it as User Preference either
• Define select (B key default) to be the default drag action in the 3D View (Global) scope
• REMOVE the click drag key bindings in the individual tool keymaps:
  
  

So that by default, click drag will always select in the viewport. If the user wants click drag to do anything else than selection in any given tool, all they have to do is to assign a mouse tweak action on that in the given tool keymap. The selection will be always the default action regardless of the tool, and the user has a liberty of overriding what the action is, individually, for any tool they want.

Right now, we have an embarrassing situation where the default keymap comes with the tools already overriding what the 3D View (Global) click drag action does, and then we have additional UI element to switch that behavior independent of the keymap, because the overrides being set up by default were not a good idea.

This proposed solution has multiple benefits:

• Removes confusing UI element
• Doesn’t clutter User Preferences with new confusing UI elements
• Works with both LCS and RCS
• Allows user to precisely specify which tools should do which actions on drag, instead of giving them premade choices

[TheRedWaxPolice]

@JulienKaspar

Should the Drag UI element be removed from the tool settings?

Well, no?
I don’t like the default, so I always switch it to the “active tool” option aka “drag anywhere”… so that popup is useful to me…

@JulienKaspar

Should the “Active Tool” option become a preference instead?

If a preference can be made so the “active tool” option can be the default (without using hotkeys) then I’m okay with removing it… as I never touch the other options…

@JulienKaspar

Or is the “Alt Tool Access” preference perhaps enough to replace that option?

It isn’t…
I wouldn’t like to press a hotkey for something that I do all the time…

---

But in general, it’s always good to have options… people have different workflows…

[LudvikKoutny]

@TheRedWaxPolice

Well, no?
I don’t like the default, so I always switch it to the “active tool” option aka “drag anywhere”… so that popup is useful to me…

Do you just switch it once to active tool and keep it that way? Or do you keep switching between select and active tool often as you work?

[TheRedWaxPolice]

Just once… that’s why I’m okay if a preference is made to make the active tool option the default (without alt)… I rarely use the selection options…

[LudvikKoutny]

Then for exactly that reason, you should say “Yes” instead of “Well, no?”

You are just another example of the person who doesn’t really need it because they don’t use it. If what I proposed above was done, then you’d just add a single keymap binding to each tool where you want your drag to use the tool instead of selecting, and it would stay that way, forever. It would no longer happen you have to change it in every new blend file, or change it when you receive blender file from someone else. You would always have 100% certainty it will work exactly as you expect (drag activates the tool), without having to worry about state of some popover button somewhere

[TheRedWaxPolice]

@LudvikKoutny

Then for exactly that reason, you should say “Yes” instead of “Well, no?”

I said that cuz even though I’m okay to have the active tool option as a preference, I’m not quite sure if it’s the best thing to do… I mean, using the popup is not that bad… I see it like a regular tool setting…

[JulienKaspar]

Ok I’m taking this feedback so far:

• Managing what the drag fallback is set to per mode/workspace can be of a hassle
• All drag fallback actions could be clearer to use as a single set preference
• The preferences should be clearer communicated or perhaps even curated into separate keymaps

@LudvikKoutny Personally I find the Alt Tool Access option promising since it allows to both box select and use the active tool by clicking anywhere.
@TheRedWaxPolice I find it acceptable to hold a modifier key to do a very basic operation for the sake of efficiency. For navigation Shift & Ctrl is being held all the time. Alt is held all the time for the many users who use 3 mouse button emulation.
Once T89989 and T93599 are implemented I want to have that option tested more properly.

then you’d just add a single keymap binding to each tool where you want your drag to use the tool instead of selecting

@LudvikKoutny I don’t want to remove easy access to customizability for things that other users are clearly using. They mustn’t need to change individual keymap entries to get the behaviour they need, especially if it’s throughout all tools.
For example, this was the only way of getting an Active Tool Keymap before 3.0. Now it’s a single preference and it automaticly switches all shortcuts to active tools.

[LudvikKoutny]

@JulienKaspar

Personally I find the Alt Tool Access option promising since it allows to both box select and use the active tool by clicking anywhere.

As long as it doesn’t affect custom keymap, it’s not a big deal, but it’s still not a good solution, because it makes Alt+LMB unusable in given tools if it’s bound to something else, and using a hotkey for such essential operation is a bit odd.

@JulienKaspar

I don’t want to remove easy access to customizability for things that other users are clearly using. They mustn’t need to change individual keymap entries to get the behaviour they need, especially if it’s throughout all tools.
For example, this was the only way of getting an Active Tool Keymap before 3.0. Now it’s a single preference and it automaticly switches all shortcuts to active tools.

We have this odd panel hardcoded to just the default keymap because Blender’s keymap editor is bad. And we are now inventing even uglier chimeras instead of just making the keymap editor more intuitive to use. And the more of these chimeras are invented, the less incentive there is to actually fix the keymap editor properly in the future.

Let me put it this way. There are many other pieces of 3D software out there, where selection works across regardless of what tool you are in, and the users of those software packages don’t seem to ever be requesting an ability to have some switch between selection and other behavior. Why? Because it’s almost always addressed in a way that doesn’t make these two choices mutually exclusive.

For example, why shouldn’t you be able to LMB drag to select things and RMB drag to use active tool? Why does there have to be a choice between one or the other?

It’s constantly the same old song. Instead of addressing the issue of poor default keymap, we keep scattering additional UI elements across the UI, and cluttering the UI preferences with “hardcoded keymap fixes”:

It’s just infuriating constantly watching everyone coming up with different ways to put a bandaid on arterial bleeding. The more the panel above grows, the less there is incentive to actually fix core keymap issues. The panel was originally supposed to be just a temporary fix until core keymap editor issues are addressed, because right now, editing keymaps through it is a bomb defusal game for both new and experienced users.

• You are trying to fix an issue of useless UI panel which just adds confusion.
• The existence of this panel is a consequence of need for a choice between selection and tool interaction.
• This need for a choice arose from the false idea that there has to be a choice between one or the other. That both can’t be happening at the same time.
• This false idea exist because the current left click keymap is based on a legacy, right click keymap with its many flaws, which is gravely overdue for a complete overhaul.

You are now planning to add another layer of commitment to this legacy chain by introducing a new preference users will start to rely on.

I am proposing to make primary mouse button dragging in the 3D view editor be always selection, regardless of what tool you are in, and using some other button, for example RMB drag, which currently does nothing in vanilla keymap, to be tool interaction, regardless what tool you are in.

Then, users who are not happy with this behavior are always welcome to edit the keymap to fit their needs.

There doesn’t have to be any user setting to toggle between selection and tool interaction, because these two actions are not mutually exclusive in any keymap that’s actually good.

[JulienKaspar]

I am not proposing to add any options but instead I want to discuss how to simplify/eliminate the mentioned complex ones and unnecessary ones.

I agree that a better keymap editor would help a lot in creating custom keymaps but this is not the topic that I’m after and not the ultimate solution to the issue.

Also finding a one-size-fits-all solution is easier said than done. Using right click drag to use tools may sound like the perfect solution but won’t work for tools that can take pressure sensitivity into account. For pen devices it makes more sense to have actions mapped to left click. And for most people it makes sense to have both actions and selections set to left click.

And the solution to separating actions and selection across left & right click already exists. RCS is fulfilling exactly that purpose.
Even in LCS action & selection is not mutually exclusive. You can do both with drag thresholds & gizmos.

[LudvikKoutny]

@JulienKaspar

Also finding a one-size-fits-all solution is easier said than done. Using right click drag to use tools may sound like the perfect solution but won’t work for tools that can take pressure sensitivity into account. For pen devices it makes more sense to have actions mapped to left click. And for most people it makes sense to have both actions and selections set to left click.

There are different classes of tools. Some you want to use along with selection, such as move tool, while others you want to use directly, such as paint brush. Does it really make sense to consider pen pressure for move tool?

It would never even cross my mind that the paint brush strokes would be done with RMB.

You can’t really throw the kind of tool that Move tool is in the object mode and the kind of tool the Brush tool is in the paint mode into exact same bag. They are different modes after all.

@JulienKaspar

And the solution to separating actions and selection across left & right click already exists. RCS is fulfilling exactly that purpose.

It does it so poorly the reputation of whole Blender has historically suffered because of it.

It’s not just IF you address some problem, but also HOW you address it. If a patient visits a doctor, and ask him to stop a pain in their knee caused by a fracture, the doctor can either put his leg into a cast or shoot the patient dead. While both solutions technically solve the problem, one is clearly more desirable than the other.

Not only did not RCS address the whole issue of being able to select and interact at the same time, as B key was still required to perform most of the selection until the more recent and more sane versions of Blender, but even the minor part of the issue it addressed was addressed in such a way it caused way more harm than good.

@JulienKaspar

Even in LCS action & selection is not mutually exclusive. You can do both with drag thresholds & gizmos.

I am well aware. I am using a completely customized keymap that has almost nothing to do with vanilla one in production for a few years now, and I always get shocked by how bad the default one is any time I accidentally get in contact with it.

[Hadriscus]

For what it’s worth, I also usually set it once (to box select) then forget about it, so I’d be fine with it living in preferences (and be shared across tools would be fine too as far as I’m concerned).

[JulienKaspar]

Sorry this is going too off topic. I don’t want to further discuss here:

• if tools should be executed with right click (or any other radical revamp of keymaps)
• if RCS is any good
• creating better support for freely customizing the keymap

This isn’t what this thread is about.

[LudvikKoutny]

I know.

If you just remove the popover and don’t add any user preferences, then it’s fine, and I don’t have more to say.

If you decide to add equivalent of it into user preferences, then this indirectly reduces support for freely customizing the keymaps as it adds yet another precedent of the special treatment of the default keymap, compared to custom ones. And then when next similar decision comes in, the precedent will strengthen once more. That is why I considered it related to the topic.

[JulienKaspar]

I’ll take that into account. The preferences should’t become more complex as a result

[Hologram]

I generally don’t use the pop-over menu. I did customise the fallback tools to be the same as my selection tools (with all the modifiers and selection mode combinations) without even knowing what the fallback tools is about. And to me, after reading all of this, it is still unclear to me what purpose they serve and how they do so. Can you give a practical example of when the fallback tool is and when it isn’t used?

That said, I have one question on the implementation: does the button affect custom (imported) keymap by overriding the settings? If not, I presume there is no easy way to change the fallback settings other than manually changing the keymap entries.
if it does, when switched over from one setting to another in the preferences, it should do so consistently, meaning it should not irreversibly destroy the settings in the custom keymap when switching from A to B and back to A.

I am under the impression that the pop over menu is redundant and that this is best handled in the user preferences, But it needs to be properly and thoroughly documented.