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
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 ?
