Click over a Gizmo to select items underneath it #63996

New Issue

William Reynish · 2019-04-29T20:21:06+02:00

William Reynish commented

2019-04-29 20:21:06 +02:00

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.

Sometimes gizmos may be covering items underneath which the user intends to select: ![Screenshot 2019-04-29 at 20.19.41.png](https://archive.blender.org/developer/F6992565/Screenshot_2019-04-29_at_20.19.41.png) 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.

Bastien Montagne was assigned by William Reynish

2019-04-29 20:21:06 +02:00

William Reynish commented

2019-04-29 20:21:06 +02:00

Added subscriber: @WilliamReynish

Bastien Montagne commented

2019-05-01 18:07:20 +02:00

Added subscriber: @ideasman42

Bastien Montagne commented

2019-05-01 18:07:20 +02:00

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 #63994.

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.

@ideasman42 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…

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 #63994. 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. @ideasman42 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…

Adrian Rutkowski commented

2019-05-07 14:17:53 +02:00

Added subscriber: @niewinny

Campbell Barton commented

2019-05-08 07:44:24 +02:00

@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).

@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).

Gavin Scott commented

2019-05-14 02:54:01 +02:00

Added subscriber: @GavinScott

Gavin Scott commented

2019-05-14 02:54:01 +02:00

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.

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.

William Reynish commented

2019-05-14 14:46:23 +02:00

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.

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.

William Reynish commented

2019-05-14 16:39:46 +02:00

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.

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.

Adrian Rutkowski commented

2019-05-14 17:11:45 +02:00

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)

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)

William Reynish commented

2019-05-14 22:20:02 +02:00

@niewinny It's not hardcoded, it's in the keymap.

Campbell Barton commented

2019-05-15 08:48:34 +02:00

In #63996#678916, @WilliamReynish wrote:
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.

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.

> In #63996#678916, @WilliamReynish wrote: > 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. 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.

William Reynish commented

2019-05-15 08:52:23 +02:00

@ideasman42 Yes, or the event could fall through the gizmo when the gizmo doesn't use it?

Bastien Montagne removed their assignment 2019-05-20 14:30:42 +02:00

Bastien Montagne commented

2019-05-20 14:30:42 +02:00

Added subscriber: @mont29

blender-admin commented

2019-05-28 06:33:13 +02:00

This issue was referenced by 13f292d10d

This issue was referenced by 13f292d10d3bb19aa9aa694cecbde499f93e7a54

Campbell Barton commented

2019-05-28 06:46:32 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-05-28 06:46:32 +02:00

Ludvik Koutny commented

2019-05-28 20:49:20 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-05-28 20:49:20 +02:00

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.

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.

William Reynish commented

2019-05-29 01:11:52 +02:00

@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.

@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.

Campbell Barton commented

2019-05-29 03:54:40 +02:00

Changed status from 'Resolved' to: 'Open'

Campbell Barton reopened this issue

2019-05-29 03:54:40 +02:00

Campbell Barton commented

2019-05-29 03:54:40 +02:00

This was automatically closed, which wasn't intended by statement "Needed to resolve".

Campbell Barton commented

2019-05-29 05:33:45 +02:00

@WilliamReynish 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.

William Reynish commented

2019-05-29 08:05:37 +02:00

@ideasman42 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.

Campbell Barton commented

2019-05-29 09:05:38 +02:00

The distance used to be 2, but was increased to 10 because of tablet users.

e815784aa6

We could try something in between (~4-6), but think a larger distance will get increasingly annoying/noticeable.

The distance used to be 2, but was increased to 10 because of tablet users. e815784aa6 We could try something in between (~4-6), but think a larger distance will get increasingly annoying/noticeable.

William Reynish commented

2019-05-29 09:08:36 +02:00

@ideasman42 No, afaik that is for click event detection, not drag events. 10 pixels is way too high for drag events.

Campbell Barton commented

2019-05-29 09:13:21 +02:00

Currently click/drag detection uses the same threshold.

Christophe commented

2019-05-29 11:22:59 +02:00

Added subscriber: @StroBlend

Christophe commented

2019-05-29 11:22:59 +02:00

In #63996#689879, @Rawalanche wrote:
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.

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

> In #63996#689879, @Rawalanche wrote: > 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. 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

Ludvik Koutny commented

2019-05-29 11:48:33 +02:00

In #63996#690518, @StroBlend wrote:

In #63996#689879, @Rawalanche wrote:
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.

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.

> In #63996#690518, @StroBlend wrote: > > > >> In #63996#689879, @Rawalanche wrote: >> 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. > > 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.

blender-admin commented

2019-05-30 07:20:20 +02:00

This issue was referenced by 8778dd0c8b

This issue was referenced by 8778dd0c8b461780fdf9de688047d1a9c24dd641

Campbell Barton commented

2019-05-30 07:30:05 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-05-30 07:30:05 +02:00

Zino Guerr commented

2019-05-30 21:43:36 +02:00

Added subscriber: @Znio.G

Zino Guerr commented

2019-05-30 21:43:36 +02:00

In #63996#678939, @niewinny wrote:
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)

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 :(

> In #63996#678939, @niewinny wrote: > 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) 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 commented

2019-05-30 23:21:39 +02:00

@Znio.G you can customize this in the keymap

Zino Guerr commented

2019-05-31 00:03:42 +02:00

@WilliamReynish
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.

@WilliamReynish 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. - > ![select.gif](https://archive.blender.org/developer/F7080379/select.gif)

William Reynish commented

2019-05-31 08:20:06 +02:00

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.

chaos commented

2019-08-23 09:53:02 +02:00

Added subscriber: @chaos-4

chaos commented

2019-08-23 09:53:02 +02:00

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.

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.

Uendel Quintela commented

2019-09-05 22:01:25 +02:00

Added subscriber: @Uendel

Jean-Philippe Savariault commented

2019-09-25 17:50:21 +02:00

Added subscriber: @JPSavariault

Jean-Philippe Savariault commented

2019-09-25 17:50:21 +02:00

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.

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.

Uendel Quintela commented

2019-10-09 19:44:37 +02:00

Removed subscriber: @Uendel

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

Click over a Gizmo to select items underneath it #63996