[Bf-taskforce25] Context/Operator: alternative

[Nathan Vegdahl]

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
>