[Bf-python] new python development path

[Toni Alatalo]

On Thursday 09 February 2006 23:41, Gilbert, Joseph T. wrote:
> datablocks and not the other, I think the api become only more
> confusing.

this is certainly something to be wary about, but i think you missed something 
here:

> Actions are basically floating datablocks like everything else. They are
> created as part of an armature object and linked/unlinked to objects as
> needed. If we have one type of access for Armature data and other for
> Action data people will only get confused.

i think ObData objects/datablocks, like MeshData and ArmatureData, are 
different from independent datablocks such as Action and Text and Image etc.

in Blender GUI, there is no way to create a new ArmatureData or MeshData. 
apart from adding a new ArmatureObject or MeshObject to the scene, but to 
create a new Action, you can just go to the action editor and click 'add 
new'.

~Toni

> -----Original Message-----
> From: bf-python-bounces at projects.blender.org
> [mailto:bf-python-bounces at projects.blender.org] On Behalf Of Willian
> Padovani Germano
> Sent: Thursday, February 09, 2006 1:49 PM
> To: Blender Foundation Python list
> Subject: Re: [Bf-python] new python development path
>
> Hi Joseph,
>
> Gilbert, Joseph T. wrote:
> > I agree that this poses serious issues and potential problems.
> >
> > The current idea being floated is that you would obtain unlinked data
>
> as
>
> > a list of names from a module level method such as
>
> Module.GetUnlinked().
>
> > You would use these names to link this data to an object.
>
> This only for obdata (ob->data), not all structs with ID's.
>
> The main issues that I'm aware about accessing obdata are two:
>
> - some operations on ob data may actually change stuff in one of its
> owner objects and we need to know which one to be able to edit it;
>
> - dag updates: changes to ob data must be informed so that all objects
> linked to that data can be update (I haven't investigate properly here
> yet).
>
> The simple and usually sensible way to decide what kind of access we can
>
> give is to follow Blender itself. Via UI you can't edit a mesh unless
> it's linked to at least one object. And you access that mesh by making
> one of its owner objects active. In BPy this means:
>
> ob = Object.Get("abc")
> mesh = ob.data
> # now you're free to edit mesh
>
> For actions, etc. we should consider what Blender itself allows via UI,
> what script writers need and if having direct access could be
> problematic or not. No need to force a general solution on obdata and
> other stuff, that's the point.
>
> Antont, Joe (joeedh): ok, bad use of the word "dict", sorry, a custom
> type, yes, that's what I meant.
>
> --
> Willian
> _______________________________________________
> 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