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 <[email protected]> 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) > <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
