Shortcuts on link dragging to quickly add nodes #94598

New Issue

Simon Thommes · 2022-01-03T12:52:42+01:00

Simon Thommes commented

2022-01-03 12:52:42 +01:00

The functionality to add nodes on link dragging allows to quickly extend a node tree with a string of operations. Due to the fact that this functionality is a modal operator it would be possible to add additional keyboard inputs before the mouse button is let go, to quickly terminate the operation and pick a certain nodes with a shortcut, instead of typing in the name in the search bar after letting go.

This extended functionality would drastically increase workflow efficiency in the cases of a few, commonly used nodes.

Which nodes that includes and how the selection adapts to the context of the dragged link (editor/socket type, in/out link) needs to be figured out/discussed in this task.

Proposed included nodes and shortcuts:

Input
{key 1} : Value
{key 2} : Color
{key 3} : Vector

Link Type: Any (Node version/settings according to the matching datatype)
{key W}: Switch
{key Y}: Reroute (visual representation of a junction and {key R} is reserved)

Link Type: Geometry
{key J}: Join Geometry
{key P}: Set Position

Link Type: Shader
{key X}: Mix Shader
{key A}: Add Shader

Link Type: Float/Vec/Vec2/Col/Int/Bool (Node version/settings according to the matching datatype)
{key X}: Mix (Ideally there would also be nodes for at least vector and float)
{key A}: Add
{key S}: Subtract
{key F}: Multiply (F for factor)
{key D}: Divide
{key C}: Curve
{key R}: Map Range
{key G}: Color Ramp (G for gradient (?))
{key I}: Invert

Separate/Combine Nodes
Using the context sensitivity of the shortcuts, the different separate/combine could elegantly be solved with the keys {key 1}, {key 2}, {key 3}.
Examples:
Dragging from a float output and pressing {key 3} would add a Combine XYZ Node.
Dragging from a float input and pressing {key 2} would add a Separate RGB Node.
Dragging from a vector output and pressing {key 1} would add a Separate XYZ Node.

↓ Key \ Socket →	Float In	Float Out	RGB In	RGB Out	XYZ In	XYZ Out
{key 1}	Value	/	Com. RGB	Sep. RGB	Com. XYZ	Sep. XYZ
{key 2}	Sep. RGB	Com. RGB	RGB	/	RGB	/
{key 3}	Sep. XYZ	Com. XYZ	Vector	/	Vector	/

Note: This might look confusing, but my hope is that it is intuitive, when used.

Notes

The shortcuts should be sensible with the name, but that leads to collisions quite quickly.

Many more useful rules would be possible, but I would keep it to a relatively small and manageable amount for now. The more get added, the muddier and subjective it gets which nodes should be included.

In a perfect scenario this would even be customizable by the user, but for now it would need to be hardcoded.

Some of these nodes are not yet available in every node editor and should be following the implementation of this feature. Unifying the node editors to allow the same workflow/copying nodes/sharing nodegroups is a separate discussion, but should be addressed in a sensible scope for this task.

