[Bf-taskforce25] operators and context

[Ton Roosendaal]

Hi,

I went over Context as well; it has many unresolved issues, mostly 
because not much has been done with it yet.

Let's try to clearly define the reason we do this:

1) Replace ugly globals in Blender code
2) Provide generic access and re-use of Operators.

The first spec already is quite succesfully in use for 
Window/Screen/Area context. Unresolved is for example "current .blend 
file" or future features like local editmode, multiple scenes active, 
etc. It should be well possible to refine that on moments when we 
tackle the issue, and now stick to how Blender did it in past. Means: 
"G.scene" and "G.obedit" will be just become a Context property, 
effectively like a global, until we make it more local. It makes the 
migration roadmap for 2.5 easier too.

The second spec, Operator re-use, is more complex indeed. The simplest 
case is this:

- Provide Context callbacks based on user defined input (i.e. "Active", 
"Selected" or "Selection Group").

We can implement that first for those actions which we want to provide 
uniform access for (toolbar, menus, hotkeys, multiple spaces, python). 
Those callbacks can also use our generic property system, to fill lists 
with pointers.

For time being, we can also live with a lot of non-Operator calls 
still, like current button callbacks to remove/add constraints or 
modifiers, or to change RGB color of Material. For both we can make use 
of RNA methods to define a uniform access, which gets either set by 
Python or by C code. For example; a buttons window can react to (or 
set) Context, and leaves it from there to RNA to find data.


-Ton-

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

On 7 Oct, 2008, at 18:03, Brecht Van Lommel wrote:

>
> 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.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>