[Bf-taskforce25] operators and context

Sun Nov 23 11:58:34 CET 2008

Hi,

Multiple scenes inside 1 screen I've tried long ago when experimenting  
with Blender 1.x design. It was immediately dropped because of  
confusing context... a Screen itself is perceived as a single Context  
UI unit, reacting to what a user activates. Users (back then) even  
required a preset to enforce the 'current scene' to be global for all  
Screens in a list. It's also useful to have one area (InfoWindow)  
defining/visualizing entire Screen context.

My suggestion is that such a feature will be better served making  
available on Window level, each with an own list of Screens having the  
same Scene.

Note that allownig multiple Scene contextes means a local 'current  
frame', with multiple object displaylists/states, which is not  
supported yet.

BTW: Modes like "EditMode" or "WeightPaint mode" can be moved to Object  
level itself, like PoseMode currently.

-Ton-

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

On 23 Nov, 2008, at 8:05, Dietrich Bollmann wrote:

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