[Bf-taskforce25] operators and context
Dietrich Bollmann
diresu at web.de
Mon Nov 24 05:37:43 CET 2008
Hi and thanks,
By the way - as the following might be only of private interest and not
relevant for the current main development focus - if you don't want this
kind of long responses to this kind of topic, just let me know! Don't
want to rob your time... :)
On Sun, 2008-11-23 at 11:58 +0100, Ton Roosendaal wrote:
> 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.
In my private Blender version every 3D view has its own local scene menu
to select the local scene to display. When doing something in a 3D
view, the scene displayed in the relative view automatically becomes
the global active one and - just to give an example - the buttons window
functionality will act on that scene from thereon.
When manipulating scenes from python (from outside of Blender - I am
using other programs which connect to Blender via a socket / command
port) I specify the scene to manipulate from the python code.
This can become confusing: Using the layout shown in
http://formgames.org/blender/multi-scene-view/multi-scene-view.png
(every of the 9 3d Views shows another scene), it becomes difficult to
manipulate the scene in the middle: When moving with the cursor from
the middle 3d view to the button area, one of the other 3d Views will be
crossed by the cursor and the local scene in this view becomes the new
global / active one :)
I currently do not mind as I am using this layout basically to display
scenes and not to edit them. (As I wrote before, I create my scenes
outside of blender in some other program which sends them to blender via
the socket connection. From those scenes displayed I later select one,
switch to a one scene layout and continue to work on the selected scene
in Blender.)
For a more general solution it would probably help to distinguish
between "active" (global / edited) and "inactive" (local, only
displayed) scenes: "Active" can be only one scene, the one which
currently can be edited; "inactive" scenes are just visible but cannot
be edited (until one of them is selected to become the new active one).
Another maybe less confusing solution could be a new area type like
"scene display only view".
> 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.
I am probably confused by the usage of screen and window. So a window
is the thing corresponding to the blender '-w' option? The thing with
"borders around"? And the screen is some area like the 3d view or the
"button window"? Doesn't this break the concept of the "revolutionary
non-overlapping and non-blocking UI"?
How about using the scene menu in the user preferences area for
selecting the "active" scene (the one to be edited) and another one in
the header of the 3D view for selecting the scene shown in the area?
Here another screenshoot:
http://formgames.org/blender/multi-scene-view/scene-menus.png
- The active and editable scene is the one selected in the scene menu
of the user preference area: 'design5';
- the one displayed in the left window would be 'design4', selected in
the view-local scene menu. The scene is only displayed but currently
cannot be manipulated by the edit commands;
- the scene displayed in the right 3D View is 'design5', selected in
the view-local scene menu of the right 3D view. This one is the same as
the "active" one, selected in the user preference scene menu, and
therefore can be edited.
In my version I can toggle the "multiple screen" option on and off using
the user preferences. When toggled off, the interface behaves exactly
like the one in the current blender trunk; when toggled on I can look
at different scenes at the same time and work on them in parallel.
By the way, there is also the option to hide the view-local scene
selection menus using the small "triangle" button on their left side, in
order to easily access the other edit buttons.
> Note that allownig multiple Scene contextes means a local 'current
> frame', with multiple object displaylists/states, which is not
> supported yet.
Everything relative to a scene could be in one scene struct and there
would be only one window-global pointer to the struct corresponding to
the scene currently active in the window.
Concerning my private version I just set the global scene pointer in the
global struct to the scene shown in the 3d view the cursor currently is
in. Yesyes, that is just a hack, but for the moment it works quite well
for me :)
Once again, my way to use Blender is not very common and probably this
functionality doesn't make sense in the main blender development branch.
I just was interested in the new organisation of blender 2.5 and thought
it might be interesting to share my own approach :)
Sorry for another time consuming mail,
Dietrich
> -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
> >
> >
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
More information about the Bf-taskforce25
mailing list