<div dir="ltr">Hi,<br><br>It seems to me that the context should merely act as some container for that provides some limits for getting access to relevant data (i.e. 3d-view would only ever return objects or bones, buttons window would only return settings on active object relating to ob-data or materials, etc.). An operator would need to have expectations for what sorts of data it can operate on, and will make requests to the context to get data that fits those criteria. The operator would then work on the data it is given by the context, probably needing to know what type of data it is and then delegating to some sub-operator that only works on some particular type of data.<br>

<br>By doing things this way, the viewer/space/whatever creates the context, doesn&#39;t need to know what it needs to supply to a specific operator. In some senses, that is quite good, as the demands of different operators can differ quite greatly. Also, by doing it this way, we can centralise the &#39;obtain appropriate data to edit&#39; issue, so that each operator doesn&#39;t end up implementing it. There would need to be a set of methods to retrieve certain types of data from the context. This is where I think there is a potential level of overlap with Data-API type stuff. We could say that while Data-API is more properties-based, context is more about the structs that those properties come from.<br>
<br>Probably this is just coming from own biased opinions on the matter: reading over this, it seems to quite closely resemble how current Action Editor implementation works. Also the new keyframing code is a bit like this to some degree (bCommonKeySrc being an example of what I envisage the operators working on). Perhaps I have also just restated some of the other ideas presented here in a slightly different way too. <br>
<br>Anyways, that&#39;s just my 2c (NZ) on the matter ;)<br>Joshua<br><br><br><br>

</div>