[Bf-taskforce25] Context/Operator: alternative

[Ton Roosendaal]

Hi all,

I've spent some time today with Brecht evaluating the discussion, and 
the more I looked into it the more it was clear we're overshooting at 
the moment.

Regardless whether the proposals are good or bad - the design proposal 
from Brecht really is high quality - it reveils a serious weakness in 
Blender we then should tackle as well. And that's (if I understand him 
well :) exactly Vekoon's point, the lack of good API definitions and 
quite some messyness on the Blender side (code is still assuming it 
runs in UI).

Knowing the code of Blender quite well, and regarding the amount of 
work already done, I think that such specs better not become pursued 
now. It will add a gigantic extra effort to the 2.5 project of which I 
can't even predict if that's feasible.

I've asked myself and Brecht this basic question:

"Ignoring the script specs, what should we do to get Context/Operators 
work for everything we want with tools, with macros, redo/repeat and 
history stacks?"

With as simple answer: "Not much". :)

Secondly: "what was the real issue we wanted to tackle especially?"

-> Solve the context-defined definitions for "Selection" or "Active".

This for example to allow operators to pass on new 'selections' like 
for Node systems, and obviously for scripters to define custom input 
and retrieve output.

I think it's better to move this feature to the future, especially when 
we have operators really functional and users validating it. For the 
Python API we have to look at a way to make this future proof, and not 
halfway change APIs, but that's well possible if we just stick (for 
now) to this:

-> Python scripts that use Operators will only work within Context

Which already offers a great advantage over what we had, and which 
sticks closely to the starting point that "python should not do what 
user's cannot do".

For example, in the operator case Brecht mentioned:
    TEXT_OT_new(wmOperatorType *ot)
The prefix will just define "this operator runs inside text editor 
context". Period!

For those obvious cases where Python needs to access data outside 
context, like for importing, or Mesh generating or animation system 
manipulations, we can add two easy to build apis:

- A new MAIN_OT_xxx() operator set
   This one can do context-free Main database ops, like adding Images, 
or unlinking (= set users zero!)
- where appropriate, a basic set of RNA data ops.
   This for example for context-free FCurve point insertion.

Moving forward this way will still give a very powerful API to control 
and use Blender via scripting - provided you target at full 
integration. I'm even quite sure you will be able to code good 
importers this way, just using the context-sensitive OBJECT_OT_add 
calls, move it to editmode, and use what we already have (or fix what 
we have).

Lastly; if you look at what we've already achieved, we've improved a 
lot in Blender. If you look at the minimum we still have to do to make 
it work, it's still quite scary. So... let's now work on first bringing 
back Blender to work, and then worry again about new advanced features 
for node systems, scripting, etc.

-Ton-

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