[Bf-committers] New Developer Meeting Minutes

mindrones mindrones at yahoo.it
Mon Dec 7 23:14:04 CET 2009

Hi Campbell,

--- On Mon, 12/7/09, Campbell Barton wrote:

> Can this be a further summarized?

I've wikified the very cool RNA/Operators "lessons" you, theeth and dingto 
made at the NewDev meeting, see

Also, after the regular Sunday meeting theeth took the time to patiently 
list most of the Blender's code folders with a bit of introduction
for each one of them, see

While I was doing this stuff I've prepared a summary, which you can find
pasted below.

I'd like to thank again mentors for this NewDev Meeting, it has been very informative and cool :)

Cheers, Luca


NEW DEV MEETING 2009-12-06th

Mentors: ideasman42, theeth and DingTo
Log: http://blenderartists.org/~theeth/bf/meeting-newdev-09-12-06.txt

Agenda has been:

1. Decide if talk about 2.49 codebase or 2.5 only
2. Talking about C codebase or Python?
3. Mentorships
4. New devs interests?
5. Source code comments and documentation
6. General questions
  6.1 Blender architecture and how to grasp "the big picture"
  6.2 Finding things in the code
  6.3 RNA explanation
  6.4 Operators explanation

1. Decide if talk about 2.49 codebase or 2.5 only

  - We agreed not talking 2.4x code.

2. Talking about C codebase or Python?

  - majority wanted C, some C/python,

  - ideasman42 and theeth agreed that:
    - C/Python is very vague and it depends very much on where developers are
      interested in working, what problems they try to solve
     - also, in 2.5, it's not as clear cut as it used to be

  - ideasman42 asked if newdevs are more o C or python:
    - most are python/C or python with some basic C
    - one said to be C/C++

3. Mentorships

  - PapaSmurf asked whether experienced developers would like to mentor a new
    developer, like we did with GSOC: theeth showed interest :)

4. New devs interests?

  - kattkieru: armature and constraints systems, Python import/expoorter
  - amennelet would like to work on windows manager
  - djaddison: low level event handling
  - dmbasso/yoff: physics simulation, specifically muscle simulation -> Campbell
    answered this is too spesific area .
  - nfz: interested in "2.5 todo list and bug squashing"

  - Interesting note:
      <KAHR-Alpha>  isn't bullet C++?
      <ideasman42>  yes, but it has a C api. Not sure how effective that is though,
        only used the C++ api

5. Source code comments and documentation

  - matd would like to see important souce code files commented at the  beginning,
    in order to see what's a certain file for.
  - PapaSmurf and matd would liek to have _readme in each folder explaining the
    purpose fo the contents of that folder
    (at least in the root dir of all important modules like wm, rna, etc ...)

