Oh, you’re right, sorry. I was on the phone when I answered the last time, so I took the comment at face value, but didn’t check for myself. My bad
1 Like
Yes, I think there should be some depth based hierarchy. Essentially, in your example, moving the blue frame should move the nodes in the orange frame only if the entire orange frame is enclosed in the blue frame.
But to be honest, I think there will be more of these issues as a consequence we are still keeping the shrink option. If the shrink option didn’t exist, this can be much much simpler. The one simple rule would apply, that any frame containing nodes moves them. So both blue and orange in this case. Only the retention of the shrink features complicates things once again.
Yes, exactly.
I disagree. I think that would be extremely annoying. It would be very easy to unparent nodes from its top-containing frame by accident, if any frame that is visually containing the nodes can move them with no hierarchy considerations. Take the orange/blue frame example:
-
You have arranged the nodes to be children of the orange frame.
-
But since it’s an operation that still relates to those in the blue frame, you overlap them a bit (so it ends up like in the image above)
-
Then, for some reason, you have to make room and move the blue frame to the left. Here there would be a couple of options possible:
- A) you drag those nodes with the blue frame, removing them from their “main” frame (orange)
- B) you drag the whole orange frame with it
- C) you leave the nodes and orange frame where they are, losing the overlap between orange frame/nodes/blue frame, so it forces you to select blue and orange to move them together.
A would be just wrong, since then it would be a mess to manage what nodes are contained in what frame, they could be changing parents unadvertently all the time (and sometimes you wouldn’t even notice).
B goes against the main behaviour it’s being implemented by @lone_noel (which is, only when completely contained is considered a child).I think would bring a big inconsistency.
To me, C is the only one acceptable. Even when it could bring some (minor) inconveniences, it would be much more consistent and easy to manage.
It may be the case that the shrink option bring more issues, probably since it adds more complication. But the main issue in my view is the Z-hierarchy, regardless of auto-shrinking.
In any case, if the option for shrinking is brought to a pop up menu, I imagine my own workflow would be: not having frames auto shrink by default, and use the menu to toggle it explicitly, or even better, give it a shortcut to toggle it at will.
Then again, I may be wrong. It’s just my take on it.
2 Likes
You have gotten yourself into a messy situation due to not treating the frames as visual comments of the node based code.
You are saying “But since it’s an operation that still relates to those in the blue frame” but I am a bit curious what kind of mental gymnastics would you use to justify that. You have two nodes, spline parameter and group Input being in the blue frame, and also the orange one, but their output links clearly lead directly outside the blue frame and are very unlikely to lead into anything that is inside of blue frame.
So it would be really hard to say that they are somehow related to the blue frame. If they were, than whatever they output to would be part of the blue frame as well.
The behavior I described is how it works in UE which I have been using for about 4 years now, and I never had an issue with it. Every single time there were two frames which were partially overlapping each other, instead of one fully containing other, it was an error.
If you think of the frames as visual comments, they are kind of similar to text based code comments. You can have a class which has a comment, and then inside of it you can have a function which is also commented. The class fully contains the function and its comment, but you can’t have a comment that comments the entire class and only part of the function at the same time.
Having the comments as 2D shapes inside of 2D space does allow for some flexibility, but that flexibility is hardly necessary there. What you have here is a bit of synthetic scenario, so you are now trying to invent some monstrous overcomplicated behaviors (rules of which will once again be offloaded to users mind, reducing the usability of the frames) to fix something that’s unnecessary in the first place.
The clear solution to your image is to simply hover over the right edge of the blue frame, and resize it outside of intersection with the orange frame. Or if the nodes in the orange frame really have something to do with the blue frame, as in that their output somewhere terminates inside the blue frame, then whatever rest of the orange frame is should be fully enclosed in the blue frame.
So ultimately, you are inventing the same problem we are solving. We are in the process of solving the problem that manually parenting nodes to the frames is a solution to a problem that never existed. Users almost never wanted to have a node fully inside a frame but not be affected by the frame. So we are removing manual parenting now.
Overlapping frames are pretty similar. Most people will considering having two partially overlapping frames to be an error, or at the very least messy workflow. It makes sense to have smaller frames fully contained withing large frames, to describe some sort of hierarchy of node clusters. But having partially overlapping frames in terms of visual comments is like saying “Well, A is part of B but not really”, which has 0 informative value in terms of visually commenting your node based code.
Ok. I was taking that example because it was already in the thread and I thought it was easier to reference back to it. Those nodes are inside a hair asset group I was using to test it. I know that specific example doesn’t make sense. Sorry, I even thought somebody would make this very point, but I hoped it would be more understandable that I was just trying to use it as a generic example.
But I think my point still stands, because 1) I have seen people do just that for visual clarity. I personally don’t do it, but I’m aware of people that do. And 2) even if it can be just by accident, I think it simply shouldn’t be that easy to unarrange your node setup when there is a clear visual hierarchy between the frames.
So maybe this next example will make clear what I mean. Don’t focus on what the nodes are,please, they’re not the point:
This is what would happen in scenario A (bear in mind, shrinking is disabled in both frames). To me this is just wrong, mainly because there is a clear visual hierarchy that is not consistent with behaviour. Look at the frames, the orange is clearly on top, and to me it feels as if the blue frame is stealing a node from it.
2 Likes
Yes, I guess the point I was trying to make is that I’d find it very difficult, if not impossible to find a practical (non synthetic) scenario where having two partially overlapping frames is useful, in terms of communicating something about the behavior of the node network. If you want to communicate that two frames are somehow related, partially overlapping them would be quite a cryptic way of doing that. Much more clear way would be to simply fully enclose the two frames within another big frame.
So that you’d fully enclose let’s say “leaves”, “branches” and “trunk” frames inside the “tree” frame, instead of partially overlapping leaves, branches and trunk frames with each other, hoping that another user will understand that by the means of frames touching, they are related.
What you are doing in that video is intentional error. I do agree with you that in intuitively feels that the blue frame steals the orange frame’s node. But what’s important to realize here is that if we completely remove the concept of parenting, meaning that specific frames remembering their specific node children, then imagine the following scenario:
You move the blue frame to overlap the orange frame as you did in the video, but you don’t notice it, and keep working for another 5 minutes, forgetting what belongs to what.
After 5 minutes, you notice the issue but instead, you move the orange frame to the left. Should the orange frame steal the blue frame’s Geometry to Instance node? When you created the overlap, the Geometry to Instance node belonged to the blue frame, but keep in mind that since the parenting is removed, the nodes don’t remember what their children are, so by creating that overlap initially, you want the system to somehow magically understand that the join geometry node belongs to the orange frame while Geometry To Instance belongs to blue one, without the system being able to track the specific frame children.
Yeah, I see your point, the way I was rooting for would also mean stealing in that scenario, just the other way around. Well, I don’t know what to tell you, it sure looks difficult.
But if the final behaviour is as in the video, I think the visual hierarchy could be improved to indicate that it’s a co-parenting situation with no specific order. The semi-opaque colours indicate a behaviour that don’t follow what actually happens.
Anyway, I’ll sit back for now and shut up, I don’t want to muddle the thread with half-baked ideas.
Ok, new personal rule for myself - no replying at a very late hour, on my phone, on a critical point without sitting down at the computer instead of trying to rely on a failing memory.
Sincere apologies, it works as you’ve stated. I was remembering all of the “node stealing”, but not that I was letting go of the mouse.
So, having cleared that up - I’ll revert to my initial feedback on that. I don’t think one frame should be able to grab nodes from another frame in this manner. I actually realized it did this on accident when (yay for testing things) while resizing one frame (which crossed over another filled with nodes), and thought - wow, that will be a problem one day.
I think it should be considered that very frequently, node frames aren’t intentionally overlapping- it’s usually a side effect of adding a node. Your comment only considers intentional error; but this patch must also address un-intentional scenarios, and what I’m seeing in the video is a very common un-intentional scenario
No, quite the contrary. By error I generally meant something that user did not intend 
What I meant by intentional error in my reply was that he intentionally created a scenario which will commonly happen to users by accident. He just did it on purpose to illustrate a point. But it doesn’t make sense to create whole new advanced behavior in Blender’s frame handling code just for frames to behave better in scenarios which users will probably not want to get into in the first place
When the user gets into such scenario, they will probably want to fix the frame overlap instead of leaving it as is, and then relying on some advanced, frame prioritizing behavior code to read their mind and move their nodes exactly according to their expectation in those rare case of one node being contained by two partially overlapping frames.
Thanks for the feedback so far, guys. A lot of food for thoughts!
I’m not yet at a point where I’m super sure about where to take things from here, but I’ll try to give my thoughts on some things.
Node Stealing
This has been contentious and I can see why considering how different it is from the current behavior.
That being said, it’s inherent to getting the bounds of the frame to actually correlate with the nodes it affects (“What you see is what you get.”). So I’d still like to pursue this idea a bit further to really see where this goes.
Very valid point! If we show overlapping frames you kinda expect it to matter.
Maybe putting a stronger focus on the border and making the border always be on top, helps? Here’s a first shot to see what that could look like.
A few more variations of this idea.
The default theme would need to be adjusted since the dark frames don’t read well like this:
Maybe a stronger border?
If we should move forward with the no-parenting approach we definitely have to take a good look at visually representing the relationships clearly.
My general thoughts
I’ve been using the patch in the past few days and have been enjoying it so far. (With shrinking enabled by default - I personally find manually resizing the frame a bit bothersome.)
With shrinking enabled it doesn’t feel that different from what we have right now, but I found the ability to resize the frames to add nodes to them to be super nice (and this is only possible without parenting). It’s just very flexible to change the node-frame-relationship both ways.
This is definitely a new direction while the original patch was more of a “faster horse” type of deal.
Similar to what @LudvikKoutny mentioned I haven’t had trouble with node stealing edge cases in practice. But I’m very concious of the issues people have reported so far and am still in the process of organizing the feedback to think this through from more angles!
No harm done! (Well, you did give me a scare that I might have done something dumb…) Thanks for checking.
7 Likes
So it took a while, but I went through all the feedback and tried to come to some kind of conclusion. Thanks for all the participation, everyone!
Feedback So Far
If you’re interested, here are my compiled notes: Node Editor: Frames - HackMD
Though, I don’t think you’ll gain too much new insight, if you’ve been following this thread.
Overall people didn’t seem to like the node stealing issue, but did enjoy being able to resize the frames to freely add/remove nodes.
Next Experiment
To move the discussion forward, I’m now trying to see if there is a compromise that manages to avoid the pitfalls of node stealing while still giving us some of the nice things from the recent prototype.
Here’s what I came up with:
-
Keep the “one frame per node” (parenting) concept for now
There doesn’t seem to be an actual usecase to have multiple frames claim ownership of the same node, so why allow it. -
Always add (currently unframed) nodes to frames if they are fully inside the frame
This avoids situations where an (unframed) node is on top of a frame without being part of it for the most part. -
Allow resizing frames to add and remove nodes
This works with parenting as long as you accept that you can’t steal nodes from other frames doing this. -
Allow unparenting nodes during transform by pressing Shift
Since the feedback on using Alt was a bit mixed, I thought it be good to give this a try as an alternative.
The improvements to frame resizing (Increased hitzone for resizing, Space to move etc.) are still part of the patch.
You can test this version of the patch with this build:
Node Stealing
Is there still node stealing? To some extend, yes. Free/unframed nodes will be joined into a frame that is moved under them, but you won’t have to fear that framed nodes will be stolen by a frame that’s partially overlapping.
I hope that this is a good compromise.
Note: The logic for adding a node to a frame is a bit more nuanced to also allow nodes being added to frames when they are part of the same frame and so on. So “unframed” is just a shorthand for “node that won’t be stolen if it’s added to this frame”.
1 Like
On paper, sounds like you’ve made some great choices on solving the paradoxes of parenting. Downloading now.
1 Like
Wait, this looks good ! I’m downloading the build now. If I understand correctly there can’t be a situation where a node is on top of one or several frames but isn’t parented to any of them ? so no need for the visual aid/outline ?
OK, this is GREAT. 
The shift hotkey to unparent is a godsend, since I don’t have to reach for the “unparent” hotkey anymore. Node insertion as an opt-in (alt+click) is fantastic, it’s now possible to work in cramped areas without messing everything up. And there’s never the ambiguous case where a node is over a frame but not parented to it. It doesn’t seem like much, but in practice it’s many small mental burdens lifted off of me.
I’m very, very happy about this version. Thank you so much for working on it.
1 Like
This seems nearly perfect. One glitchy thing -
- Shrink: OFF
- Click LMB
- Select a node within a frame, it leaves the frame as expected.
- Move the frame, and that node now travels along with it.
This works as I believe is as expected:
- Shrink: OFF
- Click LMB
- Select a node within a frame, it leaves the frame as expected.
- Hold SHIFT, left go of LMB
- Move the frame, and that node now stays where it was dropped.
I can see that the SHIFT combo is of value, if Shrink is ON (as it appear to over-ride the shrink, for obvious reasons), but if Shrink is off, I believe SHIFT shouldn’t be required. So perhaps some sort of… if shrink on/then shift LMB req, else LMB ok … sort of thing.
-
If I resize a frame, such that it unframes a contained node, that node leaves the group as it should.
-
Node stealing seems to be completely resolved. It picks up orphans off the “pasteboard”, but I’ve no problem with that whatsoever.
-
Repeating, just because it’s great and I love it: the “click border” on frames, so much easier to grab than release build.
-
Overall shrink behavior (other than the glitch above) works well.
Great work, Noel.
2 Likes
Was about to comment, but more or less is the same, the only weird thing to me was what @thorn-neverwake is talking about (I noticed it with nodes and frames), because I tend to keep autoshrink disabled.
Other than that, I really like it. And I saw that in the HackMD doc there is a couple of ideas about further improvements (color and labeling I look forward to).
Very cool! Thanks for working on this, Leon.
1 Like
Re: Copy/Paste (duplication) -
Selecting the entire frame + nodes, then duplicating = intact copy as desired.
Selecting only the frame: it duplicates the frame, but not the nodes within.
Might be how it needs to work, but mentioning for completeness.
Dragging the edge of a node larger/smaller works 100% in affecting shrink size, no issues there.
FRAME COLORING:
Label of command is “copy color”. I did so, selected another frame, and expected to see a “paste color” option appear. Went back and forth a few times, wondering how to assign this color. Only when the tooltip appears, does the user figure out how it works. I think it may need a different label, as “copy” is a ubiquitous command in the world of computers and I think most people expect a “paste” command to be involved when offered the chance to copy.
Maybe “Apply Color to Selected Frames”…or “Assign Color”… or just “Apply to Selected”?
FRAME SELECTED command - still leaves a frack ton of empty space around the entire layout. Completely not within the scope of your work, but though I’d throw out a “while you’re in there…” 
I’m glad that this version seems to be on the right track!
This is how it was supposed to work, but I made an error when updating the parenting state. Have it fixed on my end. Thanks for testing and reporting, @thorn-neverwake and @txo!
It has worked this way for a long time and I’m not sure copying the frame’s contents is always desired.
What I could see working nicely is an easy way to select a frame together with all its nodes. I would really like to just double-click a frame for that but maybe there already is an established design-paradigm for that somewhere in Blender.
I’ve never used that and agree that the naming is confusing. It seems the only reason for it to exist is that the “Copy to Selected” operator only working on nodes of the same type.
Maybe “Copy Color to Selected” would be more clear and also in line with “Copy to Selected”?
I’ll add it to the list of things to look into
For the most part, yes.
The way it works right now is that it updates the parenting states after moving nodes and after resizing frames.
I’ve noticed a few cases where this misses something but those are easily fixed.
One case that I’m inclined to keep that way is, when the frame grows because the size of its child nodes changes. Since currently the parenting isn’t updated immediately there is a moment, where nodes can be overlapping the frame without being part of it (until the next time any node is moved or resized).
The reason why I think this might be desirable is, that it allows unhiding big nodes to expose more inputs without having to worry about it immediately absorbing adjacent nodes into the frame. Here is how that looks and I could see it being annoying:
With the current rules those nodes below would not become part of the frame until a node is moved or a frame resized. So making the group input node inside the frame smaller again would also return the frame to it’s original size (unless a node has been moved or a frame resized).
Not yet sure if this is just inconsistent or cleverly aligns with what most people would want. Making it consistent is simple though so it’s just a matter of deciding what behavior is preferable.
Since this is not necessary for this patch to work, anymore, I think this will have to be discussed separately.
To me it makes sense for this to be opt-in rather than opt-out but ideally we’d be able to actually customize the modal keymap. I’m certain there are people that prefer the link insertion to be on by default.
2 Likes
Not as far as I know, however I read people wishing that such a thing would exist for object hierarchies before.
Makes sense to me !
That’s how it worked when I tested your build, opt-in. I had to hold alt for the node insertion to happen. I may have changed the keymap for this, I’m not sure. But at least it means it can be changed
1 Like
Yeah, I hadn’t reverted that change from the original patch. I’m just trying to set expectations since it won’t be bundled with the frame changes.
From what I understand the modal keymap can’t (easily) be customized. So for the most part you’ll be stuck with whatever is the default, unfortunately.