[Bf-taskforce25] Moving RNA Struct inheritance to iteration time

[vekoon]

First a note on the ray_mirror_ prefix. I'm not quite sure that adding 
nested structs is that better then having longer names. As I said on 
channel I think this has the advantage of making names shorter but the 
disadvantage is that you have to subtype something that is not really a 
type. This means that accessing it on the fly is easier, but accessing 
it in a unique way becomes harder in the long run (e.g. when storage is 
involved). For instance if you want to remember a bunch of material 
properties for an object you'll save their names and values like in an 
associative array. When you, as a user, see a texture, you know it's a 
link to another thing that exists on its own and it's pretty clear that 
you can't save a single setting for the texture at the material level 
because you access textures separately and modify their settings 
globally (which is reflected in all materials that use that texture), so 
you're gonna save something like "tex[0]" -> "tex.001". Now, again as a 
user, you see a bunch of ray mirror properties in the material settings 
as you can't separate them from their material because they're not a 
different type, like it is instead for textures, and indeed if you 
change some ray mirror settings they'll only affect that single material 
so if you want to save some of them you'll have to memorize a path to 
them that has to be calculated and although there's API for that it's 
not about the additional work but the fact that you introduce an 
exception to the whole system just to have some name shortening which 
I'm not quite sure is a good idea. In my mind structs should be confined 
to type definition only so that you, as a plugin/python developer, know 
that names for properties directly attached to a certain data are unique 
and avoid exceptions which in my experience are always bad for 
developers. Hope I make sense.

About the other thing, we're not really solving this at the RNA level 
with groups. All groups do is separate properties more logically by 
grouping them and all the attributes for groups are really generic and 
not UI specific. For instance the group type is something that defines 
what kind of properties you'd expect in a certain group, in what order 
and what's the 'meaning' of them. All of this is not really UI specific 
but just gives you a 'lot' of meta information on RNA that in the end 
can also be used for UI.
For instance a group type is like "GROUP_FLAGS": this informs you that 
the group will contain a series of flags that enable or disable some 
specific features, but this same information I use to generate UI in my 
demo implementation of AutoLayout (which is probably a silly name by the 
way but can be changed) for groups of properties like layers, draw mode, 
draw extra ecc all its generated only based on these information and 
some UI paradigms (and these are the paradigms that will be discussed 
upon later for UI design and they indeed can be changed).

Better if I take advantage of this mail to explain better how my code is 
separated because on chan ton was confused about what I was doing and 
maybe I explained it badly (or not explained at all).

There are three levels of separation in my implementation. The first 
level is represented by RNA groups which are just meant at grouping and 
thus giving more shape to RNA properties. Groups in this case are just 
an overlay of RNA-specific meta-information, i.e. they don't represent 
nor provide access to any data or lower level information, they're 
basically RNA for RNA.

The second level is aimed at creating an easier and abstracted access to 
RNA groups in a more possibly efficient way. The need for this comes 
from the design of groups itself: groups are simply attributes for RNA 
properties, you don't "add" properties to groups as you do with structs, 
you just associate a group information to every property. This gives you 
a lot more flexibility and also makes the API easier.
The problem with this is that, in most contexts (like UI), you'll need 
to access properties by group in order to group them (seems obvious). Of 
course in a tree-like structure you could do as I did for the outliner 
but I did this way with the outliner just to change the less than I 
could outliner.c to avoid svn conflicts and make the code small and it 
was possible to do so because the outliner doesn't really require that 
high performance. Unfortunately this would probably be inefficient in 
most other contexts (like a possible properties editor).
So I concentrated into creating a cache for groups that would provide an 
easy and efficient access to groups and their properties. The good thing 
about this cache is that when you first create it you can associate any 
related information for every group that you put in the cache and this 
information can be used (and changed) later by other higher level code 
for various purposes. In the cache context you can think of a RNA group 
like sort of a unique identifier you use to refer to a specific cache 
element.

Finally, the third level of my implementation is just kind of a demo 
usage of the aforesaid cache in the form of the refactored buttons 
window (aka properties editor).
After I implemented the cache I needed somehow a way to test it out to 
see if it worked and how efficient it was. To make sure it was efficient 
enough I chose what I think is (or will be) the most performance hungry 
code that will be using the cache, i.e. the buttons window. This way I 
could also demonstrate that RNA groups were providing enough information 
for a good level of UI automation.
To show what I meant with associating related information to groups I 
added a field to the cache element (which as of now is called 
LayoutGroup, maybe not so smart as a name, can change of course), this 
field was an icon id to be associated with the RNA group the cache 
element was representing and added a function to retrieve a default icon 
for the group (that's called when the cache is created). In this 
function I have a series of "if/else if" that check for the RNA group of 
the cache element and returns an icon id (basically if 
(lg->data==&Group_Object) return ICON_OBJECT;) this way I had an easy 
way of showing up icons in the context buttons (that are created 
automatically so it was hard to display an icon for them). The same idea 
could be applied to associate for instance a pointer to a function that 
takes care of custom drawing when you don't like how the automatic UI 
system generates UI for a specific group. If you then add an API to 
change this function pointer, there you have a way to let python scripts 
draw their own groups or also customize the drawing of built-in groups; 
for instance, you want the layer buttons to have a different appeal? you 
can do it simply with a python script. Talking about customization, eh?
We could be worried that adding too much information to every cache 
element could be heavy on memory side but consider that there's one of 
these cache elements for every RNA group and there won't probably ever 
be more than 1000 groups which means ~4k (or 8, depending on arch) every 
time you add a field of information (unless this field it's a flag then 
you can just use a common int for all the flags). As of now the cache 
has to be at the screen level (it's still the old messy code) but when 
I'll refactor the API I think I'll be able to put it at the app level in 
the end as to avoid complications.


Brecht Van Lommel wrote, on 02/02/2009 8.49:
> Hi,
>
> Thanks for the patch! Will review and commit.
>
> Regarding what was discussed in the meeting, will repeat here in short 
> what was the conclusion for completeness. Splitting the storage for 
> inheritance is fine, I also need it myself for the C api.
>
> Groups are useful for organizing the RNA outliner better. It's not 
> clear yet however how this works with the nested structs (those get 
> rid of ray_mirror_ prefixes in python code, which does not seem a good 
> idea for groups to do as well). How groups would affect automated UI 
> generating is also not clear yet, if it is sufficient information, or 
> if we should not try to solve such things at the RNA level. I need to 
> think about this a bit more..
>
> Thanks,
> Brecht.
>
> vekoon wrote:
>   
>> Hi brecht,
>> as you agreed on channel about moving struct inheritance for properties 
>> to iteration time and because I had some time tonight I implemented it 
>> as to avoid you some work (well not much, depends especially on how many 
>> mistakes I made). Hope you don't mind. Here's the patch: 
>> http://vekoon.googlecode.com/files/rna_struct_inheritance_1.0.patch
>> Oh by the way, I grepped through the code in search for 
>> RNA_struct_defined_properties and noticed that no code uses it, which is 
>> good because now it returns only the properties that strictly belong to 
>> that struct.
>>
>> Also the patch is for others to try out if you have time. Although I 
>> tested it a bit, more testing is always better.
>> As a side note, now properties show up in the outliner ordered by struct 
>> inheritance so you'll always see (for instance) name and modifier 
>> settings before the properties specific for the actual modifier type 
>> which to me looks nicer than it was before.
>> _______________________________________________
>> 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
>
>