[Bf-taskforce25] Proposal: Blender API revisited

Brecht Van Lommel brecht at blender.org
Fri Mar 20 15:30:39 CET 2009


Hi,

After some more discussion on IRC, here is another proposal, not unlike
the Blender API one, but with some tweaks to get it more feasible and
incremental.

a) Blender 2.5 is about tools and the event system, and operators remain
just that. They are always context sensitive. Getting blender
functionality working as such tools is the #1 priority for 2.5.

b) A secondary low level API provides access for python scripts. This is
very much like the Blender API proposal. What I would like to see
different there however is that it should be defined in the editor
modules (close to the operators), and not have the operators call any
auto-generated functions.

c) Operators are still available for python to call, but they are
context sensitive. This means they are mostly useful in macro like
scripts. The low level API permits to do context-less operations.


To demonstrate what this means in practice, let me show an example. This
is the current delete objects operator:
http://pasteall.org/4641/c

This is how it would look in the earlier context-decoupled method:
http://pasteall.org/4640/c

And here it is using a separate operator and low level python function:
http://pasteall.org/4642/c

Advantages:
- Low level python functions can be added incrementally, not interfering
with 2.5 targets much.
- Operator design does not get complicated further.
- There is a clear distinction between operators and python functions,
permitting better API design.

Disadvantages:
- Means we will likely release 2.5 with reduced python functionality.
How much depends on efforts to improve the API.
- Duplicate code in defining operator properties and function
parameters.
- Effort is needed to get operators accessible context-less for python.
Unavoidable in any design?

Brecht.




More information about the Bf-taskforce25 mailing list