Hi Charles, answers inline. On Sat, Mar 20, 2010 at 3:36 PM, Charles Wardlaw <cward...@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 Toggle is just was the key runs, you can also do bpy.ops.object.mode_set(mode='EDIT') to chech you can do is_editmode == (context.mode == 'EDIT')
> - 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? Operators are tools and not api functions, the idea is that operators manipulate the context so python can be used to create macro's What an operator would return isnt always clear, for instance if you link in objects, would it contain a list of every object, scene and text blocked linked?? however in some cases its really obvious that you would want to run an operator and get a return value, in these cases we should probably make RNA function calls for these operators (internally they can use the same C functions). There are also quite a few cases where the operators should be removed and only have API calls only. Things like "Move Modifier Up" IMHO are not useful as operators. But then we need to see how rna function calls can be done from the UI :S. We could try to make operators behave more like API functions but this is not a small task and not what operators were originally designed to do. so I think its out of the scope of 2.5 tool refactor. > - 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. There are many many inconsistencies in how operators work at the moment, this is one reason I dont want to call blenders API stable too soon! Different developers wrote operators, mostly to get blender working again and not having read how all other operators work. When you try use operators from python you end up finding many problems like this. for data creation and removal though we accept that operators are not ideal and there are existing functions for this # Example arm = bpy.data.armatures.new("MyArmature") obj = bpy.data.objects.new("MyObject", arm) scene = bpy.context.scene scene.objects.link(obj) > 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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers