And that mode can have its own keyboard modifier shortcuts only for the duration of the mode. As soon as you release the node to end moving and place it, the shortcuts no longer do anything. So the Alt key being assigned to 3 button mouse emulation in node editor should not be in conflict with using Alt key to connect/disconnect nodes during the node move operator.
Also, according to the documentation, the three button mouse emulation already makes Blender shittier to use:
So even if it did not work with the alt key in the node editor well, adding one more thing into already a big bag of things that three button mouse emulation breaks should not be that big of a deal anyway.
I was thinking something like that too, but didnāt mention it since I thought it may add visual clutter? I donāt knowā¦an overlay? maybe expose the outline around the child nodes when the frame is selected? (although at that point thereās not much gain than to just grab it and wiggle the frame a bit. It would be better, but not by that much). I guess the optimal result would be evident without doing anything at all, but also not cluttering the ui
I really didnāt intend to sound like I was all for keeping it the way it is and I admit that, while in nuke Iām much cleaner with my layouts, I tend to be messier in blender just because only I access the file, even while in production. So I get you point.
I donāt have that strong an opinion in the end about the default auto-attachment behaviour. For me it works as is because itās really fast (I use the search option all the time and since Iām in the neighbourhood of where I want it to be, itās usually fine). And Iām ok with it specially since the alt modifier was introduced to prevent auto link (which drove me crazy). But setting itthe way you propose (alt for connect-disconnect) would also be fairly easy to use, so Iām ok with it either way.
First time I see that.
I mean - I know already that this mode prevents a lot of other things from happening but always found it to be a much superior way of navigating. Interesting to see that the documentation specifically says: āYeah, itās there but itās only designed to work okayish.ā Clicking the mouse wheel always seemed as a suboptimal navigation to me.
But that crosses over to a completely different discussion now.
(edit) - plus I now remembered when I was firing up Blender at home why I prefer 3 Button Mouse Emulation: Working with a pen tablet. Especially on a pen display.
Another issue for me related link-drag-search is that disconnecting a link from and Input socket with Ctrl still activates drag-search. While I can undertsand this behavior in some corner cases, I think the majority of the time when we want to disconnect, we donāt want to search a new node to attach automatically. Especially considering that disconnecting a link from an Output socket doesnāt activate drag-search.
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.
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?:
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.
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
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.
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)
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.
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.
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.
