Keyboard tap/drag detection useful?

Archive User Feedback
1

During the code quest we tested out having two actions for the Tab key: Tap for edit-mode, Drag for pie-menu.

This is no longer used which raises the question of whether we should keep support for it.

While it was handy in some ways, ultimately we found this to be a poor default because users generally expect keyboard actions to happen when pressing a key.

On the other hand once you know to expect this behavior it’s not such an issue, and it allows any key to have two actions.

Examples could be:

  • Tap Z to toggle wire-frame, hold for render menu.
  • Tap T for toolbar, hold for tool popup (so it can be kept hidden).
  • Tap Q for favorites menu, hold for pie menu that toggles gizmos (move/rotate/scale).
    … not hard to think of others.

We’re considering removing this ability, because it’s not used by the default keymap (and this code is already fairly complicated).

Has anyone tried using this in their own keymap and found it handy?

I’d like to know if users who configure their keymaps think this would be useful to keep or not.

Edit, to try this out:

  • Change quick menu (Qkey) (Window -> Call Menu) from Press to Click.
  • Change navigate (3D View -> View Navigation) from Press to Click-Drag, set the key to Q.

Now in the 3D view, Q-drag begins walk-mode, tapping opens the menu as before.

2 Likes
2

Someone posted a request for this on RightClickSelect.

I’d offer my opinion, but I never knew it was possible?!

What would I set the key to? Click-Drag?

And what’s the delay from press to activation?

I think it could be nice to press C for the Knife tool, then hold C for Loop Slice.

3

@zimlorog long-press is a bit of a different feature.
The nice thing about dragging is you don’t need to wait for it as you do with long-press.
The down side is you can accidentally drag.

Added brief instructions to the OP on how to try this out.

4

Huh. Huh. I see. I need to rethink a lot of things about my keymap, because this could easily replace a lot of modifier key use. Especially for calling pie menus.

I think this needs to be presented to the community in a wider venue like Blender Today, because I’d be super curious to see how many other people knew about it as well.

Edit: I know a lot of people just want a keymap that works (industry, minimal, etc), and to that point this feature is probably useless. However, I strongly believe the community should be motivated to get comfortable with editing the keymap themselves. Part of that I think is better messaging of features like the one presented here.

If it has to go because it’s complicated code, then fine, I lived without it before. But I’m starting to think of how useful it might be to tablet users, or users who don’t have a num pad on their keyboard.

(while I have your attention, please let me edit the modal map for Loop Slice, and Bevel. Please please please)

5

Yes, it co-exists fairly well with the pie menu because you typically drag it once activated.

We’ll see how much feedback happens here.

By default - yes, as a keymap preference it can work.

Hopefully in the future editing keymaps can be made to work better, with current 2.8x - it’s a hassle to use the UI.

Only if it’s not useful to keep.

Would be good if some users could try it out and report back if it’s useful in practice or not.

1 Like
6

Maybe default keymap should ship with some examples? Hardly known things are not going to get much testing and generate feedback. @zimlorog is right about getting community attention.

Tab is a good candidate too, I am testing it with Tab Click (changed from Press) and Tab Click Drag (added this one), making Ctrl Tab Press redundant (only difference is that it shows the menu before motion). I can see other things going this way, Click for most common, Click Drag for menu or less common.

1 Like
7

I’m currently giving this a spin:

C = Knife
C + Drag = Loop Slice
Shift + C = Offset Loop
Shift + C + Drag = Subdivide

It’s not bad. I do have to be a little careful because it is easy to drag enough to activate Subdivide, but so far so good.

It also appears that you can just keep holding the keys down and dragging and it will continue to activate the command. So watch out for that too.

8

Safest seems to limit drags to trigger menus or anything else that can be cancelled.

9

Try increasing the ‘tweak threshold’ in the preferences to see if that helps.

1 Like
10

This seems extremely useful! However, most people do not know about it. I didn’t know about it. It is a big and time consuming task to customize a key-map well and not a lot of users find the time to experiment with it a lot. I wish I could spend more time making Blender more convenient for myself but the fact is I do not have time to search for the most optimal way to use hotkeys so only very few essential customizations and things that I believe make a huge difference make it into my own customization. It is a lot easier for me to learn a hotkey than to think of it, create it and then learn it. I think this might be true for other people as well.

A huge amount of useful hotkeys are being removed in 2.80. I think that is in attempt to make it lighter, less obscure and leave more empty keys for easier customization, and I don’t know - this might be good for some people, but this is definitely not what all people need. I, for example, need a good keymap that would have most functions accessible instantly. This functionality of keyboard tap/drag detection here may be amazing for such a thing. But it does not exist for me now. It is not used in any keymaps as far as I know. I am really extremely excited to try it and I most definitely will, but at this time I am writing this, I just don’t have the time for it. I think it’s an amazing feature, but more examples and suggestions of use cases should come with it. What if there were 2 standard keymaps that come with Blender: the current 2.80 one and a FULL one ridiculously overcrowded with stuff that would use features like this and absolutely everything and anything that makes it possible to stuff all the possible functionality to it. I would use the full one no matter how obscure it might be and no matter how hard it would be to learn because I value speed and efficiency more than ease of learning. And the big full keymap preset should definitely not be called 2.7X that implies it may not be tuned to new 2.80 features, by the way. It would be so cool to see this happen. I wish I could do this myself…

1 Like
11

i tried the tab for edit/pie menu in pre-alpha version, despite changing the threshold/radius…etc to make it work smoothly but i found it, prone to error…u have to be extra aware & bit annoying. because you don’t want to overthink when switiching modes…just my 2 cents.

12

I haven’t tried it, but I think I would love it!

