Ctrl-mousewheel over the mode-button (object interaction mode) does nothing #80659

New Issue

user1 · 2020-09-10T12:10:15+02:00

user1 commented

2020-09-10 12:10:15 +02:00

System Information
Operating system: Linux-5.4.0-47-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GT 630/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.138

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-09 20:10, hash: 0721fbb6e1

Short description of error
Ctrl-mousewheel over the mode-button (object interaction mode) does nothing

Exact steps for others to reproduce the error
Open blender
Hover over the knob that sais "Object mode" in the upper left corner of 3D-view

Hold [ctrl] and roll the mousewheel
Nothing happens

**System Information** Operating system: Linux-5.4.0-47-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GT 630/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.138 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-09 20:10, hash: `0721fbb6e1` **Short description of error** Ctrl-mousewheel over the mode-button (object interaction mode) does nothing **Exact steps for others to reproduce the error** Open blender Hover over the knob that sais "Object mode" in the upper left corner of 3D-view ![Bildschirmfoto zu 2020-09-10 12-08-35.png](https://archive.blender.org/developer/F8861184/Bildschirmfoto_zu_2020-09-10_12-08-35.png) Hold [ctrl] and roll the mousewheel Nothing happens

user1 commented

2020-09-10 12:10:15 +02:00

Added subscriber: @user1

Philipp Oeser commented

2020-09-11 17:49:48 +02:00

Added subscribers: @HooglyBoogly, @JulianEisel, @lichtwerk

Philipp Oeser commented

2020-09-11 17:49:48 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2020-09-11 17:49:48 +02:00

Can confirm the behavor, dont think this is a bug though.

This is a bit of a special button (operator_menu_enum -- calls operators with different properties, not even sure if we would want to support {key CTRL scrolling} on those?)
But in a Debug build it asserts in ui_but_range_set_soft after 298d5eb669 -- this should not happen (though it is harmless).
Easiest way to prevent that is
P1627: T80659_snippet



diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c
index 6a6914daf47..3eca722ec15 100644
--- a/source/blender/editors/interface/interface_handlers.c
+++ b/source/blender/editors/interface/interface_handlers.c
@@ -8893,8 +8893,10 @@ static int ui_handle_button_event(bContext *C, const wmEvent *event, uiBut *but)
     if (post_but) {
       /* The post_but still has previous ranges (without the changes in active button considered),
        * needs refreshing the ranges. */
-      ui_but_range_set_soft(post_but);
-      ui_but_range_set_hard(post_but);
+      if ((but->rnaprop) || (but->poin && (but->pointype & UI_BUT_POIN_TYPES))) {
+        ui_but_range_set_soft(post_but);
+        ui_but_range_set_hard(post_but);
+      }
 
       button_activate_init(C, region, post_but, post_type);
     }

(but the correct way would be to make sure this button does not have postbut in the first place)

Anyways, getting offtopic here, will ask for a decision of whether or not this is to be supported on these kind of special buttons: @JulianEisel, @HooglyBoogly
(to me, this sounds like a limitation - probably a sane limitation even - and not a bug, but will let module owners decide).

Can confirm the behavor, dont think this is a bug though. This is a bit of a special button (`operator_menu_enum` -- calls operators with different properties, not even sure if we would want to support {key CTRL scrolling} on those?) But in a Debug build it asserts in `ui_but_range_set_soft` after 298d5eb669 -- this should not happen (though it is harmless). Easiest way to prevent that is [P1627: T80659_snippet](https://archive.blender.org/developer/P1627.txt) ``` diff --git a/source/blender/editors/interface/interface_handlers.c b/source/blender/editors/interface/interface_handlers.c index 6a6914daf47..3eca722ec15 100644 --- a/source/blender/editors/interface/interface_handlers.c +++ b/source/blender/editors/interface/interface_handlers.c @@ -8893,8 +8893,10 @@ static int ui_handle_button_event(bContext *C, const wmEvent *event, uiBut *but) if (post_but) { /* The post_but still has previous ranges (without the changes in active button considered), * needs refreshing the ranges. */ - ui_but_range_set_soft(post_but); - ui_but_range_set_hard(post_but); + if ((but->rnaprop) || (but->poin && (but->pointype & UI_BUT_POIN_TYPES))) { + ui_but_range_set_soft(post_but); + ui_but_range_set_hard(post_but); + } button_activate_init(C, region, post_but, post_type); } ``` (but the correct way would be to make sure this button does not have `postbut` in the first place) Anyways, getting offtopic here, will ask for a decision of whether or not this is to be supported on these kind of special buttons: @JulianEisel, @HooglyBoogly (to me, this sounds like a limitation - probably a sane limitation even - and not a bug, but will let module owners decide).

Hans Goudey commented

2020-09-11 23:31:39 +02:00

Right, as far as I know these operator enum buttons don't know about which item in their enum is active anyway, so ctrl scrolling isn't expected to work here.

That fix for the assert seems fine, might want to still check with Julian about it though.

Right, as far as I know these operator enum buttons don't know about which item in their enum is active anyway, so ctrl scrolling isn't expected to work here. That fix for the assert seems fine, might want to still check with Julian about it though.

Julian Eisel commented

2020-09-21 13:23:13 +02:00

Changed status from 'Confirmed' to: 'Archived'

Julian Eisel closed this issue

2020-09-21 13:23:13 +02:00

Julian Eisel self-assigned this 2020-09-21 13:23:13 +02:00

Julian Eisel commented

2020-09-21 13:23:13 +02:00

For a button that doesn't support cycling, execution shouldn't even reach this point. So committed a different fix for this assert, 92454ae100.
But I also found the assert to be pretty weirdly placed, and decided to remove it 88a9d82bbb.

I also find it odd that we explicitly have to set the ranges here, that seems like a lower level function than what should be called here. I'd expect ui_but_update()/ui_but_update_edited() to be called here (not sure which exactly). It already sets the soft range, and should probably also ensure the correct hard range.

Anyway, for the report itself - like others have said, this is not really a bug. The object mode is a rather special case, Ctrl+Mousewheel isn't supported here and probably shouldn't be for now (changing modes can be a heavy operation, but it may also be destructive, e.g. for the undo steps). Ctrl+Mousewheel is a convenience/efficiency feature, but we can't deliver on that currently.

For a button that doesn't support cycling, execution shouldn't even reach this point. So committed a different fix for this assert, 92454ae100. But I also found the assert to be pretty weirdly placed, and decided to remove it 88a9d82bbb. I also find it odd that we explicitly have to set the ranges here, that seems like a lower level function than what should be called here. I'd expect `ui_but_update()`/`ui_but_update_edited()` to be called here (not sure which exactly). It already sets the soft range, and should probably also ensure the correct hard range. ---- Anyway, for the report itself - like others have said, this is not really a bug. The object mode is a rather special case, Ctrl+Mousewheel isn't supported here and probably shouldn't be for now (changing modes can be a heavy operation, but it may also be destructive, e.g. for the undo steps). Ctrl+Mousewheel is a convenience/efficiency feature, but we can't deliver on that currently.

Philipp Oeser commented

2020-09-21 14:00:13 +02:00

I also find it odd that we explicitly have to set the ranges here

was the fix for #78763 (could have possibly been done in another way, was the most limited in scope I thought at that time)

> I also find it odd that we explicitly have to set the ranges here was the fix for #78763 (could have possibly been done in another way, was the most limited in scope I thought at that time)

Julian Eisel commented

2020-09-22 18:48:02 +02:00

@lichtwerk could you play with my suggestion above to see if it works as an alternative fix? Not super important but would be nice to keep code here as clean as possible (it's already confusing as hell).

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

Ctrl-mousewheel over the mode-button (object interaction mode) does nothing #80659