Another test snippet by Roy Nieterau can be found here: https://gist.github.com/BigRoy/df3f063b8f7c8e4f307254e69278ac6e

My snippet started out as a slightly modified version of his and then grew into this 'full fledged test'.

See discussion here.

Update: now the 'communication' between the Qt app and Blender happens via queue.Queue's. This resolves issues that are probably related to this. Although in the code no 'direct' threading is used, my suspicion is that Qt does use threading in the background and can cause problems.

Thanks for posting this example! I'm also trying to tackle Qt in Blender at the moment. I'm playing around with your code and noticed that if I try to move Blenders main window it freezes the Qt and Blender windows. Any idea why this would happen? I'm not that experienced with Blender and queues in Qt so I have no idea where to start troubleshooting this.

@borbs727 I just updated the snippet a bit. Moved to PySide2 (shouldn't matter, but that is what I use now). Also changed the preferred method to run_timed_modal_operator, because that is what works best. Furthermore the Qt window is now closed when the modal operator is cancelled (when you open a new file for example). Else the window will become unresponsive, because Qt's processEvents is not triggered anymore. And lastly: are you on macOS by any chance? I also increased the interval value in line 84, because I noticed laggy behaviour under macOS when this value was too small. In Linux and Windows smaller values seem to work fine. But 0.01 should still feel pretty responsive... :)

Hey @jasperges, thanks for doing that! All of the windows are still freezing whenever I move the Blender window by grabbing the title bar. I had the same issue with this setup as well Might be a windows thing? I posted my problem on a Blender forum somewhere and they suggested attaching Blender to a debug to see what's happening. I'll look up how to do that some time this week and try to post what I find.

I'm not a mac user but I might get a loaner through work soon so I'll let you know if I experience a performance hit like you were mentioning. It felt great on PC though!

@borbs727 What do you actually mean by "all of the windows are freezing"? (Should have asked this earlier... 🙄 🙂 ). Do they freeze temporarily or permanently? I'm using this for the Blender Avalon integration and so far it runs perfectly on Linux and Windows (only tested macOS quickly at some point). Does this also happen if you use the run_with_timer() method? I actually think that method is better, but you can easily crash Blender if you run a Blender operator from your Qt windows or actually from any timer. Issue mentioned here, here, here and here in bug reports.

Tested under MacOSX (Catalina) and it seems that both Blender and QT windows become frozen. I can't interact with Blender and I can't click on any buttons in a QT window. When I close the QT window, Blender does not restore interaction.

@sshumakov3 If I recall correctly I also had this issue once when testing on macOS. If you use run_with_timer() it should work, I think. But as mentioned earlier, take extra care with the code you run in the Qt app:

I actually think that method is better, but you can easily crash Blender if you run a Blender operator from your Qt windows or actually from any timer. Issue mentioned here, here, here and here in bug reports.

@jasperges It still does not work, at least with Blender 2.83 with any of them. Except for the QT app example, where there is no processEvents() call. The problem is due to the timer events being captured by some other model operator that is running in the background for my case, I believe. So without using the timer event, I am not getting the issue. (e.g. this snippet by somebody else which links to this one works https://gist.github.com/BigRoy/df3f063b8f7c8e4f307254e69278ac6e0). Maybe using bpy.app.timers API instead? Also, is there any reason to not just call processEvents() all the time? I am not noticing any performance decrease by just running it modal without any timer delay.

@sshumakov3 The run_with_timeruses the bpy.app.timers. The processEvents() is called from within the timer (see here). If you don't do this via a modal operator or timer Blender is blocked.

A 'normal' modal operator is mainly intended to use for tools. A lot of actions are modal operators, like moving, rotating and scaling. A modal operator can add extra items to the UI and change the hotkeys. Also it prevents running auto-save and possibly other things as well. Running the timed modal or bpy.app.timers keeps you in 'normal' mode. And running it every 100th of a second should feel quite responsive. :) And if I recall correctly, running with a 'normal' modal operator doesn't work on Linux.

You also might want to have a look at the Avalon integration for Blender. There is still uses bpy.app.timers, but in production I don't have to worry about macOS, so there I switched back to a timed modal operator, because of the problems mentioned earlier.