[Bf-taskforce25] Context/Operator: alternative

[Campbell Barton]

Regarding inputs/outputs for operators

@Joe, agree, some python api calls this could be made less painful, but if
we're getting op-i/o in future releases its not so motivating to put a lot
of time into porting scripts which involve a lot of context switches.

@Nathan,
>> I'm not sure why there is such an obsession to make operators also
directly usable as nodes.
- Agree, even though it could be very cool.

Its useful because it effects how you can use the python api.
Without this you'll need python to setup the selection before operating on a
list of objects.

Could support for this be added without all operators having to be converted
over right away?

This way whenever we need this functionality (from python for instance) we
can add that in properly, rather then writing some python workaround.
Of course blender would need to stay usable during this change over (users
should not notice).

-
-- Campbell

On Thu, Mar 19, 2009 at 8:00 PM, Nathan Vegdahl <cessen at cessen.com> wrote:

> (Note: in this mail I'm referring to the current notion of "operator"
> when I use the term.)
>
> Another thought: I'm not sure why there is such an obsession to make
> operators also directly usable as nodes.  Firstly, I'm not at all sure
> that all operators make sense as nodes (delete object, for example?).
> Nor am I at all sure that all nodes would make sense as operators.  I
> don't really think a one-to-one mapping will work well here.
>
> Perhaps this is another argument for splitting operators into
> "operators" and "tools".  Then we can also have "nodes" which sit on
> the same level as "tools", but still without code duplication.
>
> --Nathan V
>
> On Thu, Mar 19, 2009 at 7:48 PM, Nathan Vegdahl <cessen at cessen.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090319/346cbd1a/attachment.htm