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