Input event activation problem in menu when using "RELEASE" options for hotkeys. Blender 2.7 to 2.8 #57856

New Issue

Brent Lio · 2018-11-15T21:09:29+01:00

Brent Lio commented

2018-11-15 21:09:29 +01:00

Windows 10 64bit
Ryzen 1700x
GTX 1080
32GB ram

Tested: 2.7x and 2.8
Worked: none

I have transform.resize mapped to "S" key on "RELEASE". If I go to the mesh special menu and press "S", the menu consumes the input and disappears. But, when I release the "S" key, blender goes into the transform-resize mode.

I think, when any menu is actively listening to input events, the input event accepted by the menu should be consumed in full. Instead of having a leftover of that event bleed into the next context.

Exact steps for others to reproduce the error
1: Edit the hotkey setup for "transform.resize" in edit mode to activate only when the "S" key is released.
2: Get a mesh object and go to edit mode.
3: Press "W" to open the mesh special menu. Then press "S" to subdivide the cube.
4: Inconsistently, Blender will go to transform.resize mode after "S" key is released.

Windows 10 64bit Ryzen 1700x GTX 1080 32GB ram Tested: 2.7x and 2.8 Worked: none I have transform.resize mapped to "S" key on "RELEASE". If I go to the mesh special menu and press "S", the menu consumes the input and disappears. But, when I release the "S" key, blender goes into the transform-resize mode. I think, when any menu is actively listening to input events, the input event accepted by the menu should be consumed in full. Instead of having a leftover of that event bleed into the next context. **Exact steps for others to reproduce the error** 1: Edit the hotkey setup for "transform.resize" in edit mode to activate only when the "S" key is released. 2: Get a mesh object and go to edit mode. 3: Press "W" to open the mesh special menu. Then press "S" to subdivide the cube. 4: Inconsistently, Blender will go to transform.resize mode after "S" key is released.

Brent Lio commented

2018-11-15 21:09:29 +01:00

Added subscriber: @remotecrab131

Brent Lio changed title from ~~Input event activation problem in menu when using "Released" options for hotkeys. All versions of blender.~~ to Input event activation problem in menu when using "Released" options for hotkeys. Blender 2.7 to 2.8

2018-11-15 21:09:56 +01:00

Brent Lio changed title from ~~Input event activation problem in menu when using "Released" options for hotkeys. Blender 2.7 to 2.8~~ to Input event activation problem in menu when using "RELEASE" options for hotkeys. Blender 2.7 to 2.8

2018-11-15 21:11:04 +01:00

Philipp Oeser commented

2018-11-16 09:54:48 +01:00

Added subscribers: @WilliamReynish, @brecht, @lichtwerk

Philipp Oeser commented

2018-11-16 09:54:48 +01:00

I can confirm described behaviour.

On my setup (default unaltered keymap) that will also happen if I keep holding "S" (dont have to RELEASE even):

subdivide takes place
menu closes
blender goes into transform-resize

Cant oversee all consequences of consuming all (future) events when closing a menu [if I understand correctly the RELEASE -- or still holding "S" in my case -- are future events] if that is desired, or how hard implementing that would be.
Maybe @brecht or @WilliamReynish can share a thought here...

To me that doesnt sound like a bug though (more of a feature request, if even...)

But leaving open to hear other opinions.

I can confirm described behaviour. On my setup (default unaltered keymap) that will also happen if I keep holding "S" (dont have to RELEASE even): - subdivide takes place - menu closes - blender goes into transform-resize Cant oversee all consequences of consuming all (future) events when closing a menu [if I understand correctly the RELEASE -- or still holding "S" in my case -- are future events] if that is desired, or how hard implementing that would be. Maybe @brecht or @WilliamReynish can share a thought here... To me that doesnt sound like a bug though (more of a feature request, if even...) But leaving open to hear other opinions.

YuanQing(Brent) Liu commented

2018-11-16 17:25:46 +01:00

Added subscriber: @BrentLiu

YuanQing(Brent) Liu commented

2018-11-16 17:53:27 +01:00

In #57856#554407, @lichtwerk wrote:

Cant oversee all consequences of consuming all (future) events when closing a menu [if I understand correctly the RELEASE -- or still holding "S" in my case -- are future events] if that is desired, or how hard implementing that would be.

I don't see this as a bug. It's more of a well hidden UI flaw. I can't think of any practical situation where a user would want to use a keypress to select an item in a menu and execute a function outside the menu context with the same key released.

A single key press always involves a "Press" event and a "Release" event. It's unavoidable. It is not a "future event". It's a "has to happen event" when a "Press" event is heard. A key will always have to be "Released" from a "Press" event.

Again, if this also happens when the hotkey isn't to execute on "Release", then this is very much an input bleed between "Menu" and "Editor Context". I think input should not bleed between a menu/pie menu and other contexts.

However, if someone can come up with one practical use case of this, I'd gladly listen.

This essentially drives fear into the act of changing hotkeys to "Release" state. <-- The
"execute on release" is otherwise extremely useful. I wouldn't mind demonstrating what they can do if anyone's curious.

> In #57856#554407, @lichtwerk wrote: > Cant oversee all consequences of consuming all (future) events when closing a menu [if I understand correctly the RELEASE -- or still holding "S" in my case -- are future events] if that is desired, or how hard implementing that would be. I don't see this as a bug. It's more of a well hidden UI flaw. I can't think of any practical situation where a user would want to use a keypress to select an item in a menu and execute a function outside the menu context with the same key released. A single key press always involves a "Press" event and a "Release" event. It's unavoidable. It is not a "future event". It's a "has to happen event" when a "Press" event is heard. A key will always have to be "Released" from a "Press" event. Again, if this also happens when the hotkey isn't to execute on "Release", then this is very much an input bleed between "Menu" and "Editor Context". I think input should not bleed between a menu/pie menu and other contexts. However, if someone can come up with one practical use case of this, I'd gladly listen. This essentially drives fear into the act of changing hotkeys to "Release" state. <-- The "execute on release" is otherwise extremely useful. I wouldn't mind demonstrating what they can do if anyone's curious.

William Reynish commented

2018-11-16 19:24:41 +01:00

With extreme customizability and flexibility, it's possible to create keymaps and interfaces that are completely broken. It's hard to prevent these kinds of issues. While I'm of course sympathetic to this, I'm not sure if this is technically a bug, or simply a keymap conflict that the user is able to create, and thus end up with a broken paradigm.

Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug.

With extreme customizability and flexibility, it's possible to create keymaps and interfaces that are completely broken. It's hard to prevent these kinds of issues. While I'm of course sympathetic to this, I'm not sure if this is technically a bug, or simply a keymap conflict that the user is able to create, and thus end up with a broken paradigm. Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug.

Brent Lio commented

2018-11-16 19:52:06 +01:00

Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug.

Whether it's a bug or a design flaw, I think it should not be left as is. I didn't know what type of report this should be, it feels like a flaw nonetheless, so I picked "bug".

If there are any suggestions on where to look in the source code, I'm tempted to try to change this so the inputs used to activate menu/pie menu items would execute on "Release", therefore maybe it won't bleed into the underlying context at all, or less often.

If that doesn't work, maybe there is a way to ignore the "Release" event in the menu after a "press" event.

> Not entirely sure how to handle these kinds of reports - I would tend to agree that this is actually a feature request, not a bug. Whether it's a bug or a design flaw, I think it should not be left as is. I didn't know what type of report this should be, it feels like a flaw nonetheless, so I picked "bug". If there are any suggestions on where to look in the source code, I'm tempted to try to change this so the inputs used to activate menu/pie menu items would execute on "Release", therefore maybe it won't bleed into the underlying context at all, or less often. If that doesn't work, maybe there is a way to ignore the "Release" event in the menu after a "press" event.

Brecht Van Lommel commented

2018-11-16 20:31:38 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-11-16 20:31:38 +01:00

Brecht Van Lommel self-assigned this 2018-11-16 20:31:38 +01:00

Brecht Van Lommel commented

2018-11-16 20:31:38 +01:00

There are thousands of these little things that could be improved. Realistically this is so low priority it's unlikely to ever be solved.

But mainly, this tracker is purely for bugs, and I don't consider this one.

There are thousands of these little things that could be improved. Realistically this is so low priority it's unlikely to ever be solved. But mainly, this tracker is purely for bugs, and I don't consider this one.

Brent Lio commented

2018-11-16 21:01:16 +01:00

In #57856#554622, @brecht wrote:
There are thousands of these little things that could be improved. Realistically this is so low priority it's unlikely to ever be solved.

But mainly, this tracker is purely for bugs, and I don't consider this one.

I believe this falls into the "Unintended design behavior" category. If no one cares, I'd like to research how to improve this. It would be greatly appreciated if there is anyone who's familiar with Blender's source code that deals with inputs and menus that could point me towards the related sections of the codes.

> In #57856#554622, @brecht wrote: > There are thousands of these little things that could be improved. Realistically this is so low priority it's unlikely to ever be solved. > > But mainly, this tracker is purely for bugs, and I don't consider this one. I believe this falls into the "Unintended design behavior" category. If no one cares, I'd like to research how to improve this. It would be greatly appreciated if there is anyone who's familiar with Blender's source code that deals with inputs and menus that could point me towards the related sections of the codes.

Brecht Van Lommel commented

2018-11-17 17:37:12 +01:00

I'd really recommended not to try to fix this, there may be no clean solution given Blender's event handling design, and trying to find a clever solution is likely to introduce bugs. There are many more important things to fix, like #56950 (UI Paper Cuts (Parent Task)).

Brent Lio commented

2018-11-17 19:51:40 +01:00

In #57856#554859, @brecht wrote:
I'd really recommended not to try to fix this, there may be no clean solution given Blender's event handling design, and trying to find a clever solution is likely to introduce bugs. There are many more important things to fix, like #56950 (UI Paper Cuts (Parent Task)).

Some of the papercuts like these ones:
#57685 (Add Save Before Closing to File -> New & File -> Open)
#57746 (Outliner: Dragging over disclosure triangles moves item rather than opening/closing)
are probably more important than the problem I suggested. Others, in my honest opinions, doesn't matter, that's why they are called "papercuts" anyway.

I worry more about bleeding wounds like inputs for selecting items in menus that bled onto the next context when menu closes.

Really, it's workflow interrupting, and it prevents users from utilizing the full potential of Blender's hotkey system, plus occasionally introduces some unintended behaviors. (from a user's perspective)

I have a few thoughts about how I can negate the problems without changing how input events are handled by Blender.

Based on my assumption, Blender's menus generates the hotkeys for selecting menu items automatically. If I could experiment with how these are generated, I could find a way to solve the issue. In the worst case scenario, I can at least add an option in user-preferences to turn off "auto-generate-hotkey" for menus, or change menu options to activate only on hotkey "Release" and block off all inputs to other contexts when a menu is open. This way, when the menu closes, user input for the menu has already ended, whatever happens after should match the user's intention.

If I can get this issue fixed, I'd gladly help to fix all the papercuts for the masses.

> In #57856#554859, @brecht wrote: > I'd really recommended not to try to fix this, there may be no clean solution given Blender's event handling design, and trying to find a clever solution is likely to introduce bugs. There are many more important things to fix, like #56950 (UI Paper Cuts (Parent Task)). Some of the papercuts like these ones: #57685 (Add Save Before Closing to File -> New & File -> Open) #57746 (Outliner: Dragging over disclosure triangles moves item rather than opening/closing) are probably more important than the problem I suggested. Others, in my honest opinions, doesn't matter, that's why they are called "papercuts" anyway. I worry more about bleeding wounds like inputs for selecting items in menus that bled onto the next context when menu closes. Really, it's workflow interrupting, and it prevents users from utilizing the full potential of Blender's hotkey system, plus occasionally introduces some unintended behaviors. (from a user's perspective) I have a few thoughts about how I can negate the problems without changing how input events are handled by Blender. # Based on my assumption, Blender's menus generates the hotkeys for selecting menu items automatically. If I could experiment with how these are generated, I could find a way to solve the issue. In the worst case scenario, I can at least add an option in user-preferences to turn off "auto-generate-hotkey" for menus, or change menu options to activate only on hotkey "Release" and block off all inputs to other contexts when a menu is open. This way, when the menu closes, user input for the menu has already ended, whatever happens after should match the user's intention. # Blender's operators do have a 'bl_option' called {"BLOCKING"}, it blocks all non-modal input. This mechanism may be used for Menu Types to solve input bleeding. Though, I'll have to experiment more with this, since I don't know whether it is possible to leave the "auto-generated-hotkey" alone while blocking all other inputs. If I can get this issue fixed, I'd gladly help to fix all the papercuts for the masses.

Brecht Van Lommel commented

2018-11-18 01:16:11 +01:00

The thing is binding an operators to release is basically never what you want. We only need the release event in some modal keymaps. It is more a UI issue in key configuration than anything else.

Solution 1) is not acceptable, we do not want to make menu interaction slower than it needs to be. And menus are not like modal operators, so 2) will not work.

The thing is binding an operators to release is basically never what you want. We only need the release event in some modal keymaps. It is more a UI issue in key configuration than anything else. Solution 1) is not acceptable, we do not want to make menu interaction slower than it needs to be. And menus are not like modal operators, so 2) will not work.

Brent Lio commented

2018-11-18 19:20:13 +01:00

I just realized one possible problem of executing items on release. If a pie menu is executed by pressing S, and an option in it responds to S on release, then I move my mouse on a different option that's activated by a different hotkey, now releasing "S" key will have 2 possible outcomes, they might be fighting for priority. Or, even if I don't want to select any options, it would execute the option that's tagged with "S".

Combined with what you said, I think my methodology in configuring hotkeys is actually flawed. It is for the best to avoid mapping operations to execute on release unless it is absolutely necessary or it's part of the design.

Thank you for responding to my ideas and suggestions, if it weren't for the discussion I may have never realized the flaws in my methodology.

I just realized one possible problem of executing items on release. If a pie menu is executed by pressing S, and an option in it responds to S on release, then I move my mouse on a different option that's activated by a different hotkey, now releasing "S" key will have 2 possible outcomes, they might be fighting for priority. Or, even if I don't want to select any options, it would execute the option that's tagged with "S". Combined with what you said, I think my methodology in configuring hotkeys is actually flawed. It is for the best to avoid mapping operations to execute on release unless it is absolutely necessary or it's part of the design. Thank you for responding to my ideas and suggestions, if it weren't for the discussion I may have never realized the flaws in my methodology.

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

Input event activation problem in menu when using "RELEASE" options for hotkeys. Blender 2.7 to 2.8 #57856