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