[Bf-python] new python development path

[Gilbert, Joseph T.]

Very good point. 
We shouldn't have problems with creation then. However you can still can't edit unlinked Action data through the UI and you can through python.

-----Original Message-----
From: bf-python-bounces at projects.blender.org on behalf of Toni Alatalo
Sent: Fri 2/10/2006 3:42 PM
To: Blender Foundation Python list
Subject: Re: [Bf-python] new python development path
 
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
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 4268 bytes
Desc: not available
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20060211/a81837e9/attachment.bin>