blender/blender

Fix #93403: Own keymap sets for each type of node editor. #106902

Open

Alexander Revkov wants to merge 2 commits from arevkov/blender:node_editor_shortcuts into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.

Alexander Revkov commented

2023-04-13 14:53:39 +02:00

First-time contributor

The solution resolves conflicts when using the same keyboard shortcuts in different node editors. Created own keymap sets for texture nodes, shader nodes, geometry nodes and compositor nodes editors.

Task #93403.

The solution resolves conflicts when using the same keyboard shortcuts in different node editors. Created own keymap sets for texture nodes, shader nodes, geometry nodes and compositor nodes editors. Task #93403.

Alexander Revkov changed title from ~~WIP: Own keymap sets for each type of node editor.~~ to Own keymap sets for each type of node editor.

2023-04-16 19:28:57 +02:00

Iliya Katushenock changed title from ~~Own keymap sets for each type of node editor.~~ to Fix #93403: Own keymap sets for each type of node editor.

2023-04-16 19:32:39 +02:00

Iliya Katushenock added this to the Module: User Interface project 2023-04-16 19:33:02 +02:00

Iliya Katushenock added the

Nodes & Physics

label 2023-04-16 19:33:08 +02:00

Alexander Revkov force-pushed node_editor_shortcuts from e316d26d44 to c5a3146fd0

2023-04-20 17:26:58 +02:00

Compare

Brecht Van Lommel commented

2023-07-24 11:45:58 +02:00

Owner

The user interface for this is not obvious. Now it will always put shortcuts in the per type keymap, but I think for most cases you actually want to change the shortcut for all editors. Adding shortcuts for specific nodes is the exception. Users would somehow have to pick the right generic or specific keymap, which is not straightforward when assigning shortcuts by right clicking on a menu item. Or we'd have to automatically figure out the right one depending on the operator or even specific node used in the operator, if it exists across multiple editors.

An alternative solution to the bug report would be to make the node add operator poll check if the node type exists, and if not return false. I would prefer that.

The user interface for this is not obvious. Now it will always put shortcuts in the per type keymap, but I think for most cases you actually want to change the shortcut for all editors. Adding shortcuts for specific nodes is the exception. Users would somehow have to pick the right generic or specific keymap, which is not straightforward when assigning shortcuts by right clicking on a menu item. Or we'd have to automatically figure out the right one depending on the operator or even specific node used in the operator, if it exists across multiple editors. An alternative solution to the bug report would be to make the node add operator poll check if the node type exists, and if not return false. I would prefer that.

Ludvik Koutny commented

2023-09-02 12:14:47 +02:00

Contributor

The user interface for this is not obvious. Now it will always put shortcuts in the per type keymap, but I think for most cases you actually want to change the shortcut for all editors. Adding shortcuts for specific nodes is the exception. Users would somehow have to pick the right generic or specific keymap, which is not straightforward when assigning shortcuts by right clicking on a menu item. Or we'd have to automatically figure out the right one depending on the operator or even specific node used in the operator, if it exists across multiple editors.

An alternative solution to the bug report would be to make the node add operator poll check if the node type exists, and if not return false. I would prefer that.

Thankfully a voice of reason! Couldn't agree more. Node Editor has currently 82 shortcuts in the default keymap. It would be absolutely crazy to add 246 new keymap entries just because of a a rare exception where user has keymapped specific nodes, instead of doing a simple check if node works in given context.

At that point, we may as well just hardcode the default keymap because the effort to create a custom one would tip over from extremely difficult to borderline impossible.

> The user interface for this is not obvious. Now it will always put shortcuts in the per type keymap, but I think for most cases you actually want to change the shortcut for all editors. Adding shortcuts for specific nodes is the exception. Users would somehow have to pick the right generic or specific keymap, which is not straightforward when assigning shortcuts by right clicking on a menu item. Or we'd have to automatically figure out the right one depending on the operator or even specific node used in the operator, if it exists across multiple editors. > > An alternative solution to the bug report would be to make the node add operator poll check if the node type exists, and if not return false. I would prefer that. Thankfully a voice of reason! Couldn't agree more. Node Editor has currently 82 shortcuts in the default keymap. It would be absolutely crazy to add 246 new keymap entries just because of a a rare exception where user has keymapped specific nodes, instead of doing a simple check if node works in given context. At that point, we may as well just hardcode the default keymap because the effort to create a custom one would tip over from extremely difficult to borderline impossible.

This pull request has changes conflicting with the target branch.

source/blender/windowmanager/intern/wm_keymap_utils.c

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u node_editor_shortcuts:arevkov-node_editor_shortcuts

git checkout arevkov-node_editor_shortcuts

Sign in to join this conversation.

No reviewers

No Label

Animation & Rigging

Automated Testing

Blender Asset Bundle

Code Documentation

Dependency Graph

Development Management

Images & Movies

Motion Tracking

Nodes & Physics

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Viewport & EEVEE

Virtual Reality

Asset Browser Project

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

Nodes & Physics

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Viewport & EEVEE

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#106902

No description provided.