Page MenuHome

Key modifier(custom hotkey) does not trigger on a proper priority level.
Closed, ArchivedPublic

Description

System Information
Windows 7 64bit OS & AMD HD6770

Blender Version
Broken: (2.74 and previous versions)
Worked: (not sure, I just started using Blender since 2.63.)

Short description of error
When I bound "S key"+"right mouse" as view3d.zoom operator hotkey (It's Softimage style viewport navigation), the S key(as a keymodifier) does not take same priority as Ctrl, Shift and Alt key have. The problem is, for example, I wrote a custom python operator as a new selection method and bound "right mouse" as its hotkey, then, I attempted to zoom the 3d view by press "S + right mouse", Blender firstly only triggered the custom selection operator I wrote but couldn't zoom the 3d view as I supposed to. Whereas, when I bound "Alt + right mouse" as zoom 3d view hotkey, it worked properly. Maybe few people use Softimage style viewport navigation layout in Blender, so this problem was not so noticeable. I really hope you can fix it, and thanks for keeping Blender awesome :)
.
Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Details

Type
Bug

Event Timeline

Eva (sweep2rails) raised the priority of this task from to Needs Triage by Developer.
Eva (sweep2rails) updated the task description. (Show Details)
Eva (sweep2rails) added a project: BF Blender.
Eva (sweep2rails) set Type to Bug.
Julian Eisel (Severin) lowered the priority of this task from Needs Triage by Developer to Needs Information from User.Apr 13 2015, 10:08 PM

Did you assign the S-key using this field? :

Did you assign the S-key using this field? :

Yes,I exactly assign the S-key using this field. And it works perfectly in most circumstances, even Blender's native select operator written by C-language works properly with this key. Only python Operators will take higher priority over this key. So it doesn't make good sense, it's supposed to be a bug.

So you have an py-written operator and you want it to be called on RMB and you want the zoom operator to be triggered on S+RMB, right? Would be useful to see your script then, at least a simplified version of it, so I can test on my own

Eva (sweep2rails) added a comment.EditedApr 23 2015, 11:55 AM

So you have an py-written operator and you want it to be called on RMB and you want the zoom operator to be triggered on S+RMB, right? Would be useful to see your script then, at least a simplified version of it, so I can test on my own

Actually, it doesn't depend on what script written in Operator. It's like that ANY python operator causes the problem, even a blender native python Operator causes this problem, for example, like "Select All Toggle" operator(A key by default), you can still press A to toggle select all objects while S (S had already been set as a key modifier as I said previously) is being held. Whereas, while you're holding Alt or Shift or Ctrl, you're not able to toggle select any more, it's working properly. The key modifier should've been working that way as Alt, Shift or Ctrl do.

It seems that Blender haven't offered an event which can test if a key modifier is held, there are only event.alt, event.shift, event.ctrl in python APIs. Recently, I dug into python coding in blender a little bit, and found a way to test if S is held during the whole runtime of blender. This can be used for avoiding that operators conflict issue. But it's still a workaround, as dev team, you should implement it in some more proper way. I wrote a "testing if SKey is held" python script sample, it's based on a python template in blender.
.blend file here:


You can play with it, simply run the script in the text editor, then press S key a few times in 3d view, you'll see the difference. Hope it's helpful for you team to a proper solution soon.

Bastien Montagne (mont29) raised the priority of this task from Needs Information from User to Normal.May 1 2015, 9:55 AM
Sergey Sharybin (sergey) closed this task as Archived.May 25 2015, 9:08 PM
Sergey Sharybin (sergey) claimed this task.

To me it seems to be just a famous keymapping conflict, where pressing S (press == hold the key down) triggers transform operator and surely prevents S-RMB from invoking.

You can work around this locally by re-assigning scale to click event. It's not ideal but should work for you.

Re-considering the shortcuts is in our list for improvements and will happen outside of the bug tracker. So thanks for the report, but archiving it now.

To me it seems to be just a famous keymapping conflict, where pressing S (press == hold the key down) triggers transform operator and surely prevents S-RMB from invoking.
You can work around this locally by re-assigning scale to click event. It's not ideal but should work for you.
Re-considering the shortcuts is in our list for improvements and will happen outside of the bug tracker. So thanks for the report, but archiving it now.

Thank you, but I'd already been not using S-key for scaling since the day I started to use blender. Instead, I always use X-key for all scaling operation types.

Why is this bug closed? Key modifiers still work inconsistently in Blender 2.8. It's not a key conflict issue in the traditional sense. If *any* key is assigned to even one of the keys that the custom modifier is supposed to be *modifying* it won't work. For instance. if "numpad 0" is your modifier key and you have "numpad 0" + "a" assigned to a default pie menu. the default pie menu will run, but additionally the singular "a" command will run selecting everything in the scene. Thus it's not acting like a proper modifier at all.

Annoying that this task was closed without awaiting for a response from the bug reporter.