[Bf-taskforce25] Proposal: Blender API revisited

[Nathan Vegdahl]

This looks almost identical to what I proposed, except that it's
written much more clearly, and operators don't use the low-level API
to do their work.

The reason I suggested that operators do their work through the
low-level API is because it ensures that the low-level API is
complete.  At least it does once all the operators have been ported,
which can be done over time.

One of the things I love about the operator design is that it ensures
that everything the user can do, Python can do, because anything
exposed to the user *has* to be implemented as an operator.
I think it's important that any low-level API have similar assurances
of completeness.  So I suggest again that the goal be to eventually
port operators to use the API to do work with actual data.  I may be
missing some important implementation details, but it seems like this
would be straight-forward.

Some secondary benefits:
- Reduced code duplication.
- The blender console could echo API calls in addition to operator
calls.  This is great for learning the API, or just refreshing your
memory how to do something if you forgot.

--Nathan V


On Fri, Mar 20, 2009 at 7:30 AM, Brecht Van Lommel <brecht at blender.org> wrote:
> 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.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>