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

[Martin Poirier]

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


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
>