6. General questions


    - http://www.blender.org/development/architecture/
    - http://www.blender.org/community/get-involved/
    - (!!) theeth has patiently explained most of the folders in the code:
    - Ideasman42 suggestion: "Not sure this is GOOD advice, but I found its good
      not even to try understand the big picture, just learn one area well".
      Theeth agrees.
    - DingTo started with UI scripts, expanded to RNA and Nodes, nfz too.
    - General agreement about starting from UI scripts or operators (in files
      ending in "_ops.c").

    - Campbell asks how people searches in the code
      - cscope (kh_pylon)
      - code::blocks (nfz)
      - kscope, crep, http://wiki.blender.org/index.php/User:Ideasman42#crep (mindrones)


      RNA is a data access and simple operations API. It sits on top of the low
      level C structs (called DNA).
      It's very basic stuff, like links between different structures, specific
      types and range of different members, ...
      From that, we generate the RNA Python API

      RNA defines not only the name of the property, also it sends an Notifier to
      tell Blender what has changed, and it contains the UI Text and Tooltip
      When you change that you also want blender to redraw for instance, or update
      its childrens location (childrens matrix)

      We dont want to define these update calls for anim/ui/py - so instead each
      access via rna: "ob.location" in python does an rna lookup, gets the array
      in C, the python api converts this known rna type to a vector and returns the value.
      Internally it does py -> coerce into an array -> rna array set function -> DNA array.
      Probably this is only interesying to py api devs.

      It might be interesting to note that RNA definition is split in two.
      A compile time generation and runtime code. In the RNA files, this is
      represented by #ifdef RNA_RUNTIME #ELSE #ENDIF

      If you ever want to look at rna code... you can mouse over the button and
      see its python variable, so if you mouse over object location youll get its
      python name, then search for "location", or "armature_head" or whatever...
      this is fairly easy way to find the rna code from a button (you can also just
      search for the tooltip which was people was used to do mostly in 2.4x)

      The rna code is in source/blender/makesrna/
      The file will start with rna_.

      If you use crep.sh, remember to add the ""'s or you'll get too
      many hits: for example if you look for "Full screen", you do:
      $ ./crep.sh "Full Screen"
      1 ./source/blender/editors/screen/screendump.c:177:       RNA_def_boolean(ot->srna, "full", 1, "Full Screen", "");
      2 ./source/blender/editors/screen/screendump.c:331:       RNA_def_boolean(ot->srna, "full", 1, "Full Screen", "");
      3 ./source/blender/editors/screen/screen_ops.c:1592:      ot->name = "Toggle Full Screen";
      4 ./source/blender/makesrna/intern/rna_scene.c:1387:              {R_OUTPUT_SCREEN, "SCREEN", 0, "Full Screen", "Images are rendered in full Screen"},
      enter a number to edit >

      Basically we have Notifiers and Listeners.
      RNA props send Notifiers and the different space types "listen" to those
      Notifiers and do an update/redraw
      Example and Questions
      So you have an objects location, which is: 

      // in DNA_object_types.h
      float location[3];

      but as well as this you want to access it from the UI and python and animations
      system of course: see the RNA counterpart below.

      Definition code:

      prop= RNA_def_property(srna, "location", PROP_FLOAT, PROP_TRANSLATION);
      RNA_def_property_float_sdna(prop, NULL, "loc");
      RNA_def_property_editable_array_func(prop, "rna_Object_location_editable");
      RNA_def_property_ui_text(prop, "Location", "Location of the object.");
      RNA_def_property_update(prop, NC_OBJECT|ND_TRANSFORM, "rna_Object_update");

      Q: Does this RNA specify 3 floats? Or is it not supposed to?
      A: RNA only references the 3 floats dna defines, the subtype PROP_TRANSLATION
          does that. For more generic arrays, the size has to be supplied.

      Q: so how does "ob.location = (x,y,z)" or whatever in Python update the DNA values?
      A: It runs the rna function to set the array from a python array that is converted,
          then it calls the RNA's update function which will trigger other updates
          if they are defined for that type.

      Q: Well wait, does that update function get generated automatically or do
          we have to write it? Is rna_object_update a function somewhere?
      A: It's done through the call to RNA_def_property_update. 
          In this case we have:
          RNA_def_property_update(prop, NC_OBJECT|ND_TRANSFORM, "rna_Object_update");

          - Thats a function at the beginning of the RNA file.
          - These NC_ and ND_ Notifiers are defined in wm_types.h, inside
            windowmanager code.
          - rna_Object_update is defined in the RUNTIME part of the code.

          - You don't always need a function, so that can be NULL and only use
            notifiers flags.
          - Most of the time you dont needs to write your own update functions,
            or they can be added later if you get some redraw problems.. its not
            likely to break if they are not there...

      Q: So if you want to add a new type of object, do you just need to define
          RNA or also DNA?
      A: Defining new object types wasn't done in years and you'd also need to be
          familiar with reading and writing code in blender (readfile.c/writefile.c).
          Not suggested for beginners.



      Operators are tools.

      They're a very simple data structure with ID, descript and label strings,
      as well as a couple of function pointers and flags.
      The functions will be called when the operator is executed.

      The basics are exec, invoke, poll.

      It is called to apply the operator using only its parameters.
      It is called when the operator runs interactively, when it needs user input
      (from a menu, mouse motion, ...)

      This is called when the operator can be run in the current Context.
      The context is more or less the current state of the UI (where the pointer
      is, what's selected, ...), we'll talk about context later.
      For example the poll function is used to grey out buttons and menu entries.

      Exec and invoke are the functions that actually do stuff.
      For instance invoke() gets the mouse location, execute() assumes the input
      was alredy assigned as operator options.

      Generic poll functions also exist, you don't have to write your own.

      The operator definition can also include RNA properties, that are used as
      operator parameters.

      There are around 1000 operators at the moment: you can find out the complete
      list from the operator cheetsheet in the Help menu.

      If you want to get started with writing operators, there are python operator
      templates in the text templates menu, so you can start by loading the template.
      Running it, it wont appear in the menu but you can access it from the spacebar

      Example and Questions
      The make parent operator defines a property for parenting type.
      Its invoke function displays the parenting menu.
      Its exec reads the type from the properties and does whatever is needed.
      For operators that need a menu like that, we have a generic menu function
      that can be used.
      Here's the parenting operator:
      void OBJECT_OT_parent_set(wmOperatorType *ot)
        /* identifiers */
        ot->name= "Make Parent";
        ot->description = "Set the object's parenting.";
        ot->idname= "OBJECT_OT_parent_set";

        /* api callbacks */
        ot->invoke= parent_set_invoke;
        ot->exec= parent_set_exec;

        ot->poll= ED_operator_object_active_editable;

        /* flags */

        RNA_def_enum(ot->srna, "type", prop_make_parent_types, 0, "Type", "");

      In this operator:
      - parent_set_invoke, parent_set_exec, and ED_operator_object_active_editable
        are functions.
      - prop_make_parent_types is an array of defined types
      - the flags are used to specify different behavior:
        - OPTYPE_REGISTER means it will be displayed in the last operator toolbar
        - OPTYPE_UNDO means it will set an undo point after it runs

      Q: Undo handled generically? (as it looks to be)
      A: Yes.

      Q: In this example function where do you get ahold of the Context.
      A: The context is passed as argument to the invoke, exec and poll function.
          - The event system will give you the correct context,
          - invoke gets the context, the operator structure and the caller event,
          - exec gets the context and the operator

      Q: Is there a difference between python operators and C operators apart from speed?
      A: No, the python operator creates an operator type struct when registered

      Q: What about for submitting to the code base?  Do the main devs prefer Python
          or C operators?
      A: Py defined operators are acceptable as patches tracker.




More information about the Bf-committers mailing list