[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