Hi Simen,

Your pseudo-code looks quite flexible to me, I use a similar one (the one I
sent you in last reply). You have a possibility to give it a list of
objects, a list of attrs, and different execution states. You can also
define it like this to make it even more flexible:

def lockAttr(objects=[], attributes=[], state='lock'):
    if len(objects) == 0:
         # get the current selection
    if len(attributes) == 0:
         # do the operation on all visible channel box attributes (or all
keyables - your choice)

This can give you a default call that can be like this:

lockAttr()

which will lock all channel box attributes on the currently selected
objects without you specifying any of inputs. I use this quite often.
I would also do some input checks, so that your function doesn't die if
given object or attr doesn't exist. This is specially important if the
function is meant to be used by the "end user", not from other code where
the inputs are controlled.

And take a look at Mark's package, it is quite well done. It takes the OOP
concept a step higher then my system does, it is much more generic and
unified, really a lot to learn from there (I will be looking at it closely,
thanks for shearing, Mark)

Cheers
Sasha

On Wed, Mar 13, 2013 at 11:09 AM, Mark Jackson <[email protected]> wrote:

> bIt might be useful to take a look at mt Red9 pack. In there is a module
> called Red9_Meta which is aimed at OOP oriented system type of coding, in
> fact there's a subclass called metaRig which at the moment is just a class
> designed to bounce round rigs. However, the idea of all of this is that it
> gives you some really nice hooks to subclass and do your own setups. I've
> tried to add a ton of MetaData help on the blog about the concepts involved.
>
> For procedural rigs etc the idea would be something like Alex mentioned.
> I'd start with a baseClass that's just an empty system but has all the
> hooks and core functions that any rig subsystem would need, things like
> anchor points, system type, switches etc. Then I'd subclass that for all
> your rig parts, treating arms as a system, legs as a system,
> hands/finger/head etc all as subsystems. This way any generic calls you add
> to the baseClass you automatically get.
>
> If you subclass the baseclass from meta you also get the advantage of a
> factory class and all the meta wrapping that I've been adding, and there's
> some very useful attr handling in there. More over when you run the calls
> in meta it will return you back the correct class from the objects
> involved, you run getConnectedMetaData() on a hand controller and it
> doesn't just give you back the controller, it gives you back your
> ArmSubsystem as the python class it came from already
> instantiated.....makes coding so much easy as all those specific cases you
> always add are wrapped and managed for you ;)
>
> Mark
>
> red9: 
> http://red9-consultancy.blogspot.co.uk/search/label/Metadata<http://red9-consultancy.blogspot.co.uk/>
>
>
>
> On 13 March 2013 09:36, Simen Chris <[email protected]> wrote:
>
>> Thanks a lot Sasha, that's really helpful! :)
>>
>> I have a quick question about a utility module, I'm not sure how to build
>> the different methods in a flexible way.
>> Here's an example (pseudo-code-ish):
>>
>> #Method for locking/unlocking attributes
>> def lockAttr(objects, attributes, state):
>>     for obj in objects:
>>         for attr in attributes:
>>             if state == "lock":
>>                 cmds.setAttr( obj + '.' + attr, lock=True, keyable=False )
>>             if state == "unlock":
>>                 cmds.setAttr( obj + '.' + attr, lock=False, keyable=True )
>>
>> #Try to call the method
>> lockAttr(['pSphere1','pSphere2'], ['translateX', 'translateZ', 'lock')
>>
>> This is what I want (kinda), a flexible way so that I can run the command
>> in one line, and have multiple objects as inputs, and define wether to lock
>> or unlock it. I was wondering if you could give an example on how you would
>> go about doing this in a method?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
> --
> -------------------------------------
> Mark Jackson
> Technical Animation Director
> http://markj3d.blogspot.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to