In the sister thread over on blenderartists we were having a similar discussion and ultimately came to the same conclusion.
It’s just much nicer if frames would be “what you see is what you get”.
This one I’m not sure about. The solution proposed over on BA has been that moving nodes on top of frames always adds them, but removing them requires the ‘Alt’ key and to me that seems like a great way to handle it.
This still doubles the complication I am afraid. You create different rules for adding them and different ones for removing them. It ceases to be simple and elegant.
The point here being that if there was no alt key removal, you can simply remove the node from the frame by moving it outside. If you are working inside of the frame, I don’t think it’s that annoying to have to resize the frame from time to time to make more space. I mean it’s not like you have to do it immediately. You can just work as you wish and only when you are done, drag one of the corners of the frame and cover the entire new thing you just did.
And once that is the case, internally, the whole concept of frames having any children, and whole concept of parenting in node editor can just be deleted. Frames would no longer store their children and nodes would no longer have any concept of having parents. Instead, every time user would move the frame, a simple function would check which nodes are fully enclosed in the frame and move them as well.
Losing the ability for frame to be auto resized when nodes are moved inside sounds like an issue on the paper, but after using many node systems for years, it’s just not an issue at all. What’s gained in exchange, deletion is substantial chunk of code (and UI elements/operators) aside, is also a very simple and clean unidirectional rule set:
Frames become just a thing in the node viewport you can create, name, color, move around and resize, and literally the only rule you need to remember about them is that if you move them, they will move any nodes they fully contain. But there are no other rules to remember.
I have to say I like the thought of not having to manage this parenting. I’ve never used unreal engine so this didn’t come to mind.
I completely agree with this. We already have the ability to have the frame automatically shrink to fit the nodes. Personally, I really don’t think I need the frame to grow and shrink if it requires me to use a hotkey modifier to drag nodes out of it.
I would rather just click on the node and drag out of the frame. If I need the frame to be larger, I can just click on it and make more space before I drag it in there. Or, I can drag the node to where I want it, and then click on the frame and drag it and make it large enough to enclose the new node.
However, I do wish the “click area” was larger, to manually adjust the frame size. I really have to zoom in there to find the magic pixel on the border.
I agree. Is the same in nuke, although the concept of nodes are very different because of compactness and it makes the step of fully placing the node inside the frame easier.
And also, one of the very annoying things to me the way the frames behave atm is that you cannot distinguish if they are parented or not just by looking at them. So I guess one extra benefit of having it being auto parented is that it eliminates the need for explicitly communicating if the node is a child or not (and creating more visual noise along the way): if it is inside the frame, it is parented. Easy and unambiguous.
Yes… if this was implemented the way I suggested, important part of it would be making the frame border more visible, easier to find with mouse cursor, and replacing the corner cursor image, which is currently incorrectly set to cross cursor with diagonal resize arrows cursor. 
I hacked together a prototype to test this new proposal, since I haven’t encountered this in practice so far. No modifier keys required:
I have to admit that even after playing with this for a while I don’t find it obvious that having to manually keep the frame and its children in sync is necessarily better than having the frame adjust the size according to its children, but if that’s the way the wind blows that’s fine with me!
We’re definitely losing some of that flexibility, but it looks so straightforward not having to manage parenting, it looks worth it to me. Thanks for putting this up so quickly. It’s much better to see it in action than having to imagine it.
I think the same. I tried to think of a way to maintain dynamic shrinking while also being able to simply move the nodes out, but these two just can’t live together without hotkeys or special rules.
Ultimately, I think simplicity wins. It also probably means more code can be nuked
really cool! 
Yeah, to me the biggest drawback in this kind of behavior is having to manage the frame size manually to make room to the nodes, because otherwise it will not be following the frame when you move it. It is the only thing that makes me unsure of it as a solution for Blender, because in Nuke’s case, nodes are so tiny that it’s very easy to make a little room to accomodate a couple new nodes (LudvikKoutny surely is more informed as to how much of an issue this can be, UE having also very big nodes)
Isn’t it tiresome having to make so much room to fit bigger nodes?
On the other hand, the biggest win (in my very much subjective opinion) is a draw between the auto parenting itself (the lack of shortcut) and how visually clearer is the hierarchy (it is really straightforward, as Hadriscus says).
The old way, you would have to either move the node to see if the frame resizes itself, or wiggle the frame a bit to see the parenting. And that can become infuriating when you forget and leave an orphan node behind.
Would that be such a compromise?
How about keeping this behaviour but adding the shift-drag that was talked about previously but for “move the selected nodes around, but keep them inside their respective frames (auto shrink)”?
I can’t speak for everyone, but the way I work, and I’ve seen other work is that you don’t really need to care about the frame in realtime in the same way you don’t care about neat arrangement of the nodes if you are prototyping rapidly. You usually make something, and then only after it works, you take a moment to clean up the node arrangement so the flow is more obvious. In UE, during this step I’d also just drag the frame to encompass the new part of the work I’ve done.
In fact, in unreal, the frames are called “Comments”, as in they literally mean that you are commenting your node based scripts. This implies that the frames are there mainly for you to remember what you did next time you open the file, or for the others to help them figure out the mechanics of your node graph.
But when you are creating part of the node graph, you are in the current mental context so you are obviously aware what part of the node graph you are working on. So for example if you are creating the part of the node graph which scatters the moss, you are aware you are working on the moss part, even if they frame you’ve labeled “Moss” doesn’t fully contain a couple of new nodes you’ve created.
So once you are done and the part of the node graph works, when you go ahead and clean up and align the nodes, you also take couple of seconds to extend the frame over them. You don’t need to wrangle the frame every single time you add a new node or move existing one.
Hmm, I don’t like the manual adjustment , let the children decide the size. I prefer the one in your patch.
Have you actually used it (I mean outside of the Blender bubble)? And are you sure you don’t like it more than you don’t like manual parenting chores?
You mean Unreal? no I haven’t. Maybe it is good.
Actually in Houdini both chidren defining the size and manual adjustment incorporated. Also you don’t need any keys for parenting. Dragging nodes to frame parents it, if you want to unparent faster dragging unparents it.
I am open to anything, all I am saying is children defining the size automatically is very handy, I don’t want to lose that.
How about this:
1- Dragging a node to a wire to parent and alt+dragging to unparent is already established, people are used to it. So same behaviour for frames? Dragging to a frame parents it. alt+dragging unparents it. No confusion.
2- Children defines the frame bounding box automatically but you can also adjust it manually.
The issue is that those hotkeys are running out really fast. And there are way more useful things to do with modifier keys during node transform than wrangling the frames.
For example see the discussion in the other thread:
Alt key during node transform already toggles whether the node is connected or disconnected onto underlying node links. So you can’t have the same key also do unparenting from the frame. The shift key is free (or rather isn’t but does quite useless operation right now), but even that one could be better used for toggling auto-offset on the fly.
Other software have smaller nodes (no exposed list of parameters), Blender nodes are almost always bigger (taller really) so they naturally require a bigger frame to be fully contained. Perhaps then we could change the rule slightly to make it so as long as the node header is contained, the node moves with the frame. Not sure whether that would be better, just a suggestion. It probably makes the thing less obvious visually.
It would just take more mental effort to determine which nodes will be moved with the frame and which won’t. Human brain can easily evaluate whether some objects are fully enclosed in some frame, but if the rule is also partial overlap, then you need to evaluate each individual node mentally to see if appropriate part of it is contained within the frame. It just wouldn’t be worth it.
I still think it’s important to think of frames as visual comments. In a sense that they don’t have any actual functionality which affects how the node (code) tree behaves. This means it’s really not necessary to have the frame always right size in realtime, so resizing the frames won’t be that frequent of an operation. You would usually do it after you are done building the node tree section.
Yea, you’re probably right. I was just leaving no stone unturned, but not completely convinced by my own proposal. I like this, though :
Not sure how good it is in practice. Houdini has a few “kinetic” actions like this, such as shaking a node from left to right to detach it.
But generally I like the behaviour from unreal engine you described, I’d like to test it if possible (in Blender).