13

Since there is quite some positive feedback here, I’ve committed a keymap preference to optionally use this feature (link).

In the keymap preferences enable “Pie Menu on Drag”

  • Z: tap toggles wireframe.
  • Tilde: tap navigates (walk/fly mode).

Note that this only impacts pie menus that use a secondary tap action, not all of them.

More could be added but I’d like to get user feedback on this before making more extensive keymap changes.

1 Like
14

I recommended these setting like default in paper cut thread. Me and other friends have configured blender in this way by default weeks ago.

It is not only for things like wireframe and pie menus. You can use for tools

X delete faces ( or context sense)
X drag, menu

Alt+M merge last
Alt+M drag merge menu

V drag, vertex menu
F drag, face menu
E drag, edge menu

S scale
S drag scale menu to select pivot

Other ideas

In sculpt
Q settings widget (it doesnt exist)
Q drag, brushes menu selector popover

F size selector
F drag brush size menu

Other ideas

E unwrap
E drag unwrap menu

Hotkey basic menu
Hotkeydrag, advanced menu

O switch between proportional modes
O drag, proportional curve selection

Space search
Space drag, toolbar

…

The possibilties in a default keymap are amazing. And other programs like maya allow this behaviour in default keymap, for example in space key.

It allow to duplicate the number of hotkeys near to left hand.

Dont delete this,because was one of the best things of 2.8

5 Likes
15

I also use this new feature, which I discovered through the new extra options in the Keymap Preferences menu. Thanks for this, I love it! :heart:

So much so that I’ve been toying with a small script to automatically change most default keys (3d View mostly) from PRESS to a full CLICK. This effectively allows you to double up the function per key (when you also define a CLICK-DRAG entry), as it is not immediately captured by a PRESS event. It’s very useful for menu calling and keeping your keymap combos minimal and memorable.

Personally, I think some specific keys should be click by default. Take move (G) for example: in edit mode, if you press G and hold (i.e. invokes keyboard repeat), the mesh does a funky dance between move and slide, as slide is also a G press in move’s modal mode. If it were click, you would avoid this, and it would also leave G free to be easily click-drag defined to have, say, a related move-pie-menu call.

Click by default would also let addon authors easily define click-drag keymap items without going through the hoops of having the user redefine their existing keys from press to click, since default & user keyconfigs are unavailable to edit by script at Blender’s initial startup time. I know this has been a problem for many people, including myself. (e.g. How to modify the default keymap at Add-on registration time?)

Anyhow, I hope this feature stays, and more people get to discover it and use it. :+1:

2 Likes
16

Could you share that script?

17

Sure, but it’s still very rudimentary. Here it is heavily commented: https://pastebin.com/zjBcjYZT

# SCRIPT TO CHANGE KEYBOARD PRESSES TO FULL CLICKS (PRESS + RELEASE)

import bpy

wm = bpy.context.window_manager
kc = wm.keyconfigs.user  # one of {active, addon, default, user}
#km = kc.keymaps['3D View'].keymap_items
kms = kc.keymaps

change_regions = []
change_spaces = ['EMPTY', 'VIEW_3D', 'IMAGE_EDITOR', 'NODE_EDITOR', 'SEQUENCE_EDITOR', 'CLIP_EDITOR',
                'DOPESHEET_EDITOR', 'GRAPH_EDITOR', 'NLA_EDITOR', 'TOPBAR', 'OUTLINER', 'PROPERTIES', ]
skip_key_types = ['TAB', 'ESC', 'RET', 'DEL', 'LINE_FEED', 'BACK_SPACE']  # F1-F12 ?
skip_key_idnames = ['wm.call_menu_pie']

changed_keys = []

# TODO:
# Write function to change any CLICK back to PRESS

# Check which are click by default = None.
# for km in kms:
#     for kmi in km.keymap_items:
#         if kmi.map_type == 'KEYBOARD' and kmi.value == 'CLICK':
#             print(kmi)  # 0


# Changes keyboard presses to clicks and stores changed keys
def change():
    for km in kms:
        if km.is_modal or km.space_type not in change_spaces:
            continue
        for kmi in km.keymap_items:
            if kmi.map_type != 'KEYBOARD':
                continue
            if kmi.type in skip_key_types or kmi.idname in skip_key_idnames:
                continue
            if kmi.value == 'PRESS':  # (usually)
                kmi.value = 'CLICK'
                changed_keys.append(kmi)
    print('# keys changed:', len(changed_keys))  # 1433


# Restore only (stored) keys we changed back to PRESS
def restore_changed():
    print('# keys to change:', len(changed_keys))  # 1433
    for kmi in changed_keys:
        kmi.value = 'PRESS'
    changed_keys.clear()


# Restore all keys to defaults (not custom user edits!)
def restore_defaults():
    for km in kms:
        # km.restore_to_default()   # buggy! also not necessary
        for kmi in km.keymap_items:
            km.restore_item_to_default(kmi)


change()
# restore_changed()
# restore_defaults()
1 Like
18

The main problem is that when you change it to click without a click&drag event a lot of things don’t work.

Could be better that when you change a hotkey to click&drag the click normal if exist change automatically to click instead of press

19

Yeah, that’s why I started adding exception lists when I was experimenting past just the 3D View, then I realized it was going to get complex fast. It might just be better to target only specific keys, or ultimately just use a custom handcrafted exported keymap or a format like the new blender_default.py keyconfig.

It would be nice if there was a compiled list of good keys to change to click, and the defaults were changed. This would make addon scripting easier, given that we currently can’t change user keymaps at startup.

20

honestly, I wouldn’t know if my mind would confuse all these combinations