[Bf-taskforce25] 2.5 io scripts design

[Brecht Van Lommel]

Hi Arystanbek, Campbell,

I haven't been following the changes in this soc project too closely,
but checked the branch today. Here's my feedback on the changes up to
now, and some other things I would like to change about the design that
are related.


We should probably rename the "exec" callback in python even though it
works in 3.x. I prefer to call it "execute".

The function "add_fileselect" should not be in context. If we start like
this it's just like adding global functions. I think we should add these
to the windowmanager, and add a wm_api.c file for this.

One thing I haven't found a good decision on yet is "default" parameters
for RNA functions. It would nice not having to pass context manually to
any functions, since it's fixed anyway, but the C functions of course
need it. Similarly the ReportList for error reporting is needed by some
C functions, but requiring it for all C functions is not ideal. So I
want to make it an RNA function flag to specify if these parameters are
needed.

I'm not so sure anymore adding *_api.c files in the editors modules is
ideal. It seemed like a good idea to me to keep the api along with the
editors code, but now I also noticed that in practice, properties are
part of the API too, and that it has the effect of splitting up that
code over two modules, and it seems more convenient in practice to keep
the RNA code together rather than the API and editors code. So I'd like
to move all *_api.c files to the RNA module.

The scripts space will be removed, what we want is for operators and
such to be integrated natively in the interface. The design for this is
unfortunately not ready yet. What we need is a way for scripts to
register operators into menus, in header, as hotkeys. My idea for this
was to add a way for operators to add themselves to menus and headers
using the identifier (e.g. IMAGE_MT_view). How this fits exactly I'm not
sure yet, just adding to the end is not completely flexible in ordering
of items, especially not for headers ..

Regarding release/io and release/ui folders. What I think should happen
here is that we should have a folder that is scanned on startup, and
just registers everything in there, panels, menus, operators, spaces, it
doesn't matter. Different folders should be used to organize files, but
should no other specific effect. One of the reasons for this is that
it's possible to distribute scripts as a single file then, even though
they may come with UI code, operators, spaces, etc.

Operators should not have a self.__operator__ property, self should be
the operator itself, just like panels.

The functions copy_mesh_data and copy_applied I don't like. When you
want to access a Mesh with all modifiers applied, I think this should
not involve modifying the actual blender database. What I think is
needed is a function that gives you the object evaluated for render,
with dupli_list and modified_mesh properties. What I'm not so sure about
here then is who owns that object, it seems to me that it needs to be
freed after the script has finished, and when the object is modified, to
avoid any data corruption. But how that would happen in practice I'm not
sure.

Regarding the generic RNA collection add callback. There should not be a
default implementation for arrays for such a thing, it should always be
implemented manually. The other thing is that it needs function
parameters in some cases, which isn't easily supported through a
callback like this. Perhaps then such an add function should be a
standard RNA function on a struct, like object.add_modifier, which has
an alias as object.modifiers.add, and similar for remove.

Brecht.