[Bf-taskforce25] operators and context

[Brecht Van Lommel]

Hi,

I'm trying to get a grip on the design of this context concept in 2.5,
but parts of it are quite unclear to me. One of the areas that I'm
unsure about is how operators figure out which data to operate on.

Let's take a practical example, a "delete object" operator. In the 3D
view the delete object operator would work on all selected objects.
However you can also delete objects from the outliner, were it would
work on the objects as selected there (selection state is completely
separate here). One could also imagine a button that would delete the
active object in the buttons window.

There's a few possibilities to figure out this data:
a) The operator is aware of the space it is running in, and knows that
for the 3d view it uses the selected objects, for the outliner the
selection state there, .. etc. Here you could have multiple operators,
one for each case, or a single operator handling all these cases.
b) The operator is directly passed the objects it operates on somehow,
for example through a property of the operator.
c) There is an abstraction that allows you to ask the context things
like 'give a list of selected objects', and then the context can return
different things based on the space, etc.

Case b) is not a ideal solution I think because it makes it difficult to
create custom operators, as the space would need to know about it's
operators. Solution c) seems reasonable at first but it becomes more
difficult as you involve more data like active objects, and object's
materials, copying things from on datablock to another, etc. In a way
case a) means you have smarter operators, while case c) means you have a
smarter context.

Some other examples of operators:
* An "attach IPO to this property" operator. Does it get the property
from the context or is that passed to the operator?
* "Remove object from this group" operator.
* "Select faces with this material" operator.
* "Copy Location from one object to other objects" operator.

So I'm wondering if it is worth trying to decouple operators from the
specific spaces/menus/.. they run in. If we do this you need an
extensive and well defined context and it needs to be ensured that
context is set when the operator runs. In the other case you'd have more
code in operators to adapt to the context.

I'm thinking you should have some abstraction of the context that the
operators don't have to know about, but there should then a list of well
defined context types that exist.

Thid also touches on UI design but it's something that should be figured
out before converting Blender code to operators..

Brecht.