The functionality to add nodes on link dragging allows to quickly extend a node tree with a string of operations. Due to the fact that this functionality is a modal operator it would be possible to add additional keyboard inputs before the mouse button is let go, to quickly terminate the operation and pick a certain nodes with a shortcut, instead of typing in the name in the search bar after letting go. This extended functionality would drastically increase workflow efficiency in the cases of a few, commonly used nodes. Which nodes that includes and how the selection adapts to the context of the dragged link (editor/socket type, in/out link) needs to be figured out/discussed in this task. **Proposed included nodes and shortcuts:** **Input** {key 1} : Value {key 2} : Color {key 3} : Vector **Link Type: Any (Node version/settings according to the matching datatype)** {key W}: Switch {key Y}: Reroute (visual representation of a junction and {key R} is reserved) **Link Type: Geometry** {key J}: Join Geometry {key P}: Set Position **Link Type: Shader** {key X}: Mix Shader {key A}: Add Shader **Link Type: Float/Vec/Vec2/Col/Int/Bool (Node version/settings according to the matching datatype)** {key X}: Mix (Ideally there would also be nodes for at least vector and float) {key A}: Add {key S}: Subtract {key F}: Multiply (F for factor) {key D}: Divide {key C}: Curve {key R}: Map Range {key G}: Color Ramp (G for gradient (?)) {key I}: Invert **Separate/Combine Nodes** Using the context sensitivity of the shortcuts, the different separate/combine could elegantly be solved with the keys {key 1}, {key 2}, {key 3}. **Examples:** Dragging from a float output and pressing {key 3} would add a `Combine XYZ` Node. Dragging from a float input and pressing {key 2} would add a `Separate RGB` Node. Dragging from a vector output and pressing {key 1} would add a `Separate XYZ` Node. | ↓ Key \ Socket → | Float In | Float Out | RGB In | RGB Out | XYZ In | XYZ Out | | -- | -- | -- | -- | -- | -- | -- | | {key 1} | Value | / | Com. RGB | Sep. RGB | Com. XYZ | Sep. XYZ | | {key 2} | Sep. RGB | Com. RGB | RGB | / | RGB | / | | {key 3} | Sep. XYZ | Com. XYZ | Vector | / | Vector | / | *Note: This might look confusing, but my hope is that it is intuitive, when used.* **Notes** The shortcuts should be sensible with the name, but that leads to collisions quite quickly. Many more useful rules would be possible, but I would keep it to a relatively small and manageable amount for now. The more get added, the muddier and subjective it gets which nodes should be included. In a perfect scenario this would even be customizable by the user, but for now it would need to be hardcoded. Some of these nodes are not yet available in every node editor and should be following the implementation of this feature. Unifying the node editors to allow the same workflow/copying nodes/sharing nodegroups is a separate discussion, but should be addressed in a sensible scope for this task.

Simon Thommes commented

2022-01-03 12:52:42 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Simon Thommes commented

2022-01-03 12:52:42 +01:00

Added subscriber: @SimonThommes

Garek commented

2022-01-03 17:23:56 +01:00

Added subscriber: @Garek

Paul Larson commented

2022-01-03 19:45:17 +01:00

Added subscriber: @GeorgiaPacific

tt commented

2022-01-03 20:48:01 +01:00

Added subscriber: @ToxicTuba

tt commented

2022-01-03 20:48:01 +01:00

interesting.
What about using the numpad operators +-*/ for Add, Subtract, Multiply Divide?
numpad0 could be mix and numpad decimal for maprange. though decimal can be . or ,
that would also keep those together on the keyboard that belong together. Alternatively A and S and D are close together so using F for Multiply (factor?) keeps the keys close together...

interesting. What about using the numpad operators +-*/ for Add, Subtract, Multiply Divide? numpad0 could be mix and numpad decimal for maprange. though decimal can be . or , that would also keep those together on the keyboard that belong together. Alternatively A and S and D are close together so using F for Multiply (**f**actor?) keeps the keys close together...

Yuro commented

2022-01-03 23:16:18 +01:00

Added subscriber: @Yuro

Simon Thommes commented

2022-01-04 11:33:11 +01:00

In #94598#1282254, @ToxicTuba wrote:
What about using the numpad operators +-*/ for Add, Subtract, Multiply Divide?

Though I generally do like the idea of using the operator keys, i don't think we should utilize the numpad for this at all for two reasons:
One is that an existing numpad is not always given on a keyboard and we're generally moving away from requiring it for crucial shortcuts. The other is simply that usually people are using the mouse with their right on the right side of the keyboard. So if they are dragging a link, the shortcut will have to be executed with the left hand only. The numpad is just too far away in that case to allow a comfortable workflow.

that would also keep those together on the keyboard that belong together. Alternatively A and S and D are close together so using F for Multiply (factor?) keeps the keys close together...

The mapping of keys to nodes for this is definitely something that requires some discussion. I think your point of keeping them close on the keyboard is valid. I just want to mention that I do think we should stick to the first letter whenever possible, as discoverability is already going to be an issue with this feature.
That said, name clashes are unavoidable here. Multiply already clashes with mix, so I can see {key F} fitting better than {key U} as an alternative. {key X} for Mix would also be an option though.

One other idea to avoid name clashes that I just want to have mentioned would be a pie menu. But I don't actually think in this case a pie menu is a good idea.

> In #94598#1282254, @ToxicTuba wrote: >What about using the numpad operators +-*/ for Add, Subtract, Multiply Divide? Though I generally do like the idea of using the operator keys, i don't think we should utilize the numpad for this at all for two reasons: One is that an existing numpad is not always given on a keyboard and we're generally moving away from requiring it for crucial shortcuts. The other is simply that *usually* people are using the mouse with their right on the right side of the keyboard. So if they are dragging a link, the shortcut will have to be executed with the left hand only. The numpad is just too far away in that case to allow a comfortable workflow. > that would also keep those together on the keyboard that belong together. Alternatively A and S and D are close together so using F for Multiply (**f**actor?) keeps the keys close together... The mapping of keys to nodes for this is definitely something that requires some discussion. I think your point of keeping them close on the keyboard is valid. I just want to mention that I do think we should stick to the first letter whenever possible, as discoverability is already going to be an issue with this feature. That said, name clashes are unavoidable here. Multiply already clashes with mix, so I can see {key F} fitting better than {key U} as an alternative. {key X} for `Mix` would also be an option though. One other idea to avoid name clashes that I just want to have mentioned would be a pie menu. But I don't actually think in this case a pie menu is a good idea.

Simon Thommes changed title from ~~Add functionality for link dragging to quickly add nodes with shortcuts~~ to Shortcuts on link dragging to quickly add nodes

2022-01-04 11:39:44 +01:00

Erindale commented

2022-01-05 19:27:55 +01:00

Added subscriber: @Erindale

Erindale commented

2022-01-05 19:27:55 +01:00

I think your proposed shortcuts look good but I'd go for X for Mix and F for multiply (of the pairs you chose) to keep it all left handed

Yuro commented

2022-01-06 00:37:47 +01:00

I'm not a developer, so this is probably nonsense.
Since we seem to be able to select sockets on nodes:

So I don't know if we can select the socket first and then use the shortcut keys directly?
This is just like selecting a vertex in edit mode and pressing {key E} to extrude.
This may not necessarily be faster, but I believe it can reduce a lot of mouse dragging in node editor.

I'm not a developer, so this is probably nonsense. Since we seem to be able to select sockets on nodes: ![select socket.png](https://archive.blender.org/developer/F12790775/select_socket.png) ![1.gif](https://archive.blender.org/developer/F12790778/1.gif) So I don't know if we can select the socket first and then use the shortcut keys directly? This is just like selecting a vertex in edit mode and pressing {key E} to extrude. This may not necessarily be faster, but I believe it can reduce a lot of mouse dragging in node editor.

Erindale commented

2022-01-06 01:21:13 +01:00

@Yuro is making a good point actually. Maybe the drag / click can be toggled in settings because I find dragging much easier than clicking with a tablet and it feels more natural imo with a mouse but from an accessibility point of view though, I remember someone brought up how dragging isn't always possible for everyone before (maybe regarding muting noodles).

Ludvik Koutny commented

2022-01-06 08:08:27 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2022-01-06 08:08:27 +01:00

In #94598#1283558, @Yuro wrote:
I'm not a developer, so this is probably nonsense.
Since we seem to be able to select sockets on nodes:

So I don't know if we can select the socket first and then use the shortcut keys directly?
This is just like selecting a vertex in edit mode and pressing {key E} to extrude.
This may not necessarily be faster, but I believe it can reduce a lot of mouse dragging in node editor.

I am afraid this would mean significant overcomplication of the node editor keymap and possible keyboard shortcut conflicts. When you are in a link drag, you are in sort of a mode, so it's fine that the shortcuts work as the awareness of being in that mode is explicit, but when you are just in a regular node editor state, then suddenly you would have to be constantly aware whether you currently have a node socket selected or not, and the keymap would behave differently based on that.

That sounds very frustrating and error prone, especially given that in a complex node network, you'd have to be constantly watching out for that one selected socket, or adopt an irritating habit of always deselecting a node first before pressing any key, which makes even less sense, since many keyboard shortcuts actually require a node to be selected (like mute).

Even if this was possible to make it conflict-less with the default keymap, it would make life hell for anyone who is not using a default keymap.

So let's just not overcomplicate it, and let's keep this sort of obscure advanced functionality to node-wrangler like addons. If Python API exposes socket selection state, it should be very easy for anyone to script an addon doing this, but Blender's default keymap is already overcomplicated as is. Last thing we need is different keymap behavior based on whether there is one tiny circle selected in an editor which often displays hundreds of tiny circles at the same time.

> In #94598#1283558, @Yuro wrote: > I'm not a developer, so this is probably nonsense. > Since we seem to be able to select sockets on nodes: > ![select socket.png](https://archive.blender.org/developer/F12790775/select_socket.png) > ![1.gif](https://archive.blender.org/developer/F12790778/1.gif) > So I don't know if we can select the socket first and then use the shortcut keys directly? > This is just like selecting a vertex in edit mode and pressing {key E} to extrude. > This may not necessarily be faster, but I believe it can reduce a lot of mouse dragging in node editor. I am afraid this would mean significant overcomplication of the node editor keymap and possible keyboard shortcut conflicts. When you are in a link drag, you are in sort of a mode, so it's fine that the shortcuts work as the awareness of being in that mode is explicit, but when you are just in a regular node editor state, then suddenly you would have to be constantly aware whether you currently have a node socket selected or not, and the keymap would behave differently based on that. That sounds very frustrating and error prone, especially given that in a complex node network, you'd have to be constantly watching out for that one selected socket, or adopt an irritating habit of always deselecting a node first before pressing any key, which makes even less sense, since many keyboard shortcuts actually require a node to be selected (like mute). Even if this was possible to make it conflict-less with the default keymap, it would make life hell for anyone who is not using a default keymap. So let's just not overcomplicate it, and let's keep this sort of obscure advanced functionality to node-wrangler like addons. If Python API exposes socket selection state, it should be very easy for anyone to script an addon doing this, but Blender's default keymap is already overcomplicated as is. Last thing we need is different keymap behavior based on whether there is one tiny circle selected in an editor which often displays hundreds of tiny circles at the same time.

Simon Thommes commented

2022-01-06 11:51:54 +01:00

In #94598#1283699, @Rawalanche wrote:
I am afraid this would mean significant overcomplication of the node editor keymap and possible keyboard shortcut conflicts. When you are in a link drag, you are in sort of a mode, so it's fine that the shortcuts work as the awareness of being in that mode is explicit, but when you are just in a regular node editor state, then suddenly you would have to be constantly aware whether you currently have a node socket selected or not, and the keymap would behave differently based on that.

I fully agree. The modal nature of dragging the node link is crucial for this feature. The last thing I'd want to do would be to change the whole keymap for node editors.
It could be interesting to add another modal operator to e.g. {key E} which does the same as link dragging. But that would be an additional topic that comes with its own design questions.

> In #94598#1283699, @Rawalanche wrote: > I am afraid this would mean significant overcomplication of the node editor keymap and possible keyboard shortcut conflicts. When you are in a link drag, you are in sort of a mode, so it's fine that the shortcuts work as the awareness of being in that mode is explicit, but when you are just in a regular node editor state, then suddenly you would have to be constantly aware whether you currently have a node socket selected or not, and the keymap would behave differently based on that. I fully agree. The modal nature of dragging the node link is crucial for this feature. The last thing I'd want to do would be to change the whole keymap for node editors. It could be interesting to add another modal operator to e.g. {key E} which does the same as link dragging. But that would be an additional topic that comes with its own design questions.

Yuro commented

2022-01-06 13:18:42 +01:00

Thank you guys. I think I have realized that this may make the problem too complicated to be worth it.

Vladislav Macíček commented

2022-01-24 11:08:40 +01:00

Added subscriber: @Aeraglyx

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

Shortcuts on link dragging to quickly add nodes #94598