Improved spline visual behavior

[Half-and-Xat]

1. Splines visuals are mirrored now when start dragging from an input-port.
2. Improved math for splines.

Here a comparison:
SplineBehavior.webm

The motivation for spline math was especially the huge curve around the ports when dragging input nodes to the left. Now you can place a node to the right graph border and the other node to the left graph border and the curve is still okay. It also looks nicer when placing two nodes close together, especially with vertical offset.

[Half-and-Xat]

Ops the last commit should become an own request. I should check how to create separate once next time. Anyway, it just fixes a little bug where zoom-label-length mess up GUI-width between 99% and 100%.

[Lluciocc]

Ops the last commit should become an own request. I should check how to create separate once next time.

No problem, maybe you mean create a new branch ?

I will look at your code later

[Lluciocc]

You code looks good but I think the spline feel too much like an "S", the curve of the spline feels like it go backwards and then go back to the node

[Half-and-Xat]

I was doing it as a trade off and the question is what kind of trade off we want to apply. I tend to agree with you. To me it is not so much about going backwards, but the read-flow itself could be better with less S-like behavior.

The trade of is that when a node is in the position like Start to IF condition on screenshot below the S-bow (see arrow) becomes shorter at first and when moving the Start further to the right, it grows again until it has the size of the upper image. That looks a bit unnatural on movement and while it looks okay, the upper image looks better in general at this specific spline-state.

I watched a lot of people using Unreal Engines Blueprint system and many of them placing nodes (especially data nodes like variables) in this way. Personally I do not, but it is a common behavior in general. So it is still a case that will happen more often than you probably think.

More complex math could maybe fix this, but I don't think we should do it. The visuals are still fine enough to me. If you agree, I'll push this little fix.

[Lluciocc]

I was doing it as a trade off and the question is what kind of trade off we want to apply.

I mean, the second one on your screenshot looks cleaner than the first one.

That looks a bit unnatural on movement and while it looks okay, the upper image looks better in general at this specific spline-state.

I agree that in this specific case, it actually looks much more natural. However, in the upper image, when two nodes are next to each other, it looks weird

More complex math could maybe fix this, but I don't think we should do it. The visuals are still fine enough to me. If you agree, I'll push this little fix.

I think we can find a middle ground here.

[Half-and-Xat]

If I import math functions I can calculate the distance of the nodes with math.sqrt() and replacing the max() part. The result is close to be perfect and feels natural. The math would be:

        d_str = math.sqrt(dx ** 2  + dy ** 2) * 1.35

        ctrl1_x = self.source_pos.x() + min(d_str, max(dx, pow(abs(dx), 0.8) + 250)) * 0.5
        ctrl2_x = self.target_pos.x() - min(d_str, max(dx, pow(abs(dx), 0.8) + 250)) * 0.5

What do you think?

[Half-and-Xat]

Preview to the sqrt() solution:

[Lluciocc]

This look way better than before.