[Bf-python] Detecting when modal operators invoke and execute

[dima glib]

About a moth ago someone has suggested a patch which adds an access to
bpy.ops.ed.undo_history menu items from python:
https://lists.blender.org/pipermail/bf-committers/2016-November/047868.html
There seemed to be no response from the main developers, unfortunately.

You can, in principle, get a log of actually executed operators from
an INFO area and/or window_manager.operators. It doesn't provide
enough information to reliably reconstruct a sequence of user actions
(e.g. for macros recording), but if you're only interested in
determining when an operator was {'FINISHED'}, it might suit your
needs.
https://blenderartists.org/forum/showthread.php?340868-Get-lines-from-INFO-area
https://blender.stackexchange.com/questions/18020/print-all-commands-in-the-info-view
To my knowledge, there is no way to get the list of INFO log reports
directly. If you decide to go this route, you'll probably have to mess
with changing area types and clipboard copy/pasting:
https://github.com/dairin0d/blender-scripts/blob/3b425f028d1d6fc9e6b0021c548dbc582d7a7f97/scripts/modules/dairin0d/utils_blender.py#L1609


On Sun, Dec 25, 2016 at 4:22 AM, James Crowther
<jamesharrycrowther at gmail.com> wrote:
> Hi everyone!
>         Merry Christmas ;)
>
>         Im in need of the wisdom of those on the mailing list :D
>
> My self and my friend Jeremy are currently building an add-on called crowdrender, we presented it at BC 2016. We’ve always wanted to find a way to discover when a modal operator is finalised, either through calling its execute method, or returning {‘CANCELLED’}. The reason being is that we track data from the user’s blend session and stream it live to other machines so that they can co-operatively render a single frame or multiple frames.
>
> I asked a question at the blender conference “Developers - ask us anything” session, Sergey responded to it. Basically we were asking this question I am asking here. Sergey’s response was “yeah we can look into it”. So I am officially following up!
>
> The issue we have is in the fact that when a user uses grab, rotate or translate (or any other similar modal operator). The active_object gets tagged with its is_updated flag set to True on every iteration or every call to the bpy.app.handlers.scene_update_post subscribed handlers.
>
> This means we have to handle a large volume of updates to properties of the active_object such as changes to location, rotation and scale for example. Though technically we can handle this there is an important problem that we have no elegant solution to yet (we have a solution, but it involves a lot of extra processing inside our add-on which could slow down the UI).
>
> Firstly, from an elegance perspective, a modal operator will change the data of the active object, triggering the is_updated flag to be True even when the user has not yet finalised their operation and they may even cancel it. All the while, we’re processing these updates without knowing that the user may just be adjusting something and haven’t yet committed to make the updates final. If we could know that the user is using a modal operator, our process could be far more efficient since it could ignore these updates until the user causes the operator to be executed.
>
> Secondly, undo is difficult to support in the most efficient way possible since every update we process is committed on the other machines, meaning that we are pushing undo levels on these other machines when the user’s machine is not. Though we have actually successfully tested our code supporting undo in this way, it requires us to store many more undo levels on the other machines which we don’t feel very comfortable with since it increases their RAM requirements and there is no definitive way to determine the number of undo levels necessary to cover the user constantly moving an object around using grab for example. To cover the extreme cases here would require us to set a number of undo levels stupendously high with no guarantee it would always work.
>
> We’ve investigated some methods of discovering when operators are invoked, however there seems to be no method available through the python api that advises the user has invoked an operator, at least not to my knowledge. We also investigated if we could inspect the undo stack somehow since this would give us a way to determine what changes had been pushed to the undo stack and therefore what data updates were actually to be processed by our add-on. However it seems that the undo level remains hidden from the python api. We did look at bpy.ops.ed.undo_history() operator, however it seems to only displays a popup containing list of other operators which run the same command with the items argument set to the appropriate undo level. We couldn’t extract the actual data or operator behind each of those levels.
>
> So, my request is (sorry for the length of this e-mail :S) please can someone advise us of a workable method (other than our brute force approach of course!) for detecting when a user has finalised their operator, allowing us to then process this update. We can’t just use C.window_manager.operators list either since if we just used this list as the one true source of edits, we’d miss edits made through other means like a script, or through the properties panel in the 3d viewport.
>
> To add weight to our request, we now have 70 people subscribed to our website and many of those have since contacted us asking for this add-on to be released, which we are eager to do in an alpha build. In fact we have scheduled for release in early January. Despite the problem with the undo levels, we are still happy to release it to a small number of artists who are happy to live with the restrictions in exchange for early access to the software. This is hopefully going to provide us with feedback.
>
> In the mean time and as we continue to develop the add-on, we’d very much like the opportunity to work with the blender developers to find a solution to this problem since it will allow us to help artists share their computer power over what ever machines they have access to in real time.
>
> All the best for all on the mailing list for 2017
>
> James and Jeremy from Crowdrender :D :)}
>
>
> _______________________________________________
> Bf-python mailing list
> Bf-python at blender.org
> https://lists.blender.org/mailman/listinfo/bf-python