[Bf-taskforce25] Context/Operator: alternative

Nathan Vegdahl cessen at cessen.com
Fri Mar 20 06:43:47 CET 2009 

> 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).

I'm a little confused what you're referring to here.  Not sure which
part of the discussion these stems from...
Sorry for my thick-headedness. :-)

--Nathan V

2009/3/19 Campbell Barton <ideasman42 at gmail.com>:
> 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
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>

More information about the Bf-taskforce25 mailing list