Industry Compatible Keymap: Questions, suggestions and answers

All of those issues should already be fixed in the latest beta of 2.83. You might want to try that :slight_smile:

Knife-Tool cut through shortcut (Modal Keymap: Z) does not work within IC Keymap

Is there a way to delete keyframes without the popup menu?

No, not by default, but we should probably change Delete/Backspace to simply delete and bypass the cleaning options.

3 Likes

Yeah, that would be more convenient.

Since recent keymap changes to file browser, the selection paradigm is inconsistent : adding items to selection in the file browser is now made by pressing ctrl+clicking, and range selection is made by shift+clicking (it used to be the opposite). However toggles in the rest of Blender still work with shift+click (such as the mesh edit mode buttons or the snap type buttons, etc). Additionally mesh edit selection still adds with shift+click, and some operators such as pick shortest path (which is basically range selection) still work with ctrl+click. Can we work on consistency on this topic ? preferably keeping the old method, unless there is a good reason to change.

Reason is industry standardness, as the keymap name hints at. On Mac and Windows in the Finder and Explorer, you do range selection by holding Shift, and toggle selections with Cmd/Ctrl. We do the same in the Outliner in Blender too.

The standard convention is to do it that way when there is a list. In icon view, or 3d view, the convention is to use Shift to extend the selection.

1 Like

I would argue with that but I am using ‘Blender’ keymap since always. Is it supposed to behave differently ? (plus I am using thumbnail view, not list view)

This thread is about the Industry Compatible keymap. For anything related to the built-in keymap, that is off topic here.

haha okay…

Yes but its not exactly like that in the filebrowser. Assumed we have an existing rangeselection of files and folder, then ctrl clicking a selected folder is deselecting it. But if you ctrl click it again then instead of toggling the folders selectionstate a switch to that folder is triggered. That’s quite confusing and even if currently drag n dropping elements into subfolders isn’t possible, this should behave consistent for all elements. ( For files Ctrl+LMB is indeed toggling the selection state )

Yep, there seems to be an issue there. I’m not sure if I can solve it via the keymap, but it sure is annoying,.

2 Likes

While we’re at it, can we eliminate the pop up menu while deleting in edit mode? I suppose this is trickier to deal with because of the deletion options in edit mode. I think the backspace key should default to “industry compatible” deletion without any pop ups. The delete key can be used for the pop up deletion menu. I feel like this was discussed previously before, but not sure why it’s not implemented yet… Any ui/ux issues with this suggestion?

1 Like

The main issue is how to handle the logic. I suppose ideally it would delete verts, edges or faces depending on the selection mode. The problem is that the keymap doesn’t really include any logic, meaning that the keymap can’t really check for things like the selection mode.

It would have to probably be added as an operator in Blender, which the keymap then can activate. So it’s not impossible to add it, but may not be feasible, since adding lots of operators in Blender to improve alternate keymaps probably isn’t necessarily what developers want.

1 Like

Thanks for the explanation. I suppose this will be difficult to convince the Blender developers that this would be good for UI/UX in the default keymap also? The delete key is already used for the delete pop up menu in the default keymap, so this isn’t stepping on anyone’s toes. Would they appreciate this UI/UX “extra” feature since the backspace key isn’t doing anything in the default keymap anyway? :wink: I think this would benefit both IC keymap users and the traditional Blender users.

2 Likes

Yes, it’s not completely out of the question. When I get time I will take a look.

4 Likes

The logic is easy but you’re right that it needs an operator to do it. What I ended up doing was adding my own ‘wrapper’ operator via python addon that contextually runs the existing Blender operator based on selection mode when I press Delete so I don’t have to waste time with the delete pop up. (Also it knows if we’re in Object or Edit Mode so it runs object.delete if we’re not editing.)

But there’s a good point to be made here about user expectations. My addon deletes faces but dissolves vertices and edges because that’s the behavior I expect from my experience in Maya.

selection_mode = [i for i in tuple(bpy.context.scene.tool_settings.mesh_select_mode)]
if selection_mode[0] == True: 
    bpy.ops.mesh.dissolve_verts()
elif selection_mode[1] == True:
    bpy.ops.mesh.dissolve_edges(use_verts=False)
elif selection_mode[2] == True:
    bpy.ops.mesh.delete(type='FACE')

However, other people expect that when you press Delete then it should always run mesh.delete instead.

Hypothetically you could write two wrapper operators. One that contextually deletes while skipping the popup, and a second that does the same thing but for dissolve while skipping the popup. Then the user could bind delete to Delete and dissolve to Ctrl+Delete, or something, and would never have to see the confirmation popup again.

Or hypothetically if you really wanted to make “one view3d delete operator to rule them all that skips the delete popup” you’d have to ask yourself which expectations you want to accommodate. If you want to satisfy both groups (those expecting delete and those expecting dissolve) at once you’d have to expose all of the options and flags for each of the commands which would not be pretty but would cover every possible permutation.

Neither of these are great solutions because they lead to more operator proliferation. The alternative would be to rewrite Blender’s existing operators to be context-aware and skip the popup (reserve the popup for a new menu invoke) but that would probably be an… unpleasant… breaking change for many users and addons.

The least evil options might be to add a new wrapper operator… or to take no action and just let users fix the problem with addons. But the existence of the delete popup is a workflow-interrupting problem for some people, and not everyone has the ability to write their own addon to fix it. None of the solutions are nice and clean.

1 Like

Great to hear there’s some hope. There’s also a bit of potential for the backspace key to use modifier keys for more sophisticated deletions.

Separate topic:

blender_modes2

I know you’re not running out of things to do and you probably don’t want to revisit this issue seeing how the previous discussion went, but I think there needs to be more consistency with the numerical keys for different modes. There’s probably not enough number keys to support all of them. There’s only 9 and 0 left, but I think we should just utilize them even though they are far on the other side of the keyboard because I think the modes should have their own unique keys to avoid confusion and conflicts. You already had to fix one bug dealing with the Pose Mode and the 3 key. Unfortunately, I don’t have good suggestions without bringing the wrath out of the IC keymap users. I’ll start from the least controversial proposal: Draw Mode gets number 9 and Pose Mode gets number 0.

For the other modes and potential future modes here are some options:

  1. Add a modifier key to the number keys.

  2. Use Numpad keys.

  3. It’s maybe better to not even have shortcut keys at all, but I think at least the previous proposals make it easier for new users to remap the keys because there are entries for them already.

If anyone has any better ideas to maintain consistency, please chime in.

In theory the keymap can include operators, but they will stop working as soon as users modify the keymap. We tried this for other things and it turned out to not be an acceptable solution.

We would need to include this inside Blender. Indeed the logic itself is super simple, but that is unfortunately not even really the issue :slight_smile:

I can talk to the other developers and see if they would accept such an operator.

2 Likes

Just as the Industry Compatible Keymap, call tools directly, I was wondering if I could perform a tool-oriented Blender Keymap. So G calls the active Move tool, and if it is already active, then call the action directly.
I know that Shift + Space and AltClick + G allow access to the tool, but I think it is more direct to access directly with G.

I think that all the needs of former Blender users have been solved with the keyboard and current options, so I think that We can experiment with new solutions for a tool-based model. Editors like the video would also greatly appreciate it.