[Bf-taskforce25] Context/Operator: alternative

[Ton Roosendaal]

Hi,

I can see the point you make, from python POV it could clarify things.  
However, from current UI perspective I'm afraid it will confuse code  
more. Having the operator/tool unified in one system helped a lot in  
the past 4 months of coding.

Most importantly; a separation wouldn't change anything to the problem  
we have, and that's that creating *real* generic "black boxes" that  
work independently of context is a big issue. And that was the issue we  
tried to tackle. :)

I fully realize that the current usage and definition of "Context" is  
fuzzy in many cases; it has been designed as a way forward, to help  
improving Blender without a need to recode it entirely. It has many  
issues yes, but I think quite acceptable compared to the big steps  
we've already made.

The worst case scenario for Python is just this: "It will be easily  
possible to code highly integrated scripts that fully conform how  
Blender works". Well, how bad is this?

-Ton-

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

On 20 Mar, 2009, at 3:48, Nathan Vegdahl wrote:

> After talking with Brecht this morning I have a couple of ideas to
> throw out there.
>
> First:
> Change the name of "operators" to "tools".
> "Operator" makes them sound much lower-level than they actually are,
> which I think is causing a lot of confusion.  The name doesn't
> communicate well their scope and purpose.  "Tool" matches their use in
> Blender much better:
> - They are highly contextual.
> - They are used directly by the user.
> - They deal with certain aspects of user-interaction (invoke() and  
> modal()).
> - Unless I'm misunderstanding something, there isn't really anything
> higher-level than them other than the actual GUI and event systems.
>
> Second:
> Presuming that the aforementioned renaming happens, we can then create
> something new to take the name "operators".
> These operators would be lower-level, directly operating on data.
> They would be black-boxes that modify input data (or create/delete
> data) based only on passed parameters.  They would have no knowledge
> of context or user input.
>    "Tools" would then call operators to do the actual work on data.
> Tools depend on context, and handle the invoke()/modal() type stuff.
> Tools could even call multiple ops to do more complex tasks, but that
> still require user interaction.
>
> So layers of the system are like this:
>
> UI/events
> --
> Tools (used to be called operators)
> --
> Operators
>
>    The UI is the top-level stuff, the things that the user directly
> interacts with.
>    Tools are... well, tools.  Just like the current operators work,
> they presume a user will either be using them directly, or creating
> macros with them.  They always require context to function.  Tools can
> be called by Python too, but they still depend on proper context.
>    Operators are for scripting and API.  You pass them data and
> parameters, and they do things to the data.  They have no knowledge of
> context.
>
> I think this has a few advantages:
> 1) By splitting things into operators and tools, Blender provides a
> clean separation between functionality (data manipulation) and how
> that functionality is packaged for user consumption (context,
> invoke(), modal()).
> 2) Blender provides a clean API for scripters/programmers to use in
> the form of (newly named) operators.
> 3) Blender provides a clear way for scripters/programmers to create
> new tools that use combinations of existing functionality (write a
> tool using operators).
> 4) And the biggest one: we don't have to do it right now!!!  It is
> 100% compatible with the current design.  It can even be added
> gradually, over several releases.
>
> I hope this all makes sense.  It seems like a clean, flexible, robust,
> and easy-to-grasp system to me.  And it's one that we don't have to
> delay 2.5 for.
> But maybe I'm a bit too enthusiastic right now. :-P
>
> Thoughts?  Comments?
>
> --Nathan V
>
> On Thu, Mar 19, 2009 at 11:51 AM, Ton Roosendaal <ton at blender.org>  
> wrote:
>> Hi all,
>>
>> I've spent some time today with Brecht evaluating the discussion, and
>> the more I looked into it the more it was clear we're overshooting at
>> the moment.
>>
>> Regardless whether the proposals are good or bad - the design proposal
>> from Brecht really is high quality - it reveils a serious weakness in
>> Blender we then should tackle as well. And that's (if I understand him
>> well :) exactly Vekoon's point, the lack of good API definitions and
>> quite some messyness on the Blender side (code is still assuming it
>> runs in UI).
>>
>> Knowing the code of Blender quite well, and regarding the amount of
>> work already done, I think that such specs better not become pursued
>> now. It will add a gigantic extra effort to the 2.5 project of which I
>> can't even predict if that's feasible.
>>
>> I've asked myself and Brecht this basic question:
>>
>> "Ignoring the script specs, what should we do to get Context/Operators
>> work for everything we want with tools, with macros, redo/repeat and
>> history stacks?"
>>
>> With as simple answer: "Not much". :)
>>
>> Secondly: "what was the real issue we wanted to tackle especially?"
>>
>> -> Solve the context-defined definitions for "Selection" or "Active".
>>
>> This for example to allow operators to pass on new 'selections' like
>> for Node systems, and obviously for scripters to define custom input
>> and retrieve output.
>>
>> I think it's better to move this feature to the future, especially  
>> when
>> we have operators really functional and users validating it. For the
>> Python API we have to look at a way to make this future proof, and not
>> halfway change APIs, but that's well possible if we just stick (for
>> now) to this:
>>
>> -> Python scripts that use Operators will only work within Context
>>
>> Which already offers a great advantage over what we had, and which
>> sticks closely to the starting point that "python should not do what
>> user's cannot do".
>>
>> For example, in the operator case Brecht mentioned:
>>    TEXT_OT_new(wmOperatorType *ot)
>> The prefix will just define "this operator runs inside text editor
>> context". Period!
>>
>> For those obvious cases where Python needs to access data outside
>> context, like for importing, or Mesh generating or animation system
>> manipulations, we can add two easy to build apis:
>>
>> - A new MAIN_OT_xxx() operator set
>>   This one can do context-free Main database ops, like adding Images,
>> or unlinking (= set users zero!)
>> - where appropriate, a basic set of RNA data ops.
>>   This for example for context-free FCurve point insertion.
>>
>> Moving forward this way will still give a very powerful API to control
>> and use Blender via scripting - provided you target at full
>> integration. I'm even quite sure you will be able to code good
>> importers this way, just using the context-sensitive OBJECT_OT_add
>> calls, move it to editmode, and use what we already have (or fix what
>> we have).
>>
>> Lastly; if you look at what we've already achieved, we've improved a
>> lot in Blender. If you look at the minimum we still have to do to make
>> it work, it's still quite scary. So... let's now work on first  
>> bringing
>> back Blender to work, and then worry again about new advanced features
>> for node systems, scripting, etc.
>>
>> -Ton-
>>
>> ---------------------------------------------------------------------- 
>> --
>> Ton Roosendaal  Blender Foundation   ton at blender.org    
>>  www.blender.org
>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The  
>> Netherlands
>>
>> _______________________________________________
>> 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
>
>