[Bf-python] Python API proposals

[Campbell Barton]

Hi, reply inline...

On Sun, Oct 9, 2011 at 10:10 PM, Dima Glibitsky <dima.glib at gmail.com> wrote:
> Hello,
> While developing a script
> (http://wiki.blender.org/index.php/Extensions:2.5/Py/Scripts/3D_interaction/Enhanced_3D_Cursor),
> I found out that I have to emulate some Blender functionality via indirect
> means. To make things simpler for script developers, I propose the following
> extensions to the Blender Python API:
>
> * Make unified access to both predefined and custom TransformOrientations:

This breaks my own rule of thumb with the Py/RNA api which is not to
hide internal functionality when exposing data, for 2.4x we did this
and ended up shooting ourselves in the foot more often then making a
good api.
So if this is done I prefer it happen in blenders internals too, or not at all.

Don't think this is needed, we can have a way to access the matrix of
orientations which allows access to both in a consistant way without
fake-builtin orientations in a collection.

> ** Scene.orientations should return a collection containing both predefined
> and custom transform orientations.
> ** Predefined ones are read-only (cannot be removed or modified), but
> otherwise their name and matrix can be accessed.

> ** No two orientations should have same name (if there is a conflict, one of
> the orientations should be automatically renamed, just like other ID blocks
> do).
+1, easy enough to ensure this.

> * Introduce a method for creating custom tranform orientations without
> having to call bpy.ops.transform.create_orientation()
> ** For example: Scene.orientations.new(name, [matrix])

+1, not hard to add.

> * Introduce a method for getting location of current pivot (or, better, any
> kind of pivot):
> ** SpaceView3D.pivot_point_location([pivot_type]) -- returns the location of
> the specified pivot point in global coordinates; if pivot_type is not
> specified, active pivot point is returned.

Can be added but wary of exactly how these api functions work.

> * Add a drawing callback that gets called after rendering of common 3D
> objects, but before rendering X-Ray objects.
> ** E.g. 'PRE_XRAY'

Guessing you need this for a specific case, I worry we get too many of
these `special cases` when to decide whats *important* or not isnt
easy but would like to know what this is for before commenting on it.

> * Add a property definition for storing references to ID blocks (Objects,
> Materials, etc.):
> ** E.g. bpy.props.IDBlockProperty(type="", name="", description="",
> options={'ANIMATABLE'}, update=None)

We already got a lot of requests for this - it can be done but IMHO
should be done in a way doesn't loop over _every_ other ID when _any_
id is removed - which is the problem you get when any id can reference
another.

> dairin0d