Canonical way to hotswap the type of socket

[zeffii]

any example code with preferred approach? List repeater uses changable_socket, but would be cool to do something like self.outputs[0].changeto(VerticesSocket [,newname])

[nortikin]

yes, but without removing it should be alltogather socket type, i think

[ly29]

changeable_socket is the canonical way but it should be updated to be future proof. It should use .bl_idname of the socket directly instead of encoding it to "s", "m" "v". It could also reconnect lost connections.

[ly29]

Also input socket isn't needed, somewhat confusing StringsSocket is considered a generic socket.
Consider the difference between the following two approaches...

def get_socket_type(node, inputsocketname):
    if type(node.inputs[inputsocketname].links[0].from_socket) == bpy.types.VerticesSocket:
        return 'v'
    if type(node.inputs[inputsocketname].links[0].from_socket) == bpy.types.StringsSocket:
        return 's'
    if type(node.inputs[inputsocketname].links[0].from_socket) == bpy.types.MatrixSocket:
        return 'm'

def get_socket_type_full(node, inputsocketname):
   # this is solution, universal and future proof.
    return node.inputs[inputsocketname].links[0].from_socket.bl_idname

[zeffii]

i'm not sure I get it. Of course i can code the socket change and reconnect in the long form, as I did in early version of the List Range Int. but say I have a node with

self.outputs[0]     # StringsSocket 

and i want to cast it to a VerticesSocket, what's the lightweight way to do that.

[zeffii]

in changeable_socket, should the params be called more appropriate 'old_socket_type, new_socket_type`, or (as you point out) ignore the current socket_type and be

change_socket_input(self, name/id, new_socket_type [, new_name])
change_socket_output(self, name/id, new_socket_type [, new_name])

# new_name would be optional

[zeffii]

or

change_socket_input(self, name/id, new_socket_type, new_name=oldname, keep_links=True)
change_socket_output(self, name/id, new_socket_type, new_name=oldname, keep_links=True)

# new_name would be optional, it would use oldname
# keep_links would default to True, set manually to False if you have some reason.

[ly29]

Inputs socket of Stringssocket are considered generic. (this is highly debatable I think it should be changed). Therefore there isn't a need to change the type for inputs in the current scheme.

For output sockets I think name and sockets should be kept as stable as possible so I am against the name parameter change. (If needed we can supply a display name that can be changed.)

It also made for different scenario than you need, mainly for the list operations where one input socket changes type of many outputs. So I think it should be updated for handling the scenario. In List Match node I wrote the code for a different scenario. With n to n matching but I havn't extracted it and made it generic.

def change_socket_type(node, socket, new_type):
     if not socket.bl_idname == new_type:
          pos=get_pos(socket)
          name =socket.name
          node.outputs.remove(socket)
          node.outputs.new(new_type, name)
          node.outputs.move(len(node.outputs)-1,pos)

Something like that

[zeffii]

is the move just to trigger update?

[zeffii]

oh, .move is socket move?..

[ly29]

New sockets get placed last.
The move would update event nr 3 at least...

[ly29]

Yeah just a quick sketch... I wish move supported pythonic -1 indexing. We should suggest that to the developers also. Also keep the link collecting all connected sockets. Also when we change type here we might trigger a long series of type changes... Each causing a series of update events.
The re link could cause some problems until we separate processing and ui. After refactor this should be top priority

[zeffii]

#152 yeah. Maybe now is the time to stop adding new nodes and discuss that properly, I only have a vague understanding of how that should work. Will continue in other thread.

[nortikin]

I with Alex made stupid thing when called it StringsSocket
we discussed many, but lost this naming and type at all
Current sockets created when we studied sockets and nodes at all

[ly29]

Yeah, but since it carried the data in a string property it was logical at the time. Now we evolve :)