[Bf-taskforce25] context/operator changes

[vekoon]

Well, but my point is that if you leave the operators as they are it 
will still be an artists' tool and you solve the context problem simply 
by passing the Contentx the script was run into (as it works right now). 
This way they'll use this operator functionality exactly as they use 
normal blender but in an automated (script) way. In normal functionality 
they select something and then act upon it (with Tools-Operators that 
is), so doing the same in script side will be fine for them I guess. If 
you do decouple context instead, you're creating 2 different ways of 
using operators, which was exactly what you were willing to avoid.
Also, what if they want to create their own tool that chains some other 
tools and does something more, writing a custom Operator that works for 
scripting will be a greater pain for them and using it as well would be 
such if I'm not mistaken as you have to pass additional information to 
the operator.

On the other hand, you can't ignore developers or extensions writers as 
those are generally tightly related to artists/users but this way, by 
not providing a generic and direct API, you're making things way more 
painful for them or even impossible in some cases.

For instance, how would a custom editor be implemented using the 
operator system? Like let's say I want to add a match moving kind of 
functionality to Blender, how would I do it? (not that I'd have the 
skill for it, it's just an example)
Or let's say that for some reason I want to draw a background image into 
the Graph Editor, or adding a region in 3d view to manage parametric 
objects or custom rig controls or I want to do something like Grase 
Pencil did. Yes you can integrate that into the sources but that creates 
huge problems an extension writer generally doesn't want to deal with, 
especially when he's willing to implement a feature that unlikely will 
be included into default blender as it's too much field-specific.

Having a powerful parallel API for those type of things is somehow 
needed in my opinion as the possibilities it creates are way superior to 
the complexity it causes. This is as much true for extensions writers as 
it is for artists because easier to write extensions in the end just 
means more tools for end users.
Basically, the way I see it, operators would just be high level API 
wrappers for artists to use in a very simple way and without excessive 
scripting knowledge. Direct API access instead would still be possible 
for more advanced usages and extensibility but still maintaining an 
intrinsic simplicity in its approach.


Brecht Van Lommel wrote, on 19/03/2009 3.06:
> Hi,
>
> vekoon wrote:
>   
>> Maybe I'm missing something but I'll try to express my opinion anyway 
>> (it'll be long and boring, sorry).
>>
>> As stated in the design documents for the new operator system the idea 
>> was that Context + Operator creates an Action, but that doesn't 
>> necessarily mean this is the only way to achieve the Action.
>> In fact from my point of view it was exactly the opposite, i.e. it was 
>> the answer to the question "How could we achieve an Action which is 
>> data-independent (so that it's reusable)?" and the answer was Context, 
>> because context is an abstract representation of state-dependent data. 
>> Meaning we could actually translate the above equation to (Data * State) 
>> + Operator = Action. Ok it's not meant to be mathematically accurate, 
>> just to explain.
>>     
>
> This is a good description of the original design.
>
>   
>> The reason Context is used (and thought of) in an atomic way is that as 
>> I said State is an abstract concept, you can't really manipulate it by 
>> itself but it represents the current State in which the Data is and in 
>> which the Action should be executed in. It's like the environment for 
>> the action. So by keeping the Action dependent on the State, because at 
>> any given time you always know what the current State is, you have a way 
>> to keep both separated and to repeat the same Action under different 
>> State conditions. This was the main reason for having State-dependent 
>> Data in the first place.
>>
>> On the other hand, as much as it's true the above statement, it's also 
>> true that Data + Function = Action. In this case the State is ignored 
>> which means the Action is directly binded to the Data. This is perfectly 
>> fine when you have some direct Data you want to act upon which by 
>> consequence means you can only repeat the Action when having access to 
>> that specific Data.
>>     
>
> I guess here you are making the distinction between using an operator 
> as a tool, and in a script/plugin/node. The second use case is indeed 
> what we are trying to improve.
>
>   
>> Now by giving access only to State-dependent data you're actually 
>> forcing a State change every time you want to act upon some Data, i.e. 
>> select objects A and B and then move selected objects. This is a big 
>> limitation in many real-world circumstances.
>> For people who programmed in Win32 or windows in general this is already 
>> obvious by considering the limitations a control like RichEdit forces 
>> upon the developer for which you actually have to first mark the 
>> selection you want to act upon (text of course in this case) and then 
>> invoke the command you'd like to apply (i.e. Make Bold) and which 
>> reflects how you act on it as a user.
>>     
>
> This is exactly why we are making a system that decouples the state 
> from the operator better. We can't immediately do that to the finest 
> level, since there is no time for it. But text editing operators can 
> be extended to take selection as an input instead of the user 
> selection. Similarly for mesh editing and other systems.
>
>   
>> This is the reason why other types of more complex piece of software 
>> like firefox, internet explorer itself and other browsers in general had 
>> to adopt a DOM centered way of manipulating data (those in web 
>> development are perfectly aware of this).
>> This does not mean they dropped Context-based interactivity (which in 
>> their case just means Selection-based). The latter indeed allows those 
>> softwares to generalize an idea of Command (which really resembles the 
>> idea of Tool-Operator in the end) which acts on current Context, can be 
>> automatically described, associated with custom keystrokes, 
>> undone/redone or could even be macroed although they didn't implement 
>> macros as they were really of no use in their case.
>>
>> My "Blender API" proposal actually tried to provide this. It would not 
>> be code duplication in that the idea would be to create a generic API 
>> function like "move object" and then reuse this in both the direct-data 
>> and operator API. Also with a well thought generic API and some minor 
>> changes to my BlenderAPI code we could actually automatize the creation 
>> of bridge functions between the BlenderAPI calling system and normal C 
>> one by generating the corresponding C functions within the makesapi 
>> module which mostly consists of parameters creation/conversion and 
>> should be easy to do.
>>     
>
> This is similar to what we are trying to as I see it, but with a 
> different implementation. The difference is that you make a 
> distinction between an operator and a low level function, while with 
> this design it is all operators.
>
> The reason I think doing it at the operator level is good, is because 
> then the scripting API closely matches what the user does. Blender is 
> an artists tool, not a development API. Having the scripting API close 
> to the tools can make scripting easier, and also means that the tools 
> you use can directly be used in scripts, or as nodes in the future.
>
>   
>> I don't really see how this lower level interaction would be a problem 
>> or how this even is low level for that matter. You can't have a good 
>> level of extensibility if you can't access the data you want where you 
>> want and act directly upon it. Other advanced programs do this and yes 
>> this adds complications, but avoiding the problem is not a solution 
>> especially if it means limiting the functionality a lot.
>>     
>
> The context-decoupled operators would allow you to act on data as much 
> as the Blender data structures and code support it I think. Even 
> inside Blender you should not change any data at any point.
>
>   
>> Not to be rough or anything but to me what "context decoupling" really 
>> looks like is a nicer way of calling an hack to a system that was good 
>> for its purpose in order to make it fit into something it is not suited 
>> for, attaching lot of added complexity to it.
>> My idea is simple: when a py script is run it can get current Context, 
>> i.e. the Context the script was run into. From context it can pull out 
>> the context-dependent stuff it needs (like selected objects)or use the 
>> Context directly to call Operators but because operators are just high 
>> level wrappers around a generic API it really wouldn't need to unless he 
>> wants those commands to be macroed for instance. This way you have a 
>> dynamic system, highly functional and extensible; you make operators a 
>> lot simpler (removing the need of context decoupling) and you let devs 
>> take care of the full potential and the problems this potential may cause.
>>     
>
> Here you describe what operators do currently. If you don't need the 
> operator to be used for scripting there is no point in trying to 
> decouple the context. If you do decouple it, then I don't see how this 
> is more work than the BlenderAPI you propose.
>
>   
>> On a final note (also to kinda strengthen my point) look at Firefox and 
>> all the problems it has: badly documented and full-of-issues APIs, huge 
>> memory usage, complex trickeries to get more advanced stuff working. And 
>> yet it's eating up on market share on every other browser (especially 
>> IE). This is because its add-ons are extremely powerful yet relatively 
>> easy to write, and that's the key. Users search for good functionality, 
>> devs for simplicity so you have to combine both elements in order to 
>> "succeed", even if this means not having a perfect design, which is 
>> impossible to get anyway.
>> Probably I should have avoided this final note as it's mostly irrelevant 
>> but my point is that a complex "low level" API is always needed for a 
>> complex application, you can't avoid it. Otherwise you end up creating 
>> various APIs for various purposes because you find you need something 
>> for custom GUIs, so you create UI templates, then maybe skinning, so you 
>> create UI styles; then you'll surely need a way to create and manage 
>> screen layouts and there's another differently custom API. Then custom 
>> toolbars buttons creation, then menus, then custom editors, then what? 
>> You end up with tons of different custom APIs for doing all the 
>> different things you need to be able to do which in the end will look 
>> exactly like having a single "low level" API but it'll be subdivided and 
>> inconsistent.
>>     
>
> For such low level API stuff, I would still like to use operators, but 
> ones that you don't use as a tool. They'd work quite similar to the 
> BlenderAPI probably?
>
>
> Context decoupling does add complexity. I am however not convinced 
> that it adds more complexity than using the BlenderAPI concept. It 
> would be interesting to compare the code for an operator + associated 
> Blender API function, and the code for a context-decoupled operator. 
> Perhaps something better than either of both can come out of it..
>
> Brecht.
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>