@Hans Goudey (HooglyBoogly) Thanks!

• Rearrange events checks.

• Changed UI as requested (talk in Blender.chat), to avoid dynamic UI and keep both sliders. Still a little hacky though. Also renamed all from 'lock' to 'link'.

• Requested changes applied.

In D10187#255101, @Metin Seven (MetinSeven) wrote:[[ URL | name ]]

Sounds good. I think it's important that the option to separate the viewport and rendering subdivisions is clear to the user, but to have the separate rendering value disabled by default, with the active lock.

The values would then always be in sync until you deactivate the lock.

If the lock is on by default (with a subdivision value of 1) that would be the most convenient to me personally, and maybe to most modelers?

If the lock would keep both values related to each other, that would make it slightly more convenient if you want to work with a consistently higher iteration for rendering. While the lock is active, you could increase the viewport iteration with 1, and automatically increase the rendering value with 1 as well, even if the value was already higher.

But... This does raise the question: what would the rendering value become if you change the viewport iterations from 1 to 3? So maybe your current approach is best: while the lock is active, both values are the same, and in unlocked mode, each value is separate.

In D10187#255058, @Metin Seven (MetinSeven) wrote:

Some elucidation:

• 9 out of 10 times I'd like both values to be the same. That means a lot of superfluous clicks while working with many subdivided objects.

• Cleanup redundant round operation

• I tweaked the gradient threshold a little so transition is not that heavy and not that soft - looking in a mid-term - around a 20% wider that previous diff.
• Also updated example (image) with a more realistic example (no impossible/weird cases as before) and also appended a video showing it in action.

In D9891#247174, @Brecht Van Lommel (brecht) wrote:

Personally I think all the new socket colors already too distracting (see my comment in T82689), and that this makes it even worse.

@astrand130 That would be for another patch, solutions are from changing colors to change style of the line as you said. For example, in the mock-up the invalid link is a stronghest red and with a 'X' in the middle http://ui.pablovazquez.art/ maybe more convenient.

Updated shader code to:

• Add a start-end threshold to compress gradient, this way original colors are better defined and data conversion through color transition is more clear and evident.
• Also fix a visual bug that was there but now was more evident with colored links that is gradient from start (coming from output socket) is around 10%+ longer than the other side.

Yeah, it's a quick hack but not the ideal solution (from root problem).

• Better indentation.

• Remove brackets in file not found description.

• Removed size in bytes.

• Followed tips and contribution from @Harley Acheson (harley) Thank you!

In T80384#1010294, @SavMartin wrote:

You have seen this development that is doing weeks ago??
https://twitter.com/jfranmatheu/status/1302237084191805441

In D8286#213267, @Brecht Van Lommel (brecht) wrote:

That seems like an artificial example, where you add a Principled BSDF node starting from e.g. a Normal Map node. And even then I don't think it's really an issue. Nearly all other nodes have only a few sockets, and even fewer output sockets which is what matters most.

In D8286#213093, @Brecht Van Lommel (brecht) wrote:

From a quick test of the patch:

• The position and size of the + icon looks wrong to me, especially when dragging from inputs. I'm not sure what will look best, but to me on the bottom right of the cursor seems like a logical choice.

@Brecht Van Lommel (brecht)
At the end I'm following this designs more less: https://developer.blender.org/T69441
Where '+' icon is in the upper right, BUT aligning it to the left for when dragging from inputs to avoid overlap with the node link. (alternatives to have it upper-right for all cases is use other color to make contrast or other shading like eg. with outline or supported with some background)

• Fix build errors.
• Unused vars.

Update patch:

• Now instead of using BLF and draw some text the new tooltip is a '+' icon. This icon is aligned to one or other side depending of which direction takes (is dragged from input or output). Later this will change to a cursor based on future new cursor system.
• Search Box is now aligned depending if you dragged from input or output.
• New node position is better as now is aligned to cursor position at release (before search box shows up) and depends if is dragged from input/output.

In D8286#210233, @Brecht Van Lommel (brecht) wrote:

I think "Add Node" text is too much, a more suble + icon seems more appropriate to me. Ideally that would be added to the cursor, though simply drawing the icon similar to the way the text is done now is probably easier to implement.

I think that too. A simple icon would be the best option.
Not sure how to draw an icon in C part though will be pretty much the same as when dragging from a color property field so I just need that part of code as reference and the icon to draw.