[Bf-taskforce25] data api proposal

[Brecht Van Lommel]

Hi,

Some notes:

* We had some discussion about what happens when you call data API
functions with NULL values, if they should still keep functioning and
not crash. This could make some code shorter and reduce the number of
== NULL checks. I'm not convinced this is a good idea, but Ton thought
it could be handy and reduce code.

* We figured Multiple Choice may not be a good name since it doesn't
really say that you have to pick one out of many, rather than zero,
one or more out of many, alternative suggestions are welcome.

* The data API should not include too many UI related things, , it
should separate UI from data level. If we want really customizable
interfaces, then of course some things cannot be static. The question
then is how many UI related settings do you keep in the data API? We
do want to have auto generated data views, but that does not really
require callbacks like uihidden(), or even soft min/max, number
sliding step. It depends a bit on how much you want to generate
automatic or how much you want to define in whatever format the UI
will be defined in. Another possibility is to allow overrides in the
UI code, and use things like soft min/max unless some other value is
specified. We didn't come to a good conclusion about this.

Personally I think:
* Remove uihidden(), i.e. let the user interface code decide what
should be visible when.
* Keep soft min/max, number sliding step in the data api but allow
overrides in the UI code. In a way this is UI level but it is also a
hint from the data level about it's meaning.
* Store UI names and tooltips separated from the data API. In any case
this should allow translation well. Also interesting would be to allow
editing tooltips so users can help documenting Blender. Multiline or
formatted tooltips or integrated docs are interesting here as well.

* IPO's, drivers, expressions, actions, proxies, .. it's a difficult
problem :). No particular conclusion here that I remember. Getting it
all working well requires more than just a data API if you want
arbitrary drivers and such, like dependency graph between any ID
blocks including a material depending on a material depending on a
material, or driving a vertex location with a proxy armature or
whatever. The current dependency graph cannot handle such cases.

Brecht.

Ton Roosendaal wrote:
> 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-
>