When you shout into the abyss, nobody shouts back at you…
PROBLEM
SOLUTION
Hi, I’ll shout back!
I actually looked into this. For panel dragging I made an operator that can be used whenever something is being dragged for smooth scrolling in both axes. I tested it out for node dragging and it worked with one major drawback-- it didn’t move the node based on the region scrolling. This is because the transform system used to move the nodes doesn’t know anything about the region’s scrolling. So the tricky part is finding a way to get the information to the right place in a way that isn’t too hacky.
I know, that’s not a timeline for the feature getting implemented, but I haven’t forgot about it and I would like to work on this at some point.
In the mean time, if you weren’t aware, you can use nodewranglers tool of shift+alt right click drag. You can drag from node to node and specify what is being plugged into what. It can be helpful. Hope that helps.
I’d like to have a go at this. Do you have a branch with your previous approach that i might learn from?
My first goal would be the NODE_OT_link operator since that’s what i’m missing the most. I’ve had a look at how the outliner uses the VIEW2D_OT_edge_pan operator (based on comment here: https://blender.community/c/rightclickselect/lVfbbc/). Trouble is that the node system uses modal operators for dragging, while the outliner uses the drag&drop system that has specialized UI handlers IIRC. Blender does not allow multiple modal operators to run simultaneously, see WM_HANDLER_BREAK here: https://developer.blender.org/diffusion/B/browse/master/source/blender/windowmanager/intern/wm_event_system.c$2220
Does the transform operator already have built-in support for scrolling? Or did you find a way to run the modal edge-pan operator alongside it?
The edge scrolling for noodles works quite nicely. The node link operator has the advantage that it doesn’t need to feedback from the View2D to update the transformed object, it just draws the link based on current view rect.
I just copied the relevant bits of the VIEW2D_OT_edge_pan operator for this, eventually we might want to have generalized functions for this (add op props, init customdata, apply modal operator tick).
Great! Yeah, instead of copying, I was starting to split out the relevant pieces of the edge pan operator so you could call them without running a second modal operator. I’ll see if I can find those changes stashed somewhere, but I’m not sure how far I got.
But for this to be acceptable I think we shouldn’t just duplicate the edge pan logic, it should be shared.
The same idea basically worked for transforming nodes, with the added caveat that you need to add the distance panned to the transform delta. I’d have to think about that a little more about the best way to do that in a less hacky way.
A note about scroll speed and acceleration: The defaults of the edge pan operator don’t feel quite right for node editor scrolling, the max. speed is too high and the fade-in too long. I think these work well for stuff like text editors, spreadsheets, or the outliner, but in the node editor the distances traveled are smaller compared to the window size. A lower top speed and a snappier fade-in would probably work better.
Noticed another issue on a dual monitor setup with full screen Blender window on the left: The cursor can move out of the window into the 2nd monitor on the right side, but it can’t move outside the node editor more than a few pixels on the left side. So panning is fast when scrolling right, but slow when scrolling left. Not sure how that might be solved, perhaps it’s better to take distance from the inside edge of the window rather than expecting the cursor to move outside.
Yes, I added an “outer boundary” to only do the panning within a certain boundary outside the region. An “inner boundary” could also be added to apply the auto-panning starting at a given distance inside the editor.
And speed and fade-in could definitely be tweaked here.
Side note: this conversation would be easier on blender.chat if you’re there already.
I’ll hang out in the chat and see if i can catch you there next time.
I’d like to reformulate the speed calculation for panning a bit, to make it more easily configurable:
Currently the speed is ramping up linearly with distance from the edge. It has no upper bound (you can get very fast panning on big screens) and it is configured with the “speed per pixel” slope value.
I want to introduce a max speed value to keep panning speed within reasonable limits. In addition i want to define the slope in terms of the max speed and a “speed ramp” distance, over which it increases from zero to max speed. This is easier to define in UI units than a “distance per pixel squared” property.
