[Bf-python] new python development path

[Toni Alatalo]

On Saturday 11 February 2006 17:39, Gilbert, Joseph T. wrote:
> Very good point.
> We shouldn't have problems with creation then. 

oh :o

> However you can still can't 
> edit unlinked Action data through the UI and you can through python.

so?

~Toni

>
> -----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