[Bf-taskforce25] operators and context

[Diego Hernan Borghetti]

On Tue, 7 Oct 2008, Brecht Van Lommel wrote:

>
> Hi Jean-Luc,
>
> On Tue, 2008-10-07 at 19:04 +0200, Jean-Luc Peuri?re wrote:
>> there is a d) case :
>> 
>> d) the space controller define the context, and the operator that is
>> called when a command is issued, when that space is active.
>> Some spaces dont define their own context but use the general
>>   one (buttons).
>
> 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.
>
>> So in your delete example, if the active context was setup by 3Dview
>> a given delete operator is called, but when the outliner is the active
>> one, it is either a different one or the context being different, it 
>> acts
>> on a different selection.
>
> This explanation leaves open if it works as a) or c). Either you have a
> different operator/code for a different space, or you get get from the
> context the selected objects through some abstraction that works for
> both the outliner and the 3d view. Or am I missing something?

As I can see in the current code, it's more like a), we have "global"
operators called in ED_spacetypes_init (editors/screen/spacetypes.c),
the function is ED_operatortypes_screen (screen_ops.c) and also we
have operators per-space (not in used yet), the function ED_spacetypes_init
go over the space list and call type->operatortypes(), this function
register the opertaor types (or that is what say in BKE_screen.h)

The only space that implemented it is the SpaceTime (I think),
ED_spacetype_time is called from screen/spacetypes.c and set the operator
type to time_operatortypes, that function register one operator
ED_TIME_OT_change_frame, check editors/space_time/time_ops.c

I don't mean that a) is better than b), both have the good and bad side,
in the first case you have operator-per-space, every space have an own
and only-need group of operator and every operator know the data inside
the context, the bad thing is that don't share code, for example in the
previous case (delete an object), both space have different operators
and probably both finish calling the same internal function to remove
the object, so we have duplicate code...

in the second case, we need a good abstraction layer that check the
context, the space, the current data and determine if the action
can take place, but anyway, the layer need know and deal with
the context and the space.. and Blender have different space..
it isn't the same delete in the 3d that in the Sequence, so we need
be careful and don't finish with a big and complex layer abstraction,
that only give problem.

.. so my personal opinion is go for a), the operator need know with
what data work, it's more easy of implement and the code is more easy
to read/work if we need/want an abstraction I think that the best is
that the operator don't work with the data and just send an event to the
space, so every space can register a handler and do whatever they
need to do with the event.. but that is hmhmm the z) option ;)

>
> Thanks,
> Brecht.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25

-- 
 			Diego