[Bf-committers] Re: [Bf-blender-cvs] CVS commit:
blender/source/blender/src editarmature.c editcurve.c
header_view3d.c meshtools.c space.c
theeth at yahoo.com
Mon Jan 2 00:03:25 CET 2006
--- 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
> > Log:
> > Added a python hook to Joining objects
> > Object.Join()
> > 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
Yahoo! for Good - Make a difference this year.
More information about the Bf-committers