[Bf-committers] registering 'dynamically generated' ops?
bkurdali at freefactory.org
Mon Sep 13 20:55:26 CEST 2010
It seems that using setattr() to set the invoke / execute / poll
functions was the culprit, presumably metaclassing works *first, then
setting the functions, so the operator doesn't end up working.
I've fixed it to just assign the functions inside the class definition,
check the function build_op() in:
I think it might be a bit nasty that setattr() and type()? no longer
work as expected, since people with a python background expect these to
work. Also a bit nasty is the difference I mentioned in my original mail
between Win7 and Linux; it seems odd (and unfortunate) that in win7 I
need to just register the operators, whereas in Linux I need to
unregister and then re-register again.
PS thanks martin for setting me on the right path.
On Mon, 2010-09-13 at 13:07 -0400, Bassam Kurdali wrote:
> On Mon, 2010-09-13 at 09:26 -0700, Martin Poirier wrote:
> > Hi,
> > I talked with Campbell about that problem yesterday, actually.
> > I think the issue is that you're bypassing the metaclass by constructing the class through a call to type().
> > We couldn't see any reason why you couldn't use the normal class syntax instead. The name of the class doesn't matter when registering, so you can just do something like this:
> > for ...:
> > class MyOperator(bpy....):
> > poll = PollClassMethod
> > ...
> Hi Martin, I tried this:
> and I still get:
> invalid operator call OBJECT_OT_copy_OBJ_LOC
> on the console when trying to actually call the operators... something
> is still not right, any clues?
> > I can check that this week if there are still issues.
> > Martin
> > --- On Mon, 9/13/10, Bassam Kurdali <bkurdali at freefactory.org> wrote:
> > > From: Bassam Kurdali <bkurdali at freefactory.org>
> > > Subject: [Bf-committers] registering 'dynamically generated' ops?
> > > To: bf-committers at blender.org
> > > Received: Monday, September 13, 2010, 11:38 AM
> > > Hi all
> > > Since Martin's commit for I believe metaclassing,
> > > registering ops
> > > became obsolete, raising an AttributeError, instead, ops
> > > created (via
> > > python) are automatically registered- very nice!
> > > However I have one script (the clone of 2.4x's copy
> > > menu):
> > > https://svn.blender.org/svnroot/bf-extensions/contrib/py/scripts/addons/space_view3d_copy_attributes.py
> > >
> > > This script dynamically builds the ops, so that it is easy
> > > to extend
> > > just by writing a function that copies something from one
> > > object (or
> > > bone) to another, the rest (looping over all the selected
> > > bones, making
> > > the operators to be called from the menu) is handled more
> > > or less
> > > automatically by the script.
> > >
> > > Before Martin's commit, I had a small loop in the register
> > > function
> > > that would go over the list of generated ops and register
> > > them one by
> > > one. After the commit, this raised an attribute error as
> > > expected. So I
> > > removed the registration of the ops, and the script runs
> > > without error,
> > > However, when I try to execute any operator from the menu,
> > > I get an
> > > error on the console, indicating that my operator call is
> > > invalid - it
> > > seems I need to register those operators explicitly after
> > > all.
> > >
> > > I found a workaround that worked for me, this was making a
> > > loop to
> > > unregister all the dynamically generated ops, and then to
> > > register them
> > > again. This works fine on Linux, but the unregistering step
> > > failed on
> > > meta-androtico's Windows 7 machine! so finally I have
> > > wrapped things in
> > > a try - except, where:
> > > first we try to just register the ops (shouldn't be needed
> > > but is) -
> > > this works on windows 7,
> > > second if we get an AttributeError exception, we unregister
> > > the ops, and
> > > then register them again ( this works on Linux )
> > >
> > > Clearly this is not ideal, I think we should find a better
> > > way, so my
> > > question is:
> > > Am I doing something wrong? is there a 'right way' to do
> > > this for
> > > dynamically generated operators? and finally, why is the
> > > behavior OS
> > > dependent?
> > >
> > > Cheers
> > > Bassam
> > >
> > >
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers