[Bf-committers] ops functions, parameters, and returns
joeedh at gmail.com
Tue Mar 23 01:35:32 CET 2010
Keep in mind when writing scripts that manipulate editmode, that we
may change the API there (and even whether we even *have* an
"editmode") in the future.
On Sat, Mar 20, 2010 at 7:36 AM, Charles Wardlaw
<cwardlaw at marchentertainment.com> wrote:
> Hi all,
> Finally got some time to sit down and do some API programming. I know everything is in flux, which is why I wanted to bring up this topic now.
> I have a few questions about thought process behind the API:
> - Editmode toggle: why is it just a toggle? Why can't it be set to a value like it was in the 2.49 API? Seems to me the old way (x = editmode() / editmode(x) ) worked pretty well
> - Why don't the bpy.ops functions that create things return what's created? It seems very roundabout to have to create something and then slurp it out of bpy.context or out of object data. For example, I'm playing with adding bones to armatures. After making sure I'm in edit mode and adding the bone, I then have to drill down somewhere else to get the bone to move its head and tail.
> Similarly, why don't they return a tuple of items that's indexable instead of a set, which isn't?
> - bpy.ops.object.armature_add() - specifying the location moves the pivot of the entire armature object, but the single bone that gets added is still placed at the cursor. Is this a bug or a feature?
> - bpy.ops.object.armature_add() can't specify a name on creation -- is this intentional? Actually it seems that many of the adding functions can't.
> I'm sure I'll have more as I go, but if anyone could help me understand why these parts were done this way I'd greatly appreciate it.
> ~ C
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers