Remove unavailable sockets and links #104126

New Issue

Iliya Katushenock · 2023-01-24T22:53:41+01:00

Iliya Katushenock commented

2023-01-24 22:53:41 +01:00

Yes. Finally, hiding some interface elements will not have business functionality and a bunch of complications in the code.

More about the problem:
The hide (in interface) and unavailable (for processing) sockets is now used to hide the visible (used) list of sockets.
This has consequences:

All sockets exist all the time.
Links to them still exist.
It is not possible to create new sockets without code complexity (previously, for node groups new sockets are created manually in some code places).
And this brings a lot of complexity to the code.
Just examples: D16784, D16772, 2b4cb893e7, ...
And trubbls for python users: #103395 (Node: Incorrect node socket indexing when connecting with python)

The main task:
At the moment, this problem can be solved in several parts :

Different sockets for different node configurations:
a. Group nodes create their sockets based on node tree declaration: D16850.
b. Individual nodes create a statically assigned set of sockets depending on the state of the node: D17081.
c. Nodes for working with multiple data layers (shaders, compositor): based on scene data or some other data. There may be subtleties here. Example task: #70802.
d. Physics Nodes: Based on what data should be stored in the simulation.
Support for multiple types on a socket as generic socket type:
a. Argument list of supported types for socket declaration.
c. Type of socket declaration, that mean evaluation-time type of socket based on context (similar to template node groups)

Also, since the constant deletion and creation of sockets has its consequences, some behavior needs to be recreated. Now it will have more control, which in theory should improve usability:

Simulating data storage for a temporarily remote socket D17136 :
a. It is possible to store data of node group sockets.
b. Value conversions when changing the group socket type.
Handling implicitly deleted links for their possible return to their original place.

Code cleanups:

The result of a complete switching to explicit processing of real sockets may be the complete removal of visibility flags for sockets. Or at least move them to the category of deprecated.
As well as the complete removal of the code that processes them.

Yes. Finally, hiding some interface elements will not have business functionality and a bunch of complications in the code. **More about the problem:** The hide (in interface) and unavailable (for processing) sockets is now used to hide the visible (used) list of sockets. This has consequences: 1. All sockets exist all the time. 2. Links to them still exist. 3. It is not possible to create new sockets without code complexity (previously, for node groups new sockets are created manually in some code places). And this brings a lot of complexity to the code. Just examples: [D16784](https://archive.blender.org/developer/D16784), [D16772](https://archive.blender.org/developer/D16772), 2b4cb893e7, ... And trubbls for python users: #103395 (Node: Incorrect node socket indexing when connecting with python) **The main task:** At the moment, this problem can be solved in several parts : 1. Different sockets for different node configurations: a. Group nodes create their sockets based on node tree declaration: [D16850](https://archive.blender.org/developer/D16850). b. Individual nodes create a statically assigned set of sockets depending on the state of the node: [D17081](https://archive.blender.org/developer/D17081). c. Nodes for working with multiple data layers (shaders, compositor): based on scene data or some other data. There may be subtleties here. Example task: #70802. d. Physics Nodes: Based on what data should be stored in the simulation. 2. Support for multiple types on a socket as generic socket type: a. Argument list of supported types for socket declaration. c. Type of socket declaration, that mean evaluation-time type of socket based on context (similar to template node groups) Also, since the constant deletion and creation of sockets has its consequences, some behavior needs to be recreated. Now it will have more control, which in theory should improve usability: 1. Simulating data storage for a temporarily remote socket [D17136](https://archive.blender.org/developer/D17136) : a. It is possible to store data of node group sockets. b. Value conversions when changing the group socket type. 2. Handling implicitly deleted links for their possible return to their original place. **Code cleanups:** 1. The result of a complete switching to explicit processing of real sockets may be the complete removal of visibility flags for sockets. Or at least move them to the category of deprecated. 2. As well as the complete removal of the code that processes them.

RedMser commented

2023-01-25 15:05:02 +01:00

As a user, will the "Toggle Hidden Node Sockets" (Ctrl+H) feature be impacted by this in any way?

Iliya Katushenock commented

2023-01-25 15:14:32 +01:00

This implies removing the functionality to hide sockets. That is, if the socket can be hidden, it will simply be invisible. But yes, I was a bit inaccurate. Hiding just unused sockets SOCK_HIDDEN and functional hiding SOCK_UNAVAIL can be misleading.

This implies removing the functionality to hide sockets. That is, if the socket can be hidden, it will simply be invisible. But yes, I was a bit inaccurate. Hiding just unused sockets `SOCK_HIDDEN` and functional hiding `SOCK_UNAVAIL` can be misleading.

Iliya Katushenock changed title from ~~Remove hidden sockets and links~~ to Remove unavailable sockets and links

2023-01-25 15:19:46 +01:00

Iliya Katushenock added

Meta

Good First Issue

and removed

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Remove unavailable sockets and links #104126