[Bf-python] Making IK flag writable in the Bone class

[Jonas Petersen]

I totaly agree with Stephens point! I probably bad style using hasIK() 
to set the value.

So should I head to a getIK()/setIK() function pair? Will then hasIK() 
remain for compatibility?

What about the option of making the member variable 'ik' writeable?

I'll do some more testing and keep you informed!

Btw. do you know when the next stable release is scheduled? You think 
this could make it in there? The thing is that using this feature in a 
python script does only really make sense if its included in the 
official blender release. Also putting my effort into this makes most 
sense only then.. :)


Gilbert, Joseph schrieb:

>The original idea was to have setIK() but this didn't work out so it was
>changed to hasIK().  The bone flags are a very dirty mess - ik being one
>of the only flags that is relevant (the reason for no getFlags()). But I
>think that if you can get this to work well Jonas a get/setIK() method
>would look nice.  For some reason I thought that this was a more complex
>issue but maybe the answers are simple :) I would suggest that you test
>the function well especially in relation to child bone's and their
>return data (loc, rot, mat) to see if it is doing well compared to the
>ik switch in the UI panel. 
>
>-----Original Message-----
>From: bf-python-bounces at projects.blender.org
>[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Stephen
>Swaney
>Sent: Friday, October 22, 2004 2:57 PM
>To: Blender Foundation Python list
>Subject: Re: [Bf-python] Making IK flag writable in the Bone class
>
>Jonas Petersen wrote:
>  
>
>>Stephen Swaney schrieb:
>>    
>>
>>>From an API point of view,  I really, REALLY dislike the idea
>>>of overloading a query function to set and unset a flag.
>>>
>>>
>>>
>>>      
>>>
>>Me too :)
>>
>>But it's done like this in other places as well. So I thought it would
>>be ok. Check out NMesh for example. It has 3 "has*" functions, which
>>    
>>
>all
>  
>
>>have an optional parameter to set the flag.
>>    
>>
>
>That doesn't make it any less weird or confusing.  IMHO, stuff like
>this should be flagged in the 0-todo.txt file for cleanup and 
>deprecation.
>
>We should either follow a get/set function pair style or use
>a C++ overloaded method style.
>
>Boolean someFlag();  	    // gets value
>None    someFlag( param );  // set value 	
>
>Having a function called hasSomething() that also sets the value
>is misleading.  It is also unclear.  Without looking at the code,
>is the return value the flag state from before or after the flag 
>is set?
>
>  
>