← All ideas
  • Published 17 Oct 2020

Drag noodle in node editor should pan at edges, feature request.

Normally node editors has a way to pan around after having grabbed a noodle. Blender would benefit from this. I think it is of high importance. It would work this way : Grab a noodle. Move the mouse to the edge of the editor. When the mouse and the noodle are within 20-30 px of the edge the view starts panning ever so slowly. Done correctly the noodle will never leave the view. A good example of this working flawlessly is unreal editor - just to give some inspiration.

100%

Development Status: Done

Upvote 44 Downvote 0
andreasng
17 Oct 2020

16 Comments

dustractor

something like in GIMP how the spacebar temporarily enables the hand tool would be good.

1
IIIFGIII

+1 Only problem - in Blender moving cursor to window border during transforms teleport it to opposite border what allow continuously dragging. Enabling auto pan conflict with this feature.

1
Draise

* @IIIFGIII * A hot spot, and crossing the edge are two areas for the mouse - so it wouldn't really conflict. Only if you cross the edge would it teleport. If you keep it in the hotspot at the edge, then pan.

IIIFGIII

* @Andres Stephens - Trinumedia * To achieve border it need to go through panning area. But in some cases user may just want to cross border with no auto pan jiggling ( eg. move some huge node bunch in zoom in case). It may work via some key modifier maybe? Some hold Alt while transform?

Lauloque

Plus I think there are cases when there is clearly only one action possibly needed. Each time you drag'n'drop a container, a form of data, or something to make some form of link between things, you need sliding edges.

But I guess it's simpler for everyone to just have some hotkey for that and let the user do his jam.

Draise

* @IIIFGIII * gah, another hotkey? If you have a 0.2ms wait on the hotspot, then it will loop. It's enough to cross the hotspot if trying to hit the edge. Like any software, you have time delay before it drags on the edge. You can quite easily have both without a hotkey.

IIIFGIII

* @Andres Stephens - Trinumedia * Speaking of other software I like how it work in UE. User can move cursor even out of window border - panning speed depend of cursor position. But in same time I like how in blender cursor teleport when border crossing while transform.

Delay solution is not the best - some pople move cursor sometime slowly (especially when hard thinking... ) , so user can get all the time not wanted panning. From other side - people who want to work "fast as lite" (like me sometime) will have to wait this delay instead of " just do it " and it will work like sotr of lag...

My solution (modifier hotkey) not the best too - not work in case of doing something " one hand " (I do so when I'm too lazy and it just need to move nodes )

MMB is already used for constraint so some combination lake LMB+MMB to move/pan not work. Maybe better to implement it this such way:

  • if user start pan ( MMB ) with cursor on canvas, he jsut pan as obwious
  • if user start panning on node - he do move node/pan ( + speed depend from " cursor to border " position)
1
Draise

* @IIIFGIII * Teleporting is nice for changing values yes.. but it shouldn't be a thing when dragging nodes to the border. It could be context activated instead of delay and hotspot. You are right. I prefer UE4 workflows I agree. A lot of other software do this also. It would be expected behaviour. If you're dragging on a slider and it teleports, it would make sense to keep on teleporting.. but dragging a node to the border should pan/drag it.

In general, I prefer only Lclick to do things, and have it context biased. Any hotkey or extra mouse keys for extra functionality when it could just be context based on where you first click should be the general UX of everything.

andreasng Author

* @IIIFGIII * I don't understand why I would want the cursor to ever teleport while dragging a node? Can you elaborate?

IIIFGIII

* @andreasng * Why I have to know why you may want or may not? Pffffff....

But if I try to imagine - you may want it if your window is spllited by many different editors and Shader Editor window is small. So if u need to move some huge selection of nodes and in same time not zoom out to outer space each time you want to move it more than your window size allow you - this feature will help.You may need it when move in precise mode, when cursor go further more than node. Et cetera...

What I can tell you for sure - this feature will not be cut out from Blender ,want you or not, so features have to live somehow together.

andreasng Author

* @IIIFGIII * but when it teleports at the top (for example) it goes to the bottom. Which is not where you want the node. Cus then you would drag it down I think. I'm sorry if I came off hostile it isn't my intention. I'm simply asking you in which situation you would want the cursor to teleport WHILE holding a node or a noodle?

And your example is exactly the situation where you would not want it to teleport, but rather pan.

IIIFGIII

* @andreasng * "but when it teleports at the top (for example) it goes to the bottom. Which is not where you want the node." Cursor... Cursor, to allow it to continue going across same window, not node...

andreasng Author

* @IIIFGIII * I get it. Lol at Picard. Great conversation we have. :) I think your examole is quite staged. Imagine if you clicked at the node at the other end of your selection. Which is the end that you are actually interested in connecting anyway. Then teleporting the cursor would be useless. In contrast to panning which would make it possible to navigate while holding nodes/noodles. That's basically what it all boils down to. It is far superior to have a control scheme which let's you navigate while holding onto things, than a control scheme which just doesn't. Don't you think?

h.goudey
slowk1d

This feature is finally in the current alpha master! I'd say we can mark this as done.

andreasng Author

Right now we either have to frame the two nodes we want to connect, which means zooming way out in some cases. Which in turn requires two snipes, one at the departure node and one again at the socket you want to connect to. The other way is to take departure node and move it into reasonable proximity of destination node. Connect. Then move it back. Auto scroll would instantly fix this issue.