[Bf-taskforce25] data api proposal

[Ton Roosendaal]

Hi,

I'll go over this with Brecht today as well, report of that will be 
posted here.

Here's a quick note:

There can be a good separation of "data as designed how it should work" 
vs. "data as how users/ui-designers want present it".

For example:

1) Data design level (sDNA, blender executable, .blend files):
- data definition of material color is 3 x float, with unlimited range.
- listview/ipos/python access then is allowed to freely manipulate that
- data api also includes "mods" on top of every property in any 
possible way, like using an expression, an ipo curve, driver or proxy. 
Those things could be closely coded inside or next to the data api? 
This is still the trickiest part... the idea of "ipo blocks" and 
"actions" fight with it. On the other hand, an action currently is 
fully standalone, it writes to channels not actual data.

On this level, usage is fully automated and fully identical whether 
it's a python script or a human interacting.

2) User/Design level: (sDNA, .blend files, scripts?)
- designed UIs (like panels, etc) store themselves the way how they 
want to present data, which data, how to group it, widget types, soft 
limits, slider steps, alternative names, etc.
- For the first 2.50 incarnation we can even still use old buttons 
system for it, until something new was designed. Of course, the new 
"data list view" is a cool new 2.50 feature to add immediate.

3) External design level: (outside .blends)
- translation files (tooltips, buttons, etc)
- scripts for custom UIs, external render configs, etc

Hrms, needs more thinking time this.
Anyhoo; the benefit of keeping 1) as uniform and generic as possible is 
evident for me. All user and ui-design stuff can re-use and modify that 
anyway.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 27 Sep, 2008, at 20:52, Brecht Van Lommel wrote:

>
> Hi,
>
> I've made a proposal on a Blender Data API design:
>
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/DataAPI
>
> I think this is an important thing to get working fairly soon, because
> it would be good for other 2.5 code to have this ready: operators need
> properties, notifiers will need to be introduced and a lot of that 
> would
> be in the data API code, plus UI code would use it to replace a long
> list of uiDefBut parameters. So rather than rewriting that code after
> porting it to 2.5 it would be good to have it use the data API already.
>
> Mostly I tried to get a clear picture of the different required data
> types, required information about properties and integration. For each
> section I've added some issues that are unsure/problematic.
>
> The second part has some prototype code on how I think these structs 
> and
> properties should be defined in practice. This is however fairly
> different from the existing initial implementations by Joshua and
> Campbell which were written in python and based on parsing DNA header
> files. Personally I prefer not to use python but it would be good to
> hear arguments for and against it.
>
> What is most obviously missing from the proposal is IPO's, duplis and
> proxies. I have ideas on how to approach this, but need to think it 
> over
> further, will write more on that later.
>
> So, if you have comments on the proposal, see things I forgot about,
> have ideas about the issues mentioned in the proposal, ideas on how it
> should be implemented, let's discuss them :).
>
> Cheers,
> Brecht.
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>