Testing Wanted for Joining Nodes Into Frames

Feature & Design Feedback
1

I’ve been experimenting with improvements to joining nodes into frames when transforming them with the aim to indicate the behavior better and maybe make it a bit nicer to use.

NOTE: The proposal in this opening post is out of date at this point.

The current state of the patch is described here:
Testing Wanted for Joining Nodes Into Frames - #67 by lone_noel

A previous experiment removing parenting completely is described here:
Testing Wanted for Joining Nodes Into Frames - #48 by lone_noel

The patch itself can be found here:
#105457 - Node Editor: Improve node joining during transform

Proposal

Improve the frame joining feedback during transform by:

  1. Choosing the frame based on the position of the transformed nodes rather than the cursor.
  2. Highlighting the frame to be joined during transform similar to how it’s done for node links.

Additionally change the way the Alt key during transform works:

  1. Press Alt to enable link insertion/frame joining. (Currently it disables it by default.)
  2. Enabling frame joining when pressing Alt also detaches the selected nodes from their parents.

Unparenting nodes before frame joining is enabled eliminates edge cases that might make the frame joining not work.
Now all transformed nodes can always be joined into the indicated frame. So it also allows to easily drag’n’drop nodes out of or between frames.

Having the attachment be disabled by default has some advantages on its own (see: Proposal: Addressing Geometry Nodes UX Issues) but in context of this proposal it also reduces the drawback that the preselection highlight adds more visual noise by only activating it when you explicitly want to attach nodes.

For some more details about the motivation or a possible alternative approach you can check the description of the PR.

This is what it looks like with this proposal, but I encourage you to try it to get a feel for it:

Your Feedback

Feel free to comment on everything you notice while testing, but here are some things I’m curious about:

  1. How do you feel about the hitbox area for the joining?
    Does it feel natural or at least predictable? Are there cases where you find it hard to pick the frame you want to attach to?
  2. Right now the frames keep their size when unparenting during transform. I found this a bit nicer than having the frames shrink the moment you press Alt. Or do you think having the frames update their size immediately would be better since it makes it more obviour what is happening?
  3. I think toggling link insertion and frame joining both with Alt is a good way to keep things compact. Does the Alt shortcut feel overloaded? Alternatively Shift could work nicely for frame joining and would be consistent with parenting in the outliner.
17 Likes
2

3

I’m not sure what to make of that video so a bit of context would be nice… :slight_smile:

Is there something that appeared not to work or that seemed like a bug? Did you just think the pattern of the highlight was fun?

2 Likes
4

No, just a video of a nice looking new feature :grin:

6 Likes
5

Oh, yes, please. Great idea. It feels like I’m wasting years of my life framing and de-framing nodes

1 Like
6

very nice feature, no more alt+P :slight_smile:

but upon testing encountered some problems:

1- Using “alt” for both frame and socket parenting creates conflict. If I want to drag bunch of nodes connected to each other to a frame using alt it detaches every socket in selected nodes. Maybe using shift for frames alt for sockets solves this?
(edit: just noticed when you drag then press alt sockets does not detach, so that might not be a problem)

2- When I drag a node to a frame it highlights when only more than half of the node enters the frame. I think it will be better as soon as it touches the frame it highlights, so we don’t need to drag the node all the way into the middle zone of the frame.

1 Like
7

Changing shift to parent/unparent frames could work. If I remember correctly @LudvikKoutny suggested the current usage of shift was pretty irrelevant in the node editor (precision mode or whatever it’s called), which I agree with.

8

yes, i think that will solve some conflicts. It is a very handy feature.

edit: actually there is no conflict. One needs get used to ;

alt+click = connects / disconnects nodes to/from sockets
click+alt = joins / detaches into/from frames

9

I would try to keep away from such nuances. I believe this is one step too deep in the keymap complexity. I’d rather remember “alt+click to disconnect nodes and shift+click to unframe nodes” rather than “alt+click to disconnect nodes and click+alt to unframe nodes”. Honestly the latter is pretty confusing to me.

I am aware disconnecting nodes already only works by alt+clicking, not by hitting alt once you’re already transforming the node, but I’d like to see that sort of discrepancy entirely disappear.

1 Like
10

True, shift+click makes sense to avoid confusions.

11

Would this conflict with shift-click when selecting multiple nodes?

12

hmmm, don’t know. Not a coder. But it is shift-click dragging, currenty it slows down the movement. I don’t think anyone uses that. So ı assume it can replace that function.

13

Ah, shift-drag, not shift click. My apologies, I misunderstood the suggestion.

Currently of course shift drag nothing, but if you hold the shift key and attempt to drag a group , it does deselect what you have selected. So obviously we would not want that to happen.

1 Like
14

Thanks for testing. Getting opinions on these specifics is very helpful!

I see your point - especially for one node it seems to make sense.

But what about when several nodes are selected? Did you find basing the selection on the center of all selected nodes to be fine in that case or would you still prefer to have it select a frame as soon as any selected node touches it?
I didn’t find the latter to work particularly well, when the selected nodes covered a larger area (potentially multiple frames at once) since it made it made it hard to pick exactly the frame you want.
But maybe I’m optimizing for the wrong case here?

I could see making a special case for one selected node that uses the exact nodes bounds and only using the selection center for multiple nodes.

Regarding the Alt conflicts/overload. The thing that I’m definitely getting from the discussion is that it’s probably best if link attachment and frame attachment can be set separately in the keymap.
That way Alt for link attachment and Shift for frame attachment would be possible whatever the default keymap ends up being.

15

Yeah your case also makes sense. I don’t have a strong opinion here. But it is also difficult when dragging several nodes into a small frame it becomes a bit difficult to find highlighted position. And also it slows noddling process a bit. First you have to drag and drop node/nodes into frame where it highlights then you adjust their final position.

I have now gotten used to it but yeah, it created extra burden on my brain: shall I press alt first then drag or the opposite? :slight_smile:

Great work anyway, it will definately speed things up. Thanks.

1 Like
16

This is a good enough reason for me to try some more with having all selected nodes (or at least a close approximation) activate the frame to join.
Fiddling around to find just the spot to join with the frame isn’t great and you noticing it as an issue quite quickly means that it should be handled better. Hopefully we can get it to a point where you never have to actively think about it - where is just works.

It will have the issue with precicely picking a frame when overlapping a large area in some form, but maybe that limitation isn’t as big an issue in practice and turns out to be the better compromise.

I’ve been there!

1 Like
17

Could that be solved by making both options part of the transform operator modal keymap ? (=attach/detach node & frame/unframe node)

This way alt+click stays free for something else

18

Upon further playing around, I have quite gotten used to it. I think it is good as it is.

2 Likes
19

That is good to know!

That could make sense. I’d have to look into that but the way it’s implemented right now when pressing Alt and then dragging it just runs “Detatch Links” and then activates the modal “Move” operator.

20

I’ve used quite a few different software packages with node based systems over the years, and when it comes to frame management, nothing comes even close to Unreal Engine due to the simplicity.

You guys seem to be solving lots of issues related to hotkeys and muscle memory, yet UE is a living proof that these problems don’t have to even exist in the first place.

In UE it works extremely simply. As long as any node is fully enclosed inside of the frame, it’s part of the frame and moves with it. As soon as the node is moved outside of the frame, or only partially overlaps the frame, it’s not part of it and doesn’t move with it.

We are trying to solve the issues of explicit parenting, such as order of the operations to properly parent/unparent node to the frame or what the hotkey should be. But why not just step out of the box, and think about whether you even would want to have explicit parenting.

If you think what the node frames are, they are a visual and management aid to organize the clusters of nodes in situation where you still want to have direct access to them instead of abstracting them into a node group. So ultimately you want two things:

  1. To have visual aid that encapsulates and describes purpose of a given cluster of nodes.
  2. To have layout management aid of being able to move clusters of nodes as a single item around, without having to select them all first.

Given these requirements, if you ask yourself if you would ever want to have a node which is inside of a frame, but not parented to the frame, the answer will most likely be no. In fact when the node is inside of a frame but not its child, it’s in most cases just an error, because you forgot to parent the node to the frame.

So why even have this option? It’s just so elegant in the Unreal Engine. You:

  1. Never have to spend mental energy thinking about any hotkeys
  2. Never have to worry if you parented the node to the frame or not

Only small drawback is that you have to manage the size of the frame manually, so there’s no feature where dragging a node over frame expands the frame to encapsulate the node. But to me that’s very small price to pay for the simplicity and ease of use of node frames that require no hotkeys and no manual parenting.

7 Likes