[Bf-taskforce25] RNA structs for UI grouping?

[Campbell Barton]

Even though RNA_ObjectGameSettings could be defined without
RNA_Object, I dont see how this is relevant, since the api only allows
access to RNA_ObjectGameSettings from RNA_Object.
In DNA struct its not a parent/child relationship... but from RNA it
is (or nested property groups - or whatever, the term parent is used
loosely)

just adding a "parent" for any nested DNA struct is a bit wrong, since
the struct could still be used in more then 1 place. this isnt what I
suggested.

In the struct definition I wrote this comment.

	/* only use for nested structs, where both the parent and child access
	 * the same C Struct but nesting is used for grouping properties.
	 * The parent property is used so we know NULL checks are not needed,
	 * and that this struct will never exist without its parent */

An annoying side effect is now the structs are documented as...
rna.FluidSettings.FluidFluidSettings
rna.Object.ObjectGameSettings
rna.Material.MaterialRaytraceTransparency

Not much we can do about this, just the result of making global
namespace C struct names nested.

- Cam

On Fri, Jan 9, 2009 at 11:40 AM, Vekoon <vekoon at gmail.com> wrote:
> 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
>>
>>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>



-- 
- Campbell