Sometimes gizmos may be covering items underneath which the user intends to select:
It should be possible to click over a Gizmo to select items underneath it.
We can solve this by differentiating between a click and a drag, just like we do outside the gizmos.
To make this work well, we need to change the input, so that the drag threshold is more reasonable for mouse and trackpad input.
This requires us to add separate drag thresholds for Mouse, Pen and Keyboard.
| rB Blender | |||
| rB8778dd0c8b46 Gizmo: activate some gizmos on drag instead of press | |||
| rB13f292d10d3b Gizmo: only highlight when held modifier keys are used | |||
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Confirmed | DESIGN | None | T57917 Keymaps (Parent Task) | ||
| Archived | DESIGN | Brecht Van Lommel (brecht) | T56702 Blender 2.8: Left Click Select | ||
| Resolved | TO DO | Julian Eisel (Severin) | T57918 Tweaks & Fixes for Improved Left Click Select Support (Parent task) | ||
| Resolved | TO DO | None | T63996 Click over a Gizmo to select items underneath it |
Am yet far from having a full understanding on that issue, but from initial investigation it looks like this is the same kind of can of worms as T63994.
Basically, if I got things right, select is done on CLICK event, which will never be sent since the GIZMOGROUP_OT_gizmo_tweak operator is triggered on PRESS event. I quickly tried to re-add a CLICK event from that operator in 'cancel' cases, but that does not work, since that operators finishes immediately and passes over control to transform operator.
@Campbell Barton (campbellbarton) only idea I have here is that transform operator should detect when there is no transform (no drag) performed, and then return OPERATOR_CANCELLED instead of OPERATOR_FINISHED. That could be detected by the gizmo handling code, which could then add a fake 'RELEASE' and/or 'CLICK' events? Kind of a random idea, am still diving into the gizmo handling code…
@Bastien Montagne (mont29) I was thinking we could give gizmos control over the key bindings that activate them (on click / drag / key modifiers ... etc).
I didn't plan how this would work though, assume gizmos could have an event flag.
There is the down side that gizmos wouldn't activate immediately (since they would need to exceed the drag threshold).
If this is implemented, would it be possible to allow click-through a gizmo to hit the underlying geometry for selection, but at the same time ignore clicks on a gizmo that would hit the background and thus result in a deselect all? I think this might prevent some accidental deselects (accidental selects might be equally likely, but this would at least eliminate one of the two issues). If I really want to deselect by clicking on the background then I can move the mouse far enough away to make sure it happens and there's no ambiguity.
The issue would be reaching for the gizmo and mousing down and then changing your mind and releasing the mouse without moving it, which then turns into a click to select that you might not have intended. Over geometry there's really nothing you can do but perform the select since there's no way to know the user's intention, but when there's nothing behind the gizmo I think it would be reasonable to simply swallow the click without turning it into a click on the background/deselect.
This change can be made easily by changing the gizmos to use a Tweak event.
I've tested it, but this does make the gizmo less responsive to use. To me it became annoying if you only intend to do a very small movement.
I am unsure how to progress, or even if we should or not. It seems that, to support this well, element selection should take precedence, but if no element is underneath the gizmo, it should ideally remain as responsive as before. Might be too tricky and fiddly to sort out in the short term? Unless there are other solutions that I can't think of.
More thoughts:
It turns out that it is quite easy to solve the main issue, which is the ability to shift-click to select multiple items through the gizmos.
To do this, we just need to change the keymap slightly, so that it gizmos don't react to 'any' modifier keys. This works well for shift-clicking.
The tradeoff is that then we lose shift-clicking for doing two-axis constraining, which we already cover with the little squares.
Personally I think that's a good tradeoff for the default left click keymap. Right click and 2.79 keymap could continue working as before.
If it gonna be hardcoded It will be a huge problem for custom maps that are using press instead of click for LMB
or current select tool setup for LMB(it will detect selection before tweak action)
It would be perfect if there will be the ability to set hotkeys for gizmos the same way we can do it for all other things
so the user can decide what action he can start gizmo with if pressed on the gizmo, if he wants to activate it or another operator (like select)
Those aren't always available, if you have location/scale/rotation all enabled for eg.
Further, this prevents all future use of modifier keys with gizmos.
We can make it so only gizmos that request modifier keys take the events.
@Campbell Barton (campbellbarton) Yes, or the event could fall through the gizmo when the gizmo doesn't use it?
I am confused as to how detecting modifier key solves this? Modifier key is not always held when selecting an item which can be covered by a gizmo. Sometimes you just want to select a single vertex, which is being occluded by a gizmo. Not *add* it to the selection, just select it. That case would not be covered then since simple selection does not involve any modifier key. What happened to differentiation between click and click-drag? That's how for example 3ds Max solves it, and it works very well.
@Ludvik Koutny (rawalanche) Yes, that is one way to solve it, for LMB select.
One issue with that, is that the default drag threshold is actually just too high for using tweak events for gizmos. 10 pixels is actually a lot of movement before something starts to react, and it makes using gizmos feel sluggish.
We could simply lower the drag threshold to something more reasonable. I tried a value of 3px which seems to work ok.
This value also seems to work better for nodes and sequencer strips, both of which react a lot faster when dragging on them.
This was automatically closed, which wasn't intended by statement "Needed to resolve".
@William Reynish (billreynish) from talking in blender.chat it seemed like you weren't so confident about using drag for gizmos - which is the solution being proposed in this task.
@Campbell Barton (campbellbarton) Well as I said, with a drag threshold of 10 pixels, gizmos feel unreasonably slow and sluggish. My proposal would be to lower the drag threshold to 3 pixels instead.
The distance used to be 2, but was increased to 10 because of tablet users.
rBe815784aa684: Keymaps: make click event detection use a larger distance threshold.
We could try something in between (~4-6), but think a larger distance will get increasingly annoying/noticeable.
@Campbell Barton (campbellbarton) No, afaik that is for click event detection, not drag events. 10 pixels is way too high for drag events.
You mean in case there is already a selection and you want to override it by selecting a vertex behind the gizmo ? Does this happens really often ?
In this case we need to click an empty space or press "a" key to deselect everything then do the new selection. That's not a big deal because most of time you prefer to be sure to have nothing selected before doing a new selection.
Lowering the drag threshold can do the trick but it requires some test because having a sluggish gizmo is very annoying
Yes, it's not a big deal. Yet for some reason this particular thing was the reason Blender had absolutely ridiculous input mapping for over 20 years. So now that it's finally being addressed, let's address it properly.
One way to go about it could be to have hardcoded, lower click/drag distinction value just for that particular case of selecting vertices under a gizmo.
3ds Max gizmos never felt sluggish to me. I've just measured the drag distance, and in 3ds Max it's 3px. I also think that it's important to scale that by monitor DPI scaling, so that it doesn't mess pen tablets up. It works well at 100% dpi scaling, but it may be tricky at higher values.
In my personal keymap. I use click-drag with 3px radius also for viewport orbit navigation, so that I can use Alt+LMB drag to navigate viewport while still using Alt+LMB click to select edge loops. And I have to say, that 3px threshold is not noticeable at all when starting viewport navigation drag.
eaxcatly this breaks my custom keymap for select tool which was used as a tweak mode with the gizmos and now selection feel sluggish since i have to use click event instead of press :(
@William Reynish (billreynish)
i already tried, the issue is also in the default Left Click and ICK, u can't use select tool for tweaking as it selects underneath the gimzo's axes the moment u drag this was possible before and in 2.79....i think the select tool should be an exception for this as it's much faster to click drag once than 2x clicks....the select tool is now broken for Left Click Select.
and that includes the Industry compatible keymap here.
->
The Select tool should really be called the Tweak tool. It is meant for clicking and dragging to directly move items. There is a reason why it is separate from the Move tool.
What about using Right Clicking only on gizmos? Is this too stupid?
This doesn't force Right Click selection, though in a way it defeats the purpose of the Left Click Only.
Left Click select created a lot of problems only because of its ambiguity. You even had to start messing around with thresholds and dragging.
As the Right Click has become a pretty useless button in terms of user interaction, why not use it only for gizmos when the mouse is over any of them?
When the mouse is far, it could work as normal, showing the Context menu. Left Click could continue to be used for everything else in all of the interface as expected.
The Right Click on gizmos could be the only exception to the rule, and it would be for a good reason, allowing clicking and dragging without ambiguity, it could be even faster to use.
If the Left Click Only decision is solid as rock, why not give the user a new option to use the Right Click for gizmos as it is provided for Selection? Currently gizmos are always stuck to be used on Left Click only, no matter the button used to select.
Left/Right dilemma was always about selection, but never about gizmos.
In some other applications, selection is perform at mouse button release, except "ray-trace"/"Paint" selection.
You can set up mouse clicks and keyboard short cuts performing different actions for "at press" and "at release".
In the case of using Gizmo:
-Click and move will use the gizmo.
-Click without moving and release will select what is under.
You can solve some other inconsistency that way by introducing "at press" and "at release".
One other annoying thing is "box", "lasso" and "circle" select are using LMB... ??? I don't get it ??? I'm confused.
Last, even if you set RMB select in preferences, you can still move with RMB... ??? I don't get it ??? I'm confused ...again.
If we set RMB to select, it should not move what you have selected. Add another key "press/toggle combo" to allow "select and tweak" like, for example, the bevel tool where you use A, S, P…
As for consistency, we should have all these various parameters available using the press/toggle combo.
Just by adding to the "lasso select" an "Ignore Back Face” key toggle, it is one-step to unify ergonomics.