[Bf-committers] registering 'dynamically generated' ops?

[Bassam Kurdali]

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: 
http://pastebin.com/3j2HG5Yy
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?
cheers
Bassam

> 
> 
> 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