[Bf-taskforce25] PyConstraints V.2 - Proposal + Unresolved Issues

[Campbell Barton]

On Sun, Jul 26, 2009 at 7:02 AM, Brecht Van Lommel<brecht at blender.org> wrote:
> Hi Joshua,
>
> There's similar design decisions to be made in the future for nodes,
> modifiers, etc, would be good to have a consistent design for this.
>
> There's two use cases, one is writing constraints that look just like
> regular ones, i.e. that are always available and can show up in the add
> constraint menu. The other is writing constraints for a specific rig, to
> be bundled with the .blend file. The same thing goes for nodes.
>
> Pynodes and pyconstraints currently cover the second use case, but it
> would be good to take the first one into account too even if it doesn't
> get implemented immediately. Ideally you could handle these two use
> cases with nearly the same code, with the same subclassing and
> callbacks, so you can convert a pyconstraint you wrote for one rig into
> a plugin you can always get available or distribute.
-- snip--

Regarding registration of per blend types via scripts, I have thought
about this a bit and it does cover a lot of areas, potentially more -
custom actuators and sensors.

I think it would be ideal if we can use the same registration system
for both cases if possible.

It could work like this...
Blender loads ~/.blender/ui, io etc are registered.

Then the blend file loads...
 all *.py text files are registered too (could have a toggle option too).

Technically this is not difficult to add though naming overlap is then
possible, still I dont think its so bad (we have it with operators and
linked library names currently).
If you make a constraint for a specific rig it can be something like
"Joes_Arm" constraint which is unlikely to conflict with an existing
one.

irrespective of whats used for PyConstraints Id like to use this for
per-blend operators, so you can have custom tools only in your blend
if you like.