[Bf-taskforce25] Proposal: Blender API revisited

[Shaul Kedem]

Another benefit would be that the same path is taken when executing python
and regular code, which means testing framework can be done in python and
test blender C API as well.

On Fri, Mar 20, 2009 at 12:09 PM, Nathan Vegdahl <cessen at cessen.com> wrote:

> 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
> >
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090320/1465870f/attachment-0001.htm