[Bf-python] Final Ipo/IpoCurve API revisit

[Ken Hughes]

Gilbert, Joseph T. wrote:

> """ per-Ipo attribute which provides a dict or list of just the 
> constants for that Ipo type"""
> I like this idea but with constants. Remember that if your returning
> constants loaded into the module dictionary and return some subset of
> this to the user you're simply passing him a reference to objects that
> already exist in the module's dictionary rather than creating a ton a
> strings to return to the user.

I was thinking that this dict/list would instead of the module 
constants, not in addition to them.  I guess this would be a 
"convenience" attribute to let the user know which of the values are 
valid for that Ipo type.  Good idea.

> The above would seem to solve some of the difficulties with the shape
> ipos is my guess but I don't really know :).  Is there any reason that
> shape ipos with no name, identifier be given one for the purposes of
> script identification?

I don't think it does solve the problem.  It's been a while since I 
looked at KeyBlocks and the shape Ipo, but the constants wouldn't have 
any useful meaning with respect to the name shown in the UI.

Ken

> 
> -----Original Message-----
> From: bf-python-bounces at projects.blender.org
> [mailto:bf-python-bounces at projects.blender.org] On Behalf Of Ken Hughes
> Sent: Thursday, April 13, 2006 12:26 PM
> To: Blender Foundation Python list
> Subject: [Bf-python] Final Ipo/IpoCurve API revisit
> 
> OK, this is the last step prior to my Ipo update:  it's actually a 
> two-part question.
> 
> antont, stivs and I discussed on IRC two weeks ago whether Ipo curves 
> should be accessed by a string ("ipo['LocX']") or a constant 
> ("ipo[LOCX]").  The disadvantage of strings is... well, they're strings,
> 
> while the disadvantage of constants here is where to get them from.  As 
> I see it, we would have to declare constants in the Ipo module for every
> 
> possible Ipocurve type (which as I count them is at least 160 constants)
> 
> or have a per-Ipo attribute which provides a dict or list of just the 
> constants for that Ipo type.  I already have something like this for the
> 
> string implementation.
> 
> The real sticking point of using constants are Key/Shapo Ipos:  they do 
> not have a specific name or number, and can be renamed by the user, so a
> 
> constant would not work naturally for them.  Shape Ipos can be accessed 
> through the Key API, however, and are currently broken in the Ipo API of
> 
> 2.41, so one solution would be to remove access for them thru the Ipo 
> API completely.  However, using strings to access the Key Ipocurves 
> would be simple to implement.
> 
> My plan, unless people think otherwise, will be to stick with the 
> current string implementation.  At worst, people will not like it and 
> I'll reimplement portions of the code using constants instead before the
> 
> next release.  But if you have an opinion, please speak up soon.  I plan
> 
> to commit to CVS sometime next week.
> 
> Ken
> 
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>