[Bf-taskforce25] RNA structs for UI grouping?

Vekoon vekoon at gmail.com
Fri Jan 9 20:40:01 CET 2009


I always thought of rna structs as kind of a "type" information (and is 
indeed said so in various contexts), where their listed properties 
indicate the properties supported by that type.
So does it make sense to have types defining a parent? I'm still digging 
into RNA but if I'm not mistaken you mean that RNA_Object should be 
considered parent of RNA_ObjectGameSettings?
My concern is that parenting generally describes a situation where 
children's definition rely on the parent being defined, which is not 
really true for the case above as RNA_ObjectGameSettings does not need 
RNA_Object being defined in order to be defined itself as it doesn't 
inherit anything from it.
Although they're clearly related to one another what they describe is 
not a hierarchy relationship between the physical types but the relation 
in which the properties of those types will be found. Basically it's 
just saying RNA_Object will have a property of type 
RNA_ObjectGameSettings, which is not really a parent-child relationship 
between types which is indeed already defined by the "from" field in 
StructRNA.
In my opinion doing so just for the sake of documentation is forcing 
structs into something they were not really thought for. I could be 
wrong though.


Brecht Van Lommel wrote, on 09/01/2009 14.45:
> Hi,
>
> On Thu, 2009-01-08 at 10:53 -0800, Campbell Barton wrote:
>   
>>> This is something I considered but I think doing this has some problems...
>>> any struct that has 1 point of access is assumed a nested struct, but
>>> if for some reason a second access point is added, the docs will
>>> change (breaking bookmarks/links - not THAT bad, but not great)
>>> If member 'FOO' happens to have 1 user and 'BAR' has 2, they will end
>>> up in different places in the docs too, even if both aren't nested
>>> structs.
>>>
>>> It also means you cant tell from the docs which structs need NULL checks.
>>>
>>> --
>>> - Campbell
>>>
>>>       
>> Brecht, would it be ok if I look into adding some check for nested structs?
>>     
>
> OK, an extra "parent" struct pointer or so to organize the
> documentation is fine I think.
>
> Brecht.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>   


More information about the Bf-taskforce25 mailing list