[Bf-committers] Python Access to some properties of nodes

[Brecht Van Lommel]

I think it's fine to add those few lines with the link function to
release/scripts/modules/bpy_types.py, there's a bunch of similar
utility functions there.

Brecht.

On Thu, Dec 20, 2012 at 12:50 PM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
> I don't say we should not have these properties, i know they can be
> very useful! I just don't want to have this stored in the DNA data,
> because it is always secondarily generated from "actual" links and we
> then need to ensure it is kept updated properly. Adding this just as a
> API function which then uses the node tree links list and returns a
> temporary list would be totally sufficient.
>
> Only question imo is whether to add it in the RNA itself or just in
> Python. For scripting in py this won't make a difference, i just find
> Python to be a lot easier for stuff like this. In makesrna C code
> returning such a collection is difficult (if not impossible).
>
> On Thu, Dec 20, 2012 at 12:27 PM, Bartek Skorupa (priv)
> <bartekskorupa at bartekskorupa.com> wrote:
>> Thank you Lukas.
>> In a nutshell it means that it's better not to add those properties to sockets right?
>> Without going deeper into it I'd say that it's not a big deal working the old way or use your suggestions.
>> I only said that it would be easier if we had such properties, but it seems that adding them could make other areas harder to maintain.
>> If so, I can live with that.
>>
>> Thank you again.
>>
>> Cheers
>> Bartek Skorupa
>>
>> www.bartekskorupa.com
>>
>> On 20 gru 2012, at 11:30, Lukas Tönne <lukas.toenne at gmail.com> wrote:
>>
>>> Slightly nicer: define 'links' as a property instead of a method:
>>>
>>> class NodeSocket(StructRNA, metaclass=RNAMeta):
>>>    __slots__ = ()
>>>
>>>    @property
>>>    def links(self):
>>>        """List of node links from or to this socket"""
>>>        return [link for link in self.id_data.links if
>>> link.from_socket == self or link.to_socket == self]
>>>
>>> On Thu, Dec 20, 2012 at 11:10 AM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
>>>> In the bNodeSocket DNA we currently have a sock->link pointer which
>>>> directly points to a bNodeLink. However, this only works for input
>>>> links with the current connectivity model (input only has one possible
>>>> link, outputs can have many). Future nodes can use a different
>>>> connectivity model, then this pointer would be pretty useless. Also
>>>> this pointer is not totally reliable in all cases, e.g. can be invalid
>>>> during node updates. For this reason i would discourage using this
>>>> pointer and always use the nodetree->links list to find connections
>>>> from/to a specific socket. Eventually i'd like to remove the
>>>> sock->link pointer as well to make maintenance easier and remove a
>>>> potential error source.
>>>>
>>>> For getting connections of a socket i would instead suggest to add a
>>>> number of python methods to the NodeSocket class (can be done in
>>>> bpy_types.py). With python this can be done very nicely:
>>>>
>>>> class NodeSocket(StructRNA, metaclass=RNAMeta):
>>>>    __slots__ = ()
>>>>
>>>>    # returns a list of links to or from this socket
>>>>    def get_links(self):
>>>>        return [link for link in self.id_data.links if
>>>> link.from_socket == self or link.to_socket == self]
>>>>
>>>> If necessary such functions could also be added to the RNA directly.
>>>>
>>>>
>>>> On Thu, Dec 20, 2012 at 3:30 AM, Dan Eicher <dan at trollwerks.org> wrote:
>>>>> Assuming Campbell's OK with it it wouldn't be too terribly hard to add
>>>>> something like Socket.link to push the iterating over the links into C
>>>>> since IIRC that's how it works internally.
>>>>>
>>>>> I personally won't have time to mess with it until after New Years but if
>>>>> someone else wants to bang their head against makesrna and node tree
>>>>> structs it might turn out to be as simple as wrapping an existing function
>>>>> (though I do seem to recall that the node links were a little tricky to
>>>>> wrap originally).
>>>>>
>>>>> Dan
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers