[Bf-taskforce25] operators and context

Nathan Letwory jesterking at letwory.net
Tue Oct 7 22:26:30 CEST 2008


On Tue, Oct 7, 2008 at 8:50 PM, Jean-Luc Peurière <jlp at nerim.net> wrote:
> Le 7 oct. 08 à 19:19, Brecht Van Lommel a écrit :
>> That the space defines the context was implicit in my assumption,
>> should
>> have been more clear on that. The question is how does it do that
>> exactly. Does it just say to the operator, I'm this space type and
>> this
>> is my data, you can figure out what to edit based on that. Or does it
>> really say this is the material that's being shown, and that menu is
>> being executed on this specific property, so that's what you should be
>> editing, without the operator having to know about the space.
>
>
> As I see it, the operator should never have to know which space call it.
> It can interpret the datas passed in context. What are those datas is
> left to the caller.
>
> But the space controller need to call the right operator when a
> command is
> executed, so how the command/(operator+context) matching is done is the
> key, I think. And I'm unclear on how Kaito's code does it.

Very likely we'll have some sort of conversion layer between
controller and view. As I see it our data (model) and controller know
everything about our data. The view essentially should make only
decisions about how things are presented and translating user input
into a usable format for the controller.

Naturally, we'll have data in the view layer, since we want to draw
things, but we should take care to ensure data is never (ever)
modified by the view code. I have to say I'm not into the code either
(it's also been too long :O ) yet.

We have two directions from which operators can be created: user input
and software triggers. This is from the user pov. It is important to
remember that all events concerning this discussion come from our new
event system. Perhaps it helps to not think in terms of "what did the
user press here", but abstract it to "what did the event system give
us".

Scenario:

We have both 3dview and outliner open, and user wants to select our
cube (default scene of course, should go without saying). User clicks
RMB on object in 3dview. Our event system knows that RMB happened in
3dview and generates appropriate operator.
At this point our Model should flag the appropriate data as selected
if it decides that the action can be accepted ( and our operator gets
thrown to the our controller. Actually, to all controllers that are
interested in the event. The controller should know what data should
be shown for its related view, prepares it and sends it along to the
view. In the end we have our 3dview (and simultaneously our outliner)
receiving the operator with prepared data. Our view knows perfectly
how this should be interpreted and shown.

I think there is a need to do some level of conversion between the
different layers, but I can understand that there might be concerns
for performance. I suggest we just start working on it, and first try
to keep the layers separated as much as possible and see after the
first view (3dview?) has been done with a minimal set of operators how
things could be improved if the need arises.

I hope I made any sense to at least one person besides myself :S

/Nathan


More information about the Bf-taskforce25 mailing list