Dev talk:Ref/Requests/Plugin-System

Interface ideas

• Sequence effects should be able to seek on input. (or request several arbitrary frames).

is solved using

struct ImBuf * plugin_sequencer_get_imbuf(plugin_control_t * control, int num_input, float frame);

Show stoppers

private plugin data

There is a problem with private plugin data: If we allow the plugin to store private data to the blend file, it won't have access to SDNA. The problem is serious, since otherwise plugin authors will write non-portable data into the blend file by accident.

There are several solutions to this:

a) we add seperate serialisation / deserialisation functions. plugin_serialize_short(p_control*, char* prop_name, short*) / _int(...), _float(...), _string(...) / same for deserialisation.

a2) just use a simple string representation for data (like a linked list of string key, string val) and force plugin authors to use this.

a3) use bProperties. This is a combination of a) and a2).

b) make SDNA extensible. Store additional sDNA structure in every blend file, that describes used plugins. Plugins register there structs using a string. This would require to integrate makesdna into blender, so that new SDNA can be generated on runtime.

b2) do not integrate makesdna, but make plugin-authors run it on their files and let them register raw sDNA data.

b3) add a reduced version of sDNA (maybe called minisDNA?), that can do struct serialisation only using base types and only with one non-nested structure. This should be sufficient for plugins. Interface to plugins should include a function, that builds a minisDNA from a c-structure. (Otherwise, this is as tedious as a)....) Registration disables the plugin, if alignment is broken and notes the plugin author about that. (If it bails out on compile or on first plugin load for test isn't really a difference...)

Solution a): is simple and works, but forces the plugin author to write tedious serialize/deserialize functions.

Solution a2): doesn't need seperate serialize/deserialize functions, but is very tedious in usage of the parameters. (Not to mention, that it is slooooow...)

Solution a3): maybe not as slow as a2), but still tedious for the plugin author.

Solution b): a lot more work on plugin system side, but the plugin could be rejected on load, if the registered structure doesn't meet makesdna alignment constraints. (And acceptance to add makesdna to the core will be low, I suppose... ;-)

Solution b2): plugins aren't rejected anymore, but plugin authors are forced to work with makesdna. makesdna has to be rewritten to work on arbitrary header-files.

Solution b3): my favorite. If no-one complains, that's it!

final solution: use bProperties for data representation, but change them, so that we can bind instance data directly to them.

switched to ID Properties. Seems to work.

don't know which image format

Sequencer effects currently use ImBufs as data type, nodes use some other image representation.

There are several problems with this:

• it is pretty hard to write effects, that work in both, sequencer and compositor
• ImBuf is a very complicated structure. Change in structure will immediately cascade through all binary plugins.

Proposal: create an abstract data type, that can be passed down to plugins, which hides this complexity and has the ability to hand width(), height(), colordepth(), rect_byte(), rect_float() up to the plugin as well as copy / new / ... methods.

solution so far: make both types abstract to plugins, make sub_types where possible to create common plugins.

Python Defining UIs

There's a general plan for all plugin types in Blender to use python to define their UIs. Anyway, just thought you should know. I doubt this is a hard-and-fast thing, so if you have issues discuss them in #blendercoders. Though I guess you probably know all of this. (joeedh)

Why should python be of any help here? Why not use a simple C interface like I proposed?

You are free in defining an additional GUI API for the plugins. (Most probably accessing instance variables by properties is the easiest way). But I don't think, that we should limit everyone to this approach, since it means, that I have to learn two programming languages to write a plugin. And I still don't get the advantage using python here. I will most probably get away with around 5 functions in my interface for a decent C GUI, around 15 maybe with all bells and whistles, so what is the point? (peter)