* Automatically do us++ and us-- reference counting in ID pointer
set functions.
* Added an enum property callback to dynamically vary the list of
available items.
* Added some functions to do removes on pointers and collections
runtime defined for RNA and using ID properties.
* Constraints now have owner/target space wrapped, and most
pointers made editable. They can be ported to use python layouts.
* Also other pointers made editable that I think are see now with
the automatic reference counting.
Brecht, would you be able to have a look at this if you have time - I can't
figure out how to trigger the python file to register the header instead of
what's in outliner_header.c.
* Any Struct can now have ID properties, by creating a callback
function to create/return an IDProperty.
* Wrapped PoseChannel ID properties.
* Note there is still no way to create ID Properties in 2.5, though
the callback to get/create the initial group is now exposed through
RNA_struct_idproperties.
The Python API to define Panels and Operators is based on subclassing,
this makes that system more generic, and based on RNA. Hopefully that
will make it easy to make various parts of Blender more extensible.
* The system simply uses RNA properties and functions and marks them
with REGISTER to make them part of the type registration process.
Additionally, the struct must provide a register/unregister callback
to create/free the PanelType or similar.
* From the python side there were some small changes, mainly that
registration now goes trough bpy.types.register instead of
bpy.ui.addPanel.
* Only Panels have been wrapped this way now. Check rna_ui.c to see
how this code works. There's still some rough edges and possibilities
to make it cleaner, though it works without any manual python code.
* Started some docs here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATypeRegistration
* Also changed some RNA_property and RNA_struct functions to not
require a PointerRNA anymore, where they were not required (which
is actually the cause of most changed files).
Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'.
These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand.
By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :)
For example, check the following diagram (thanks Cessen/Nathan V from Peach team):
http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png
TODO List:
* Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects)
* Graph Editor interface for editing these needs to be rewritten
* Python function for evaluating these expressions is needed (Campbell?)
Committing quick RNA function calling RNA_function_call_direct* functions set à la fprintf.
It works like this (with ptr being an RNA pointer to some ID):
RNA_function_call_direct_lookup(ptr, "rename", "s", "MyCamera");
the format specifier would not be strictly needed but I prefer to keep this as it gives nice error handling in case some RNA function changes.
Format strings are very easy and similar to python ones:
"b" for booleans
"i" for integers
"f" for floats
"s" for strings
"e" for enums (using int values)
"O" for pointers (using O as in py, we can change to P)
"N" special NULL parameter, valid to skip optional parameters
For bools, ints and floats you can use a special format specifier with [n] where n is the size of an array of that type. For instance "f[4]" to set a location/vector (it expects a pointer to float* holding the array).
Return values still have to be implemented.
Also I know the name is a bit long maybe we can cut it up at RNA_call_direct or simply RNA_call.
* Added REQUIRED flag for function parameters.
* Made dupliframes/verts/faces/groups an enum, and make it editable.
* Enum bitflags were broken, fixed.
DNA_texture_types almost finished, missing still plugin type.
I noticed many texture share the same noise settings maybe this can be grouped into a common function.
Also testing out first commit.
which can be defined to call C functions with defined parameters.
* Parameters are RNA properties, with the same types.
* Parameters are stored in a ParameterList, which is like a small
stack with the values. This is then used to call the C function.
* Includes Python integration.
* Only one test function is part of this commit, ID.rename.
* Integration with the editors/ module is not included in this
commit, there's some issues to be worked out for that still.
- Register python panels
- Added a generic class checking function BPY_class_validate() for panels/operators.
- No button drawing yet
Brecht, Added RNA_enum_value_from_id() and RNA_enum_id_from_value() to rna_access.c to do lookups between identifiers and values of EnumPropertyItem's, Not sure if these should go here.
*******
ported some of the scene buttons to the new system
- added RNA_SceneRenderData struct to rna
- added a warning print to uiItemR when it can't find the property
- what is not there is due to relating entry not being in RNA
- anim button does not work
Im commiting this so we have much more wider test area then text and object buttons
* Test with constructing RNA paths from pointer + property, based on
a callback per struct. For animato we'll need to be able to do this,
for keyframing from buttons, unless we can somehow derive the paths
from the interface code, which seems like an unnecessary burden.
However constructing such paths is not always quick, and we need a
fast way to find out if a property is animated for drawing buttons,
so this may not be the best solution.
See rna_mesh.c for some callbacks created as a test.
* Added BLI_sprintfN to mallocN a new string using printf style
formatting.
* Made it based on string lookups rather than fixed enum, to make
it extensible by python scripts.
* Context callbacks now also have to specify RNA type when returning
pointers or collections. For non-RNA wrapped data, UnknownType can
be used.
* RNA wrapped context. The WM entries are fixed, for data context
only main and scene are defined properties. Other data entries have
to be dynamically looked up.
* I've added some special code in python for the dynamic context
lookups. Tried to hide it behind RNA but didn't find a clean way to
do it yet. Still unused/untested.
* Also minor fix for warning about propertional edit property in
transform code, and fix for usage of operator poll with checking if
it was NULL.
- Added an autogenerated C++ API, basically a simple layer over the C
API, but with the advantage that it fits the object oriented RNA
model better. Read-only still like the C API.
- Had to rename "protected" property in Action Group because it is
a C++ keyword, called it "locked" since that seems more consistent
anyway?
- It's not used anywhere, so here's some example code I used to test it,
to get an idea of how it would be used:
http://pasteall.org/4582/cpp
- Also, ID names are now editable.
* As a test, used by:
* Object buttons, tried to make it match the mockup.
* Text window header.
* Text window properties panel.
* Panel interaction with view2d is still problematic, need to make
this work properly still.
* Templates are very basic, the ones there are simple but already
can follow the object buttons mockup quite closely.
* It's based on a three level system: panels, templates and items.
To get an idea of what that means in practice, see:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/UI_LayoutEngine#Panels.2C_Templates_and_Items
There was very little structure in this code, using many globals
and duplicated code. Now it should be better structured. Most
things should work, the main parts that are not back yet are the
python plugins and markers. Notes:
* Blenfont is used for drawing the text, nicely anti-aliased.
* A monospace truetype font was added, since that is needed for
the text editor. It's Bitstream Vera Sans Mono. This is the
default gnome terminal font, but it doesn't fit entirely well
with the other font I think, can be changed easily of course.
* Clipboard copy/cut/paste now always uses the system clipboard,
the code for the own cut buffer was removed.
* The interface buttons should support copy/cut/paste again now
as well.
* WM_clipboard_text_get/WM_clipboard_text_set were added to the
windowmanager code.
* Find panel is now a kind of second header, instead of a panel.
This needs especially a way to start editing the text field
immediately on open still.
* Operators are independent of the actual space when possible,
was a bit of puzzling but got it solved nice with notifiers,
and some lazy init for syntax highlight in the drawing code.
* RNA was created for the text editor space and used for buttons.
* Operators:
* New, Open, Reload, Save, Save As, Make Internal
* Run Script, Refresh Pyconstraints
* Copy, Cut, Paste
* Convert Whitespace, Uncomment, Comment, Indent, Unindent
* Line Break, Insert
* Next Marker, Previous Marker, Clear All Markers, Mark All
* Select Line, Select All
* Jump, Move, Move Select, Delete, Toggle Overwrite
* Scroll, Scroll Bar, Set Cursor, Line Number
* Find and Replace, Find, Replace, Find Set Selected,
Replace Set Selected
* To 3D Object
* Resolve Conflict
* The settings of KeyingSets can now be viewed/modified through RNA.
* Shuffled RNA wrapping for AnimData over to its own file
* Moved insert-key flags to DNA_anim_types.h, as they're now used for KeyingSets.
* RNA_blender.h is now generated along with the other files. It is not
used anywhere yet, and still located quite hidden next to the other
rna_*_gen.c files. Read only access for now.
* Inherited properties are not copied from the base anymore but
iterated over. Patch by Vekoon, thanks!
* Array get/set callbacks now do the whole array instead of getting an
index. This is needed for some layers for example so python can set
the array as a whole, otherwise the check that one layer has to be
enabled at all times gets in the way. Also nicer for the C API.
* Also some changes to returning pointers to make the API cleaner, got
rid of the type() callback and instead let get() return PointerRNA
with the type included.
The C API looks like this currently:
http://users.pandora.be/blendix/RNA_blender.h
It's about time that the RNA wrapping for various parts of the animation system were cleaned up for my recent changes. I've moved some code around (and/or deleted a file or two) in the process.
* Work around bScreen/Screen DNA name patching, so bScreen does not
require manual callbacks to be written for properties.
* Added SpaceLink and SpaceImage RNA.
* Fix issue initializing ID property arrays with default values.
DNA
* Some DNA changes for space image.
* And a fix for corrupt clone image pointer in reading brushes.
* Finished DNA_lamp_types.h, DNA_world_types.h and DNA_sound_types.h.
* Renamed "parent" struct property to "nested", and also remaining "from"
usage to "base".
* Added a NEVER_NULL subtype for pointers and use it for all properties
that apply.
* Make sure all structs have a description, and fix any other DOC_BROKEN
descriptions, also many other naming consistency improvements.
* DNA_cloth_types.h, patch by Roelf de Kock. The gravity[3] member
is not being parsed correct by makesdna.c and will give issues
even when trying to fix it. Worked around it for now in RNA by
wrapping it manually, but this should really be fixed in the DNA
genetics code, added a comment about it in DNA_cloth_types.h.
* Handle vertex groups and uv layers more consistent now. They are
all exposed as strings now. Reason is that indices don't really
say much, and a direct pointer is not always possible because for
example a uv layer in a material can be used for multiple objects
and so there is no single pointer. In python it is not too hard
to use either since the strings works as a key for lookups.
For the user interface we can later think of some method to
generate popup menus in a way that works for vertex groups,
uv layers, bones etc.
* This also fixes the XXX's in rna_modifier.c, I think that can be
marked done.
