[Bf-python] RVKs

Joseph Gilbert jgilbert at TIGR.org
Thu Sep 22 17:42:44 CEST 2005


I have a few respectful (quoting stivs : )) comments about packages 
structures i'd like to share as it has been a concern to me recently:

It makes sense to put NLA under Blender.Armature if your thinking of 
functional groupings. NLA wraps Actions which defines an Armature's 
animations. NLA applies to armatures - it does not apply to other 
objects. This is the reason it's here rather than Blender.NLA or 
Blender.Object.NLA.

Originally we had no submodules. We started to group submodules by 
function just recently.  Ton has expressed to me (with tha armature api) 
the need to put our modules in some heirarchal order that represents the 
data structs internally. According to this we should have 
Object.Action(NLA). (and Object.Pose, Object.Armature, Object.Mesh, 
etc.). Although not a bad idea I don't think this reflects the purpose 
of python modules.

Modules in python are for presenting an API. A heirarchy of modules is 
called a package structure.  It doesn't make a lot of difference where 
the module resides in the package structure other than from a functional 
standpoint of how the module is imported.  We could get rid of the 
Blender package, for instance, and add all modules separately to the 
_inittab and be happy. (i.e. no package structures at all). However, it 
would remove the 'blender' functional group from the import schema and 
we could not do such things as 'from Blender import *' anymore. e.g. we 
would do 'import Object\import NMesh\import Armature

Functional package structures such as Blender.Armature.NLA, for example, 
would allow you to call 'from Blender.Armature import *' and you could 
do everything required with armatures - including manipulating 
Object.Actions.  Having Object.NLA would also mean that when you do a 
'from Object import *' you have the ability to manipulate Actions - but 
Objects are not always armatures and if you wanted to manipulate the 
armature too, you would also have to call 'import Blender.Armature'.  It 
makes more sense (imho) therefore- from a package import structure - to 
put NLA with armatures. (or top level *cough*)

I know there is pressure to put thing differently, and i'm not so 
adverse to change :), however, I think that the functional package 
structures of modules (rather than following the convention of placing 
modules according to their heirarchy in the internal data structure) 
simply makes sense. I'm not sure if anyone agrees with me :) (I know ton 
probably does not) However I think this makes sense for bpython.

Joseph ^_^

antont at kyperjokki.fi wrote:

>just a short note, (to get this out of my mind)
>
>was looking a bit into how to work with RVKs from Python, and found out about 
>the existing NMesh.insertKey, with the note 'Warning: This and removeAllKeys 
>were included in this release only to make accessing vertex keys possible, 
>but may not be a proper solution and may be substituted by something better 
>later.'
>
>.. with <stivs> we figured that that time might be now, but after a little 
>talk with Ton it became clear that it's better to wait a while. he's still 
>pondering what to do with all the different animation things there are .. 
>rewriting NLA being the next in todo i think, and he might put RVKs to 
>Actions or something .. we'll see. in that case it would not really make 
>sense to have NLA in the Armature module (did it ever?), and i guess the 
>whole NLA will deserve consideration (a new top-level module?)
>
>getting RVK/slider access to Python is not urgent for Orange, so that can well 
>wait. just got a enthusiastic about it for other reasons ;)
>
>dunno how relevant those things will be for you, nor what exactly we will 
>need, but time will tell .. and there still is some :)
>
>~Toni
>_______________________________________________
>Bf-python mailing list
>Bf-python at projects.blender.org
>http://projects.blender.org/mailman/listinfo/bf-python
>  
>




More information about the Bf-python mailing list