[Bf-taskforce25] operators and context

[Dietrich Bollmann]

Hi,

On Sat, 2008-11-22 at 17:13 +0100, Ton Roosendaal wrote:
> 1) Replace ugly globals in Blender code
[...]
> 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.

Does this mean that it will be possible to see different scenes in
parallel in the future? 

I mean something like this:

  +--------------+--------------+
  |              |              |
  |   3D view    |   3D view    |
  |  of Scene 1  |  of Scene 2  | 
  |              |              |
  +--------------+--------------+
  |       button window         |
  +-----------------------------+

I actually hacked this together for my private blender version (here is
a screen shot:
http://formgames.org/blender/multi-scene-view/multi-scene-view.png )
but I am sure that other people might find this useful also...

Dietrich


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