[Bf-committers] Re: [Bf-blender-cvs] CVS
Object.py blender/source/blender/src editarmature.c
editcurve.c header_view3d.c meshtools.c space.c
cbarton at metavr.com
Mon Jan 2 13:27:10 CET 2006
Martin Poirier wrote:
> --- Stephen Swaney <sswaney at centurytel.net> wrote:
>> On Fri, Dec 30, 2005 at 03:17:16PM +0100, Campbell
>> Barton wrote:
>>> campbellbarton (Campbell Barton) 2005/12/30
>> 15:17:16 CET
>>> Added a python hook to Joining objects
>>> Seperated the join calls from space.c and
>> view3dmenu into join_menu() in space.c, like the
>>> okee's from join_curve, join_mesh.. etc are in
>> join_menu() so python can call them without UI
>> menu's in the way.
>>> this is also a bit neater since there were 2
>> places that were doing what join_menu() does now.
>> A couple thoughts:
>> In Object.c in the M_Object_Join() method, before
>> you use ob after
>> Object *ob= OBACT;
>> you might want to check for ob being nonzero
>> since OBACT is a macro that can return O.
>> Since the scripter cannot tell of Object.Join() did
>> you might want to return the number of objects
>> joined instead
>> of None.
> Another thing, this is probably obviously, but was
> this code tested for reference integrity?
> Lets say you already have python references to the
> selected object, what happens with them?
> Blender automaticly removes all selected objects
> except the active one when you do a join (that's
> remove, not decrease user count), how does the BPy
> objects behave after that? (or for that matter, any
> kept reference to deleted Blender data)
> As far as API design goes, I think the method is too
> much state dependant and linked with many outside
> variables (in the UI sense of the term): it acts on
> objects that aren't references neither as parameters
> nor as properties of the caller (though that last one
> is debatable).
How about join takes a list of BPython pbjects and joins those? would
that be acceptable?
More information about the Bf-committers