[Bf-python] Proposed BPyAPI Additions

[Campbell Barton]

Matt Ebb wrote:
>> Campbell Barton <cbarton at metavr.com> wrote:
>>
>> In reply Matt  also
>> Id realy realy like not to have object type spesific funbctions in Scene 
>>
>> or scn.objects
>>
>> Matt, I hear your request, do you think this is adequate?
>>
>> ob= scn.objects.new(Mesh.Primitives.Cube(2.0))
>>     
>
> Well perhaps I'm splitting hairs here, but I'm just thinking on a more conceptual level. When you're working with Blender, you don't first find a collection of objects and add a new object to that collection, which is what the code above looks like it's doing to me. You add the new object to your scene.
>
> This is just from my perspective as someone who (although using the python api more and more these days) is using it, well... for scripting, to automate tasks etc. and not to write big 'applications'. I'd just be happiest if the python API mimicked the Blender user interface as much as possible. I just moved to a new house and don't have internet connected yet, and over the last few days I've been madly putting together my reel, and writing some python scripts to help in stuff I was doing. It was really difficult without the online API reference - I eventually remembered the .py files in /doc that I started using. Maybe this sort of difficulty is just inherent in any API, but I couldn't help but think that it would all be much easier to just 'get things done quickly' and move on if there was a better connection and relevance between Bpy and Blender itself, and that includes a conceptual conenction, instead of it sometimes living in it's own universe beside Blender.
>
> Anyway, that's just my not-so-well informed opinion on this, for what it's worth :)
>
> cheers
>
> Matt
>   
Hey Matt, respect your rationale and dont want to steamroll other 
peoples input by saying my way is the right way,
it seems to me that a part of the problem is that we need to take into 
account the bigger picture when putting forward API suggestions..

    say an object is created by  scn.add(...)  thats ok buy its self,
    but then how do we access an active object?  - scn.active maybe...
    but what if we want to access a scenes active  world or ( in future
    - renderlayer?) we would have to mix scn.activeWorls and scn.active
    Maybe we have scn.world instead.... buw then were mixing up
    conventions- once is .ACTIVEobject and the others .activeWORLD

    It also opens up the case for adding object to every command that
    references an object. scn.getActiveObject() scn.addObject()?


- To summarize, we need a proposal which explains how commands are added 
in a way that is consistent- not just 1 or 2 functions in the API.


About making the API follow the UI, - The API does not offer macro style 
commands and its structure is different to the UI through its design.
follow the UI where it makes sense to  but I'm not convinced this can be 
done well in a way that also gives us a good API (in the short term anyhow)

As an argument to this particular case - dealing with objects. Scenes 
give you access to objects, render prefs, tool settings, radiosity 
settings, paint settings and timeline.
Within in blender access to this data is well defined. - timeline in the 
timeline window, radio buttons, render panel and objects in the 3d view.
so having
  scn.scriptlinks
  scn.tools (or toolsettings?)
  scn.objects
  scn.render
  scn.timeline
  scn.radio

All in their own datatypes makes sense, even when compared to blenders UI.

feel free to reply with equally opinionated content ;)
- Cam



-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241