Popover search menu when Drag&Release a NodeLink in node editors #78919

New Issue

Antonio Vazquez · 2020-07-14T15:27:53+02:00

Antonio Vazquez commented

2020-07-14 15:27:53 +02:00

This task is to discuss the pacht D8286.

this patch includes a new behaviour for when dragging node links.
When releasing over a blank space ir shows up a seach menu to add a node and link automatically with the one you dragged the link.

Based on this RCS proposal: https:*blender.community/c/rightclickselect/bMbbbc/This behaviour is also presented in other softwares with node editors, so it's a expected behaviour for users coming from other softwares as:- Unreal Engine: https:*youtu.be/icR_EgXrS6o?t=5175

Unity: https://youtu.be/Ar9eIn4z6XE?t=535
Houdini: https://youtu.be/j3Qqiy6uC5I?t=289

Some notes:

You can use the search to filter the node list.
Shows only the nodes that are compatible with the source socket (the one you dragged from), that is, nodes with sockets of the same type.
It also respect if you are dragging from input or output so for the list only search for the input/output of the other nodes.
It knows when you are detaching a node link, so in that cases, it will prevent to not show-up!
It should support all node editors.

Preview video:
2020-07-13 22-46-17.mp4

Issues:

Maybe some nodes are not filtered in the list, is the case of 'Mix Shader' node and I'm not usre why, so some kind of help into this will be very welcome!

Future:

The part of the auto-link both nodes can be improved a lot, it links to first empty available socket and that's not always the desirable.
Can be improved adding list of nodes sorted by categories (as SHIFT+A), but atm I think with only the search part is nice to go for a first patch and get some users feedback.
For UI team: what about an option to toggle on/off this behaviour? (for users don't want the search always) Would it be nice?

This task is to discuss the pacht [D8286](https://archive.blender.org/developer/D8286). this patch includes a new behaviour for when dragging node links. When releasing over a blank space ir shows up a seach menu to add a node and link automatically with the one you dragged the link. Based on this RCS proposal: https:*blender.community/c/rightclickselect/bMbbbc/*This behaviour is also presented in other softwares with node editors, so it's a expected behaviour for users coming from other softwares as:*- Unreal Engine: https:*youtu.be/icR_EgXrS6o?t=5175 - Unity: https://youtu.be/Ar9eIn4z6XE?t=535 - Houdini: https://youtu.be/j3Qqiy6uC5I?t=289 **Some notes:** - You can use the search to filter the node list. - Shows only the nodes that are compatible with the source socket (the one you dragged from), that is, nodes with sockets of the same type. - It also respect if you are dragging from input or output so for the list only search for the input/output of the other nodes. - It knows when you are detaching a node link, so in that cases, it will prevent to not show-up! - It should support all node editors. **Preview video:** [2020-07-13 22-46-17.mp4](https://archive.blender.org/developer/F8692176/2020-07-13_22-46-17.mp4) **Issues:** - Maybe some nodes are not filtered in the list, is the case of 'Mix Shader' node and I'm not usre why, so some kind of help into this will be very welcome! **Future:** - The part of the auto-link both nodes can be improved a lot, it links to first empty available socket and that's not always the desirable. - Can be improved adding list of nodes sorted by categories (as SHIFT+A), but atm I think with only the search part is nice to go for a first patch and get some users feedback. - For UI team: what about an option to toggle on/off this behaviour? (for users don't want the search always) Would it be nice?

Antonio Vazquez commented

2020-07-14 15:27:53 +02:00

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

Antonio Vazquez commented

2020-07-14 15:27:53 +02:00

Added subscribers: @antoniov, @ideasman42, @jfmatheu

Antonio Vazquez commented

2020-07-14 15:30:54 +02:00

Added subscribers: @brecht, @juang3d

Brecht Van Lommel commented

2020-07-14 16:18:26 +02:00

The ability to add, link and position a node in one action is quite powerful, and for the positioning part you need dragging. If needed there could be a modifier key to hold before adding, to avoid issues with mis-clicks when trying to drag the node. But not needing that at all would be nice.

A bigger distance threshold should definitely be added, though it doesn't solve the whole problem. Some threshold when near other sockets may also help, to avoid adding a node when failing to connect? Maybe it also helps to check the drag direction, that it's not into the node? Not sure if all that is needed.

Further:

Nodes that get added can be positioned so that the output socket is at the location where the dragging ended. This allows for more precise positioning, otherwise you're required to move the node afterwards unless you are good at guessing where the node will end up exactly. Though this might require lowering the distance threshold, it's a trade-off.
The link line could remain visible while the search menu is open. Potentially the search menu could be in roughly the same place as the node would be as well.
If there are multiple compatible sockets, the search menu could list all of them. For example Light Path > Is Camera Ray, Light Path > Is Diffuse Ray, .. . This should be a relatively change I think.

The ability to add, link and position a node in one action is quite powerful, and for the positioning part you need dragging. If needed there could be a modifier key to hold before adding, to avoid issues with mis-clicks when trying to drag the node. But not needing that at all would be nice. A bigger distance threshold should definitely be added, though it doesn't solve the whole problem. Some threshold when near other sockets may also help, to avoid adding a node when failing to connect? Maybe it also helps to check the drag direction, that it's not into the node? Not sure if all that is needed. Further: * Nodes that get added can be positioned so that the output socket is at the location where the dragging ended. This allows for more precise positioning, otherwise you're required to move the node afterwards unless you are good at guessing where the node will end up exactly. Though this might require lowering the distance threshold, it's a trade-off. * The link line could remain visible while the search menu is open. Potentially the search menu could be in roughly the same place as the node would be as well. * If there are multiple compatible sockets, the search menu could list all of them. For example `Light Path > Is Camera Ray`, `Light Path > Is Diffuse Ray`, .. . This should be a relatively change I think.

Andres Stephens commented

2020-07-14 16:20:22 +02:00

Added subscriber: @AndresStephens

Andres Stephens commented

2020-07-14 16:20:22 +02:00

There was a debate in the original patch that a better threshold or some system to avoid misactivation might be needed.

I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference.

The issues highlighted with this was socket threshold, which has no pre-highlight per Blender UX in the node editor and the socket threshold is very low - practically drag to the socket to connect. If this were to be useful and not annoying by missing a socket connection, then the socket connection threshold should be increased and a highlight on the would be connected socket should shown, giving the user expected behaviour. If no highlight, no add search menu. If the noodle is in the connection hot zone, then the search menu wouldn't trigger. The issue of misactivation (which should never be part of the UX) is another issue with connecting sockets and should be another task.

This one is I would say.. good to go, at least even for experimental.

There was a debate in the original patch that a better threshold or some system to avoid misactivation might be needed. I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference. The issues highlighted with this was socket threshold, which has no pre-highlight per Blender UX in the node editor and the socket threshold is very low - practically drag to the socket to connect. If this were to be useful and not annoying by missing a socket connection, then the socket connection threshold should be increased and a highlight on the would be connected socket should shown, giving the user expected behaviour. If no highlight, no add search menu. If the noodle is in the connection hot zone, then the search menu wouldn't trigger. The issue of misactivation (which should never be part of the UX) is another issue with connecting sockets and should be another task. This one is I would say.. good to go, at least even for experimental.

Juanfran Matheu commented

2020-07-14 16:22:57 +02:00

Some insights based on Campbell and Brecht feedback:

(Campbell) Ctrl+Click over a socket to show-up the search: as Brecht pointed, one of the strongest points of this behaviour is placing+creating+linking all in one action, so this alternative will break that freedom.
About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX.
I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though.
About this from Campbell: "...users might wonder where else Blender uses drag actions to expose some hidden functionality", I'm aware of this and it really should be threated with UI/UX team. I have some ideas like showing some little icon/text when dragging so user gets visual feedback as you can add a node from that action, but not sure about the best way it can be tackled or if it will end up into some intrusive visual feedback.
(Brecht) About keep node link being drawn, I like it and I though of it, but as the modal has to finish and the UI block is apart from it I can't think of a not dirty solution now, but I would like to dig into it as it gives more feedback on where the node will be placed. (maybe some immediate drawing callback?)
About adding some kind of key modifier to invoke it, I would prefer not to do that and keep it simple as possible. As for the same reason we have the powerfull and efficient CTRL+RMB to cut links but users keep using drag&drop to detach links as maybe (?) feels more handy without keyboard dependency as well as it is not a hidden feature.

**Some insights based on Campbell and Brecht feedback:** - (Campbell) Ctrl+Click over a socket to show-up the search: as Brecht pointed, one of the strongest points of this behaviour is placing+creating+linking all in one action, so this alternative will break that freedom. - About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX. - I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though. - About this from Campbell: "...users might wonder where else Blender uses drag actions to expose some hidden functionality", I'm aware of this and it really should be threated with UI/UX team. I have some ideas like showing some little icon/text when dragging so user gets visual feedback as you can add a node from that action, but not sure about the best way it can be tackled or if it will end up into some intrusive visual feedback. - (Brecht) About keep node link being drawn, I like it and I though of it, but as the modal has to finish and the UI block is apart from it I can't think of a not dirty solution now, but I would like to dig into it as it gives more feedback on where the node will be placed. (maybe some immediate drawing callback?) - About adding some kind of key modifier to invoke it, I would prefer not to do that and keep it simple as possible. As for the same reason we have the powerfull and efficient CTRL+RMB to cut links but users keep using drag&drop to detach links as maybe (?) feels more handy without keyboard dependency as well as it is not a hidden feature.

Juan Gea commented

2020-07-14 17:52:22 +02:00

About this:

"...users might wonder where else Blender uses drag actions to expose some hidden functionality"

Well, this kind of functionality has been present in UE4 since a lot of time, and no one wonder where can they drag to show up some kind of hidden menu :)

It's just a feature of the nodes, it works in shader nodes, it works in blueprint (visual programming) nodes, it works everywhere, and that's it.

While for shaders and compositing it may seem something "good" but not vital, for particles and other kind of nodes this is basic, this helps users to understand what works with what, this ease the process of learning to work with nodes, and it's a "thinking" asssistant, in UE4 is a big success, and I always wondered why Blender didn't have something like that.

I think it's important to polish the concept and reach a point where the implementation is solid, but don't be afraid for the "users may think...", in any case, let the users to test it and ask them what they think, don't assume what users may wonder, that's what daily builds are for partially, specially now with the experimental features options, which BTW make the users wonder where can the enable some more hidden functionality :)

About this: "...users might wonder where else Blender uses drag actions to expose some hidden functionality" Well, this kind of functionality has been present in UE4 since a lot of time, and no one wonder where can they drag to show up some kind of hidden menu :) It's just a feature of the nodes, it works in shader nodes, it works in blueprint (visual programming) nodes, it works everywhere, and that's it. While for shaders and compositing it may seem something "good" but not vital, for particles and other kind of nodes this is basic, this helps users to understand what works with what, this ease the process of learning to work with nodes, and it's a "thinking" asssistant, in UE4 is a big success, and I always wondered why Blender didn't have something like that. I think it's important to polish the concept and reach a point where the implementation is solid, but don't be afraid for the "users may think...", in any case, let the users to test it and ask them what they think, don't assume what users may wonder, that's what daily builds are for partially, specially now with the experimental features options, which BTW make the users wonder where can the enable some more hidden functionality :)

Bent Hillerkus commented

2020-07-14 18:39:49 +02:00

Added subscriber: @bent

Matt commented

2020-07-14 19:50:14 +02:00

Added subscriber: @mattli911

Matt commented

2020-07-14 19:50:14 +02:00

This comment was removed by @mattli911

*This comment was removed by @mattli911*

Rahul Chaudhary commented

2020-07-15 05:14:04 +02:00

Added subscriber: @RC12

Campbell Barton commented

2020-07-15 07:32:11 +02:00

A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already.

This way it won't be a hidden-feature.

A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already. This way it won't be a hidden-feature.

imad commented

2020-07-15 12:25:04 +02:00

Added subscriber: @imad

Brecht Van Lommel commented

2020-07-15 14:45:16 +02:00

In #78919#978880, @AndresStephens wrote:
I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference.

For these kind of simpler features we should not have them in an experimental state, but rather finish them before committing.

In #78919#978883, @jfmatheu wrote:

About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX.

The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though.

It shouldn't be complex, just means that every search entry is a node + socket instead of only a node.

In #78919#979255, @ideasman42 wrote:
A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already.

This sounds good to me.

> In #78919#978880, @AndresStephens wrote: > I would consider this not too necessary to have this feature out in the wild for the general user. This could be a feature that could be added as experimental or with an Interface prop toggle for user preference. For these kind of simpler features we should not have them in an experimental state, but rather finish them before committing. > In #78919#978883, @jfmatheu wrote: > - About adding some threshold, it will add more complexity but if it's only for when you miss a socket connection (some rect area around node sockets) I believe that little one can make a big difference to improve UX. The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me. > - I really like this from Brecht: "If there are multiple compatible sockets, the search menu could list all of them.". It's something I really thought of, but for further... Not sure about complexity in adding this though. It shouldn't be complex, just means that every search entry is a node + socket instead of only a node. > In #78919#979255, @ideasman42 wrote: > A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor - so dragging the socket on an empty area will add a new node, from the videos linked Unity does this already. This sounds good to me.

David commented

2020-07-15 14:56:48 +02:00

Added subscriber: @Galagax

David commented

2020-07-15 14:56:48 +02:00

I would suggest another functionality, when u "ctrl+lftclick", for example, on the node in the search bar it will preview the node and let u choose which socket u would like to attach to it

Juanfran Matheu commented

2020-07-15 22:29:42 +02:00

In #78919#979503, @brecht wrote:
A dragged distance threshold seems the most important to me.

That sounds nice and easy to add. If wanted, I can try to add it so we can see it in action and make a better idea.
Also, some design into how to communicate user if node link is not valid or it is - for adding a node - based on that threshold, such as color change or just the text/icon (shows-up or not).

It shouldn't be complex, just means that every search entry is a node + socket instead of only a node.

Perfect 👍 I didn't dig into it yet, so that's why I was not totally sure.

In #78919#979255, @ideasman42 wrote:
A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor

Great for me, I already know how to draw text, I can add it so we can give it a try.

> In #78919#979503, @brecht wrote: > A dragged distance threshold seems the most important to me. That sounds nice and easy to add. If wanted, I can try to add it so we can see it in action and make a better idea. Also, some design into how to communicate user if node link is not valid or it is - for adding a node - based on that threshold, such as color change or just the text/icon (shows-up or not). > It shouldn't be complex, just means that every search entry is a node + socket instead of only a node. Perfect 👍 I didn't dig into it yet, so that's why I was not totally sure. > In #78919#979255, @ideasman42 wrote: > A way to avoid confusion with this feature could be to show text or plus-icon next to the cursor Great for me, I already know how to draw text, I can add it so we can give it a try.

Serj Maiorov commented

2020-07-16 00:22:00 +02:00

Added subscriber: @SerjMaiorov

Ryan Inch commented

2020-07-16 06:22:54 +02:00

Added subscriber: @Imaginer

Ryan Inch commented

2020-07-16 06:22:54 +02:00

Looks like a nice feature. One thing I noticed in the video was that the search menu would keep the last search term (standard behavior, I know), but it often wouldn't show anything because the last created node isn't valid for the new socket. It seems to me that in this case, remembering the search term is more of a hindrance than a help and I'd suggest having it show up with the search field blank each time instead so that you can immediately see all of the available node types for that socket.

Juanfran Matheu commented

2020-07-17 20:20:37 +02:00

In #78919#979908, @Imaginer wrote:
Looks like a nice feature. One thing I noticed in the video was that the search menu would keep the last search term (standard behavior, I know), but it often wouldn't show anything because the last created node isn't valid for the new socket. It seems to me that in this case, remembering the search term is more of a hindrance than a help and I'd suggest having it show up with the search field blank each time instead so that you can immediately see all of the available node types for that socket.

I agree with you

> In #78919#979908, @Imaginer wrote: > Looks like a nice feature. One thing I noticed in the video was that the search menu would keep the last search term (standard behavior, I know), but it often wouldn't show anything because the last created node isn't valid for the new socket. It seems to me that in this case, remembering the search term is more of a hindrance than a help and I'd suggest having it show up with the search field blank each time instead so that you can immediately see all of the available node types for that socket. I agree with you

Evandro Costa commented

2020-07-18 23:16:18 +02:00

Added subscriber: @EvandroFerreiradaCosta

Evandro Costa commented

2020-07-18 23:16:18 +02:00

In #78919#979503, @brecht wrote:
The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area accidentally be something that users do that commonly?
We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do.
It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing.

Dragged the line but decided you didn't want to?
Release Left-Click anywhere, knowing that the popup will appear,
Press Right-Click to exit/close it, done.

This is also the same argument for notimplementing a Ctrl-Click to drag-create nodes. Why force a key-press before every operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents?
I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident.

This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes very close to the originating nodes.

I created this GIF example.

I'd like to know if a threshold would impede the user from creating that node in that middle space, because he didn't drag the line far enough. Would we be forced to drag the line far away to open the popup, then after to grab the created node and put it in place?

I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important).

I used darkening to indicate which socket will be targeted, but this user proposal of having a Highlight appear around the target socket would also solve the issue.

I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient)
Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that.

> In #78919#979503, @brecht wrote: > The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me. Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area **accidentally** be something that users do that commonly? We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do. It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing. Dragged the line but decided you didn't want to? Release Left-Click anywhere, knowing that the popup will appear, Press Right-Click to exit/close it, done. This is also the same argument for **not**implementing a Ctrl-Click to drag-create nodes. Why force a key-press before `every` operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents? I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident. This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes **very close** to the originating nodes. I created this GIF example. ![InsertingImageTexture.gif](https://archive.blender.org/developer/F8704840/InsertingImageTexture.gif) I'd like to know if a threshold would impede the user from creating that node in that middle space, because he didn't drag the line far enough. Would we be forced to drag the line far away to open the popup, then after to grab the created node and put it in place? I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important). ![image.png](https://archive.blender.org/developer/F8704850/image.png) I used darkening to indicate which socket will be targeted, but **[this user proposal ](https://blender.community/c/rightclickselect/Zpbbbc/)** of having a Highlight appear around the target socket would also solve the issue. I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient) Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that.

Matt commented

2020-07-18 23:29:21 +02:00

In #78919#981552, @EvandroFerreiradaCosta wrote:

In #78919#979503, @brecht wrote:
The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me.

Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area accidentally be something that users do that commonly?
We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do.
It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing.

Dragged the line but decided you didn't want to?
Release Left-Click anywhere, knowing that the popup will appear,
Press Right-Click to exit/close it, done.

This is also the same argument for notimplementing a Ctrl-Click to drag-create nodes. Why force a key-press before every operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents?
I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident.

This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes very close to the originating nodes.

I created this GIF example.

I'd like to know if a threshold would impede the user from creating that node in that middle space, because he didn't drag the line far enough. Would we be forced to drag the line far away to open the popup, then after to grab the created node and put it in place?

I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important).

I used darkening to indicate which socket will be targeted, but this user proposal of having a Highlight appear around the target socket would also solve the issue.

I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient)
Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that.

This is very interesting..! So you're saying, if you left-click and drag out, it will do as normal, but if you let go, then it pops up and searches/creates a new one? If so, that sounds good to me I think.
Then yeah ,if you can right-click to cancel as you said, that would be good as well.

> In #78919#981552, @EvandroFerreiradaCosta wrote: >> In #78919#979503, @brecht wrote: >> The main issue is not missed socket connections I think, at least testing here it doesn't seem that likely. A dragged distance threshold seems the most important to me. > > Well, if the issue is not missed sockets, then what is it? Is it dragging a line and releasing Left-click in an open area **accidentally** be something that users do that commonly? > We must keep in mind that Right-Click and ESC are both quick ways of canceling any unwanted popup windows or behaviors. And that this is a behavior present everywhere in blender and something users instinctly do. > It is extremely simple, quick and intuitive for the user to Right-Click in order to close the unwanted popup, IF unwanted, and go back to what he was doing. > > Dragged the line but decided you didn't want to? > Release Left-Click anywhere, knowing that the popup will appear, > Press Right-Click to exit/close it, done. > > This is also the same argument for **not**implementing a Ctrl-Click to drag-create nodes. Why force a key-press before `every` operation, and instead not keep it simple allowing the user to simply right-click or press esc after only those rare unwanted accidents? > I'm very certain that people will release Left-click while dragging purposefully much much more frequently than unwillingly doing it by accident. > > This threshold idea seems to be more of an arbitrary limitation for the feature than an avoidance of unexpected behavior, after all any threshold would basically impede the user from drag-creating nodes **very close** to the originating nodes. > > I created this GIF example. > ![InsertingImageTexture.gif](https://archive.blender.org/developer/F8704840/InsertingImageTexture.gif) > I'd like to know if a threshold would impede the user from creating that node in that middle space, because he didn't drag the line far enough. Would we be forced to drag the line far away to open the popup, then after to grab the created node and put it in place? > > I also added in the example above a suggestion for the secondary "socket popup" which lists the socket names and colors/types (knowing the type, image/vector/value/etc, may be important). > ![image.png](https://archive.blender.org/developer/F8704850/image.png) > I used darkening to indicate which socket will be targeted, but **[this user proposal ](https://blender.community/c/rightclickselect/Zpbbbc/)** of having a Highlight appear around the target socket would also solve the issue. > > I also reinforced the idea, discussed in the original proposal, of using the regular Shift+A menu instead of a simple Search/History menu. (Although I agree that a History is very convenient) > Sometimes navigating towards an option that you use frequently is much faster than removing the hand from the mouse in order to start typing it in the keyboard. Not to mention that sometimes you don't know or remember the name of a node or you're not sure of what you want. The regular list menu helps that. This is very interesting..! So you're saying, if you left-click and drag out, it will do as normal, but if you let go, then it pops up and searches/creates a new one? If so, that sounds good to me I think. Then yeah ,if you can right-click to cancel as you said, that would be good as well.

Andres Stephens commented

2021-06-18 01:32:50 +02:00

Bump, will this be implemented for 3.0? I certainly hope so! It looks practically done.