[Bf-taskforce25] context/operator changes

[Brecht Van Lommel]

Hi all,

I'm working on context/operator changes discussed at Wintercamp, mostly
with the purpose of improving python interaction.

Check this diagram:
http://wiki.blender.org/index.php/Image:Operator_control_flow2.5.png
And example code:
http://pasteall.org/4607/c

The basic idea is sound I think, but I'm running into some consequences
and questions while implementing this, so I'm looking for feedback. See
the XXX marked comments in the code, and the notes below.

properties vs. context
----------------------

When all context data is passed along as properties, it becomes tedious,
not only for the operator code but also for python scripts having to
specify these things over and over. For me it's not clear where to draw
the line. Some examples:

* Does delete objects get scene as a property?
* Does grab in mesh editmode get the selection mode (vertex/edge/face)
as a property?
* Does set 3d cursor get the 3d view space as a property?

in/out RNA
----------

As can be seen in the example code, the operator type and operator now
have separate in and out properties. I prefer this over one RNA struct
with properties tagged for input/output.

poll
----

The poll() callback now only should run when the operator is used as a
tool. This means exec/invoke have to do more verification, since python
may pass in an object that is not in editmode for example, while poll()
would guarantee this otherwise.

poll/input/output names
-----------------------

I've called the get_context/set_context callbacks input()/output(). The
names of these callbacks, and actually poll() is a bit unclear. Longer
names like user_input/user_output/user_poll or
context_input/context_output/context_poll may be better, but are a bit
long?

context RNA
-----------

Context now works with RNA pointers, to get things accessible by python.
However some things currently in the context are not RNA wrapped, like
Base or EditBone. Do we want this dependency of context on RNA, and
assume things will get RNA wrapped in the future, or do we want some
sort of support for putting stuff in the context that is not RNA
wrapped? They could be passed as UnknownType, but that's not so nice.

context global/localization
---------------------------

Currently there are CTX_data_* functions in BKE_context, which look a
lot like globals. In a way they should be global, to permit decoupling
operators from spaces, but I'm not really comfortable with the way it is
now. It's not clear at all what is available when.

I'm changing the context lookups to be based on strings, so that they
become extensible by python. This permits to get rid of these CTX_data_*
functions, but it means what is in the context is effectively
undocumented, and you might get a pointer of a type you did not expect.

Not sure what to do here. Is there a good system to localize and
document this context stuff better? One approach would be to make the
input() callback do more, but then operators again get strongly coupled
to the spaces. Or define context RNA and associated CTX_data_* functions
per module, but it's unclear where that fits.


Brecht.