I would like to propose switching to bqt to integrate Qt/PySide2 into Blender for Ayon.
The major benefit is that it allow proper parenting of Qt widgets to the Blender window.
Its use is quite wide spread through the games industry and currently the Ayon integration conflicts with the bqt integration causing an error when trying to show widgets.
Here is the repo: GitHub - techartorg/bqt: A Blender add-on to support & manage Qt Widgets in Blender (PySide2)
Thoughts?
I’m a strong defender of using the native’s UI instead of using third party libs. I already think that the current use of PySide is a bad practice, mostly because it causes a lot of issues with Blender threading system, may affect speed consequently, doesn’t behave identically regarding the platforms and has some strong limits or adds overhead for implementing low level features (with custom props.Collection for example). IMO, if we have to rewrite the code, we should focus on adapting it for a native Blender’s integration.
I’m aware it won’t look the same across hosts and it may be a choice to keep it. But for Blender users, a not native UI integration is very confusing and painful to use (and I’m not talking about devs point of vue, for whom it’s even worse).
That being said, moving to AYON may be the occasion to support two different integrations:
PS: I can read in BQT’s README. “Instead of feeling limited by N-Panel only UI. Do whatever you want.” This is the root of hell and sounds to me like a very bad way to create UIs for artists. An UI must stay consistent, and the freedom left in many DCCs for custom UI’s ends up to an unbearable multiplicity of useless differences and adds a lot of learning overhead. I have many other arguments, but this is simply only my (strong) opinion 
I think you would need to start a separate thread for your concerns tbh as I am wanting address how qt is integrated rather than whether or not it should be in the first place.
That being said, I don’t think it is an issue that will ever be objectively solved as my experience with Blender is that their native ui framework is awful to work with and I would much rather use the framework that I use in all other DCCs as it significantly reduces the amount of maintenance required for cross DCC tools.
Our artists also prefer it as it is familiar coming from other DCCs.
Learning a separate ui framework per DCC is an unnecessary burden when there is an alternative method.
If we were only using Blender and no other DCCs I would be more on your level, but we don’t - it is only one DCC in the large pool of DCC’s we use and I would prefer not to have to give it any more special treatment than is necessary ( it is already demanding enough to support in the first place ).
I think a lot of your issues are due to the current Ayon integration not being ideal, and is part of why I am suggesting bqt as it is a better solution.
For this point:
mostly because it causes a lot of issues with Blender threading system
bqt doesn’t use threading in it’s implementation so that solves one other complexity.
Bump this thread - bqt has had a lot of love recently: