I think that makes sense, if you don’t need to reattach the link why not just cut it ? it’s an even simpler action
1 Like
I find the node wrangler more convenient in most cases during the disconnection phase。
This plugin should have been built in or turned on by default, I don’t know why it hasn’t been, almost all blender users I’ve looked at use scissors directly to break links, no one uses ctrl left click。
I never knew that ctrl+left click could break links until yesterday when I read about the new 3.5 feature ait left click can link swap, and I didn’t know that you can also ctrl left click to break the link line of a node, seeing as no one uses the ctrl left click at all.
Cutting (Ctrl+RMB, or “scissors”) and disconnecting (Ctrl+LMB) are different operations. The value of Ctrl+LMB becomes more apparent with multiple connections going out from a single socket as you can move them all to a different source at once. It’s also convenient to use it to “cut” when there are other noodles in the way so you can’t use the scissors easily, but as of now doing that brings up the search box when it perhaps shouldn’t, that’s what slowk1d was talking about (I think):
Ctrl+LMB is a relatively new feature, afaik, so that might be why you haven’t encountered it much yet. It is a very nice addition imo.
5 Likes
Yes precisely, it’s more a matter of consistency.
I have to say that while in your video you show its usefulness for that situation, more than once I hated this behaviour exactly because you can’t disconnect just one noodle from an input, but always all of them, which many times isn’t what I want. Still waiting for being able to select noodles in their entirety, to have best from both worlds… Right-Click Select — Blender Community
Well, isn’t it being consistent actually, technically? It’s more of a “relocate” shortcut, not a “disconnect” shortcut, so when you release on blank canvas it looks for a socket to connect. Makes sense to me, especially when there’s already a method for cutting (scissors) so the disconnection part’s a bit redundant. If most people keep using it just to disconnect links and find the search box jarring it might be best not to fight that intuition though I guess—I don’t have a strong preference.
Took a look at your RCS post, and while I share your frustration with the first example (dealing with individual entries in a multi-join socket), I’m not so sure about the second one, because if you mean to simply disconnect a single noodle you can use the scissors or detach from the input socket at the other end; and if you wish to relocate, you can simply create a link from a new source which will automatically detach the old one anyways?:
2 Likes
While the outcome of what you show in the video is technically the same, in that case my proposal was aimed also to give more easiness to dealing with noodles in the node editors, especially when we have to specifically select the socket, instead of easily select and drag any part of a noodle. And while yes, you show how you can resolve having multiple noodles connected to an input, to me it’s still an issue that you can disconnect a specific noodle from an Output, but can’t do the same with an Input.
If the input point has more than one connection and there is a lot of interference, hold down ait+left mouse button to move it slightly.
While I still think it would be wonderful to select and detach wires in any point and not just their ends, I made a request for improving multi-input sockets: Right-Click Select — Blender Community
Are you sure you know about the current functionality? 
6 Likes
Admiteddly, I didn’t.
I never thought about holding click and move up/down to go through them. Thank you for showing me, but I find it quite hidden, still think it could be visually improved and made more obvious.
2 Likes
Perhaps it would be easier, yes. That would be a first, considering Blender’s history with preselection highlighting. Also to consider : in some of the prototypes by @lone_noel the multi-input sockets are more widely spaced, so that there’s pretty much no ambiguity when picking a link. That’s in addition to better grid alignment, consistent spacings, etc. See Feedback wanted on node layout changes to match the node grid
I’d also like to add a papercut ! that ties in a bit with the changes by Leon.
The problem :
The node auto-offset feature is bound to always nudge some of the nodes out of grid alignment, because the nodes themselves are of arbitrary width. So even if they’re left-aligned to the grid, their right side is usually not, yet that’s where the margin is calculated from. That means even with a margin that’s an exact multiple of grid units, you can still send all your upstream/downstream nodes (from the point of insertion) out of alignment.
So I fiddled with the node_margin property to find that on my install, 83px correspond to exactly 4 grid units, a spacing I find comfortable, but is only valid with a ui scale of 1.5, and solves only half the issue.
I suggest :
- have node_margin use grid units/subdivisions instead of pixels
- when inserting a node, if the node’s position ends up unaligned with the grid, nudge it to the next grid unit (and with it all the upstream/downstream nodes)
- have node widths be snappable to grid increments
4 Likes
True, but also not true. While indeed preselection highlithing is considered an anti-feature in general terms, there are specific tools in Blender that indeed use it, like the Polybuild or the Knife tools. They are specific tools that have an exception because of their particular workflow, and I’d argue that also multi-input socket is a unique kind of node. So I wouldn’t mind seeing an exception, exactly because they work in a way different from all other sockets.
And apparently, it was considered too show all plugged wires when hovering on a multi-input socket, but unfortunately it never got developed: #84433 - Multi Input Socket for Nodes - blender - Blender Projects
Alternatively, my proposal could be integrated more with how the current way is: instead of showing all the plugged wires when hovering, the user still has to hold click and go up/down like in @modmoderVAAAA video, but instead of only highlithing the wire’s end, we see all the plugged circles.
3 Likes
I looked into this to see what it takes to change this and it doesn’t seem too involved, but I don’t think the preferences are the right place for this setting. I agree that this being per editor is really bad but making it per scene (just like the snap setting) seems reasonable.
Similar to what you described, I find the auto-offset useful when plopping down a lot of nodes quickly in the beginning and later disable it once I’m organizing the tree. Based on that it makes sense to me to be able to toggle this during a session without having to dive into the preferences.
Disabling auto-offset in your start-up file would then still mean you’d never encounter it unless you explicitly enabled it. Do you think that’s an acceptable compromise?
I also wanted to plug this feedback thread for changes to how joining into frames during transform works:
I had hoped to get a few people to test this to get some feedback on the direction and to make the behaviour solid before bringing it up with the core team. 
I don’t think it’s reasonable because auto-offset is a workflow/user preference, not a scene preference. Meaning it’s a toggle which doesn’t change the state of the scene (how it looks, functions and renders), but it changes the way tools respond to user interaction.
Blender has TONS of usability issues caused by the fact that developers can not distinguish between these two, yet the distinction is not that difficult. It’s relatively simple, just ask yourself a question - if someone else sends me their scene, or opens my scene and changes something in it, do I want this setting to come with the scene? Or do I want this setting to be stored within my Blender install.
Now if you apply this question to for example theme, or keyboard shortcut, the answer is a no-brainer. Obviously you would not want your Blender theme or keyboard shortcuts to change whenever you open someone else’s scene. If you apply this same question to the auto-offset, I think the answer becomes quite obvious as well. If you prefer to use or not use auto-offset, it doesn’t make sense for this setting to constantly change depending on which file you open.
The taboo of not putting node editor (or per editor settings in general) into user preferences has been already broken:
In miscellaneous, there’s even auto-offset margin setting. Let’s just create new rollout called “Node Editor” (since there’s already Text Editor), put the auto-offset margin there and add auto-offset checkbox next to it.
I can’t imagine anyone toggling auto offset on and off too often, since it would constantly mess with the muscle memory of what you intuitively expect to happen when placing the node, so user preferences should not be that much of a burden. If you spend couple of hours prototyping a functional node setup, and then you want to spend another 30 minutes doing cleanup, I don’t think opening user preferences once every 2.5 hours is that bad. Especially considering that the people who toggle this feature are probably a minority. I think most of people either want it always off or always on.
Alternative would be to create a “shortcut checkbox” somewhere in the node editor UI, but I think that could break some UI design guidelines.
Having it per scene, not per editor, would be less wrong, but still wrong. While it’s understandable things were constantly done wrong 10 years ago, when Blender was still an amateur toy project, I don’t think we should keep doing things wrong now in 2023, now that we have good understanding of how common sense UIs should work.
3 Likes
The reasoning is sound, but do you by any chance disable it after a while because it interferes with your tree cleanup process ? because if we solve its usability issues, you may never have to toggle it off again. I agree with @LudvikKoutny that it seems more of a user preference.
1 Like
Yes mostly. Though the issue isn’t so much what the auto-offset is doing specifically but that it introduces non-local changes.
With auto offset I might have to check how nodes off-screen are affected and first asses what even was changed before going about adjusting the layout.
Without auto-offset I still have to fix the layout where I inserted the node, but can then work my way forward from there always knowing what has changed.
During clean-up my priorities change from “keep nodes away from each other so I can keep adding stuff” to “I want things to be precisely where I put them”.
As described it’s really about my goal changing and I’m not sure if that is something that can be fixed. Some things like better alignment with the grid or maybe some tweaks to the logic which nodes are moved might improve things, but I’m not sure it would get to the point where I would want to keep it on once things start having a fixed place.
I’ll try to think about this more broadly, because it would be great to just never have to toggle this on/off. 
That could happen if it was a keymap property. We now have one which decides if a new node that’s being placed will be connected to underlying link when placed. I think it’s the Alt key. The issue was that the default behavior was inverted. That the auto-connection is on by default and Alt key is opt-out, not opt-in. If it would be opt-in, then it would make it easier to add for example shift.
So that if you place a new node over existing links, it just plops there. If you hold Alt, it connects to the underlying node link, and if you hold Alt+Shift, it connects to the underlying link and offsets the node around it to make space. You could also possibly hold Shift alone to offset the nodes around but not connect it to the underlying node link. This way, the option could be removed from the UI altogether, as it would become a property of the node translate modal operator.
This is great solution because:
- The state of the auto-offset would be stored with the keymap - the user preference. Not editor or scene file.
- User can easily change the user preference default value by changing the default property of the node translate modal operator. So for example they can make Shift key to opt-out of auto-offset rather than opting-in.
- At the same time we gain this flexibility, we can also remove the auto-offset from the node editor UI. The changes which add flexibility while at the same time removing UI elements instead of adding them are the best ones. It’s same great feeling as adding a new functionality or improving the existing functionality of the software by actually deleting lines of code
The only small drawback is that the Shift key is currently reserved in the Node Editor for reducing sensitivity of the node translate operation. But I don’t think anyone has ever needed to use that for node editor
1 Like
Agree that’s a good solution. It’s not even a compromise !
I like the idea.
Not sure about giving it a such a prominent role as ‘shift’, though.
Also to me that doesn’t sound like “never” toggling it but “always” toggling it when you want to use - or disable - it. Though I do get how that is good because it allows to build muscle memory and it prevents you from accidentally using/not using it, having to undo and the redo the action after toggling it.
On the other hand we already have the ‘T’ shortcut to toggle the auto-offset direction during transform. Maybe that could cycle through ‘Off’, ‘Left’, ‘Right’ - rather than ‘Left’ and ‘Right’? Or even just toggle it ‘On’ and ‘Off’. Despite using auto-offset regularly I never touch the direction toggle.
But I think we’re all on the same page about wanting something that is basically an operator property to be gone from the menu.
I’d say it may be best to avoid wrapping three scenarios into a single hotkey, instead keep the toggle and the direction separate. It’s a modal keymap, we have pretty much the entire keyboard at our disposal I believe ?