[Bf-committers] Blender 2.5 api proposal.

[Campbell Barton]

On Tue, Dec 2, 2008 at 6:48 AM, Timothy Baldridge <tbaldridge at gmail.com> wrote:
>> What remains is a lot of calls like "Add constraint" or "Delete
>> modifier", which is currently a very undefined piece of Blender code,
>> closely tied to the buttons for such options. At this moment it's well
>> possible we don't tackle all of that via Operators, still allowing
>> direct callbacks to buttons (just for the sake of simpler migration).
>
> It seems to me that part of these issues come from the fact that we're
> trying to squish the rather procedural API of C into the OOP based
> programming of Python.
>
> I'm assuming the issue with things like modifier stacks is that
> currently every list of objects in Blender uses a different method of
> data modifiying? So in some cases we have linked lists and other times
> we have vectors (arrays). Perhaps what we need is a Standard Template
> Library for blender. In this way we can make the internal Blender code
> more closely match the Python code.
>
> It seems to me that the best way way to have Python access the
> modifier stacks would be with Python lists:
>
> obj = getObject("MyBlenderObject")
> mod = BuildModifyer()
> obj.modifiers.append(mod)
>
> But while we're on the subject of rewriting everything, should we
> stick with C instead of C++? Now I know, most C++ code is often (or
> perhaps most times) abused, but well written C++ code can aid
> readability. It seems to me that allot of Blender code could be
> simplified by using the OOP-ness of C++.  In general the 3d tool set
> is object based. We take a object and set the transform and rotation
> attributes of that object. We use modifiers to warp object. It seems
> that the code should express this to some extent. In the end it's
> really 6 of one half a dozen of the other, but C++ would help new
> coders make a easier transition from Python to C++.
>
> Timothy
>
> --
> Two wrights don't make a rong, they make an airplane. Or bicycles.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

@Chris, Agree, Python should be wrapping a C API, custom functions in
the PyAPI should be added with care - for functionality that's only
relevant to the py api.
To me it looks like RNA already does this well when it comes to accessing data.
- Adding support for other languages is an advantage too, but Id
rather leave that alone for now :)


@Martin,
Its difficult to know how much work haveing the 2.4x API running
Blender2.5, along with this there is the trouble of multiple API's
running parallel that proved problematic for me when trying to merge a
previous python API branch.

If you believe " find source/blender/python/ -name "*.[h|c]" | xargs
cat | wc -l ", the python api is over 100,000 lines,
It  seems a waste of time when scripters are going to need to modify
their scripts to run with 2.50 - (since the 2.4x api will be changed
for Blender 2.5),
And a second time with 2.51+ when the 2.4x API is dropped.

I also suspect if we did this, the API would NOT get removed at 2.51,
since this means a load of scripts break, and nobody wants to be
responsible for the task of migrating all/most scripts between 2.50
and 2.51. (2.4x API suffers from deprecated functions not being
removed)

IMHO it would be better to maintain 2.48 by backporting bugfixes
during the transitional period.


@Ton,
The wording can change but this raises the question -
Which common tasks would you want to do in python that would not be
available through PyRNA, PyOperators or utility functions that can be
written in python.
I was under the impression that adding/removing a constraint,
material, modifier, image etc would be operators, since this would
also be needed to record/playback user actions.

These functions are important for python, if they are not operators
then we need some other way to access them.
Though I wonder how much harder it would be to make them operators
(once we have an PyOperator auto-generated api),
Since wrapping these functions in the Py/C api is time consuming too,
taking into account time for testing that the function is called
correctly and adding in doc strings in C and EPYDocs.

I'll write up a shortlist of operators the py api will need.


@Timothy, this is out of the scope for the Python API discussion.

-- 
- Campbell