I am having a weird issue with the use of MayaQWidgetDockableMixin.
When I am testing my code in Maya 2017, all the signals within are working. However as soon as I tested it out in Maya 2018, while the Gui shows up, it seems that none of the signals are working.
Eg. The use of dockCloseEventTriggered is not called as the Gui is closed.
Wondering if anyone has encountered such issues before?
If I create a button that connects to a function where within the function contains the dockCloseEventTriggered, it works as the button is clicked.
If not, is there a way to ‘force’ the signals to work?
That mixin seems to have quite a few problems. I think the move to workspaceControl instead of dockControl along with the jump to Qt5 / PySide2 kind of broke the hell out of it.
On the Qt derived front I honestly don’t know.
When I’ve needed to craft a dockable UI I just used a basic workspaceCommand window and interacted with that.
You could probably craft one of those, get a pointer to the underling QDockWidget and use that as a parent for a regular QWidget panel. But that is honestly pure speculation.
And even so, you’d need to route everything through the workspaceCommand function, so very much a hybrid solution.
It seems that, when my tool is docked, anywhere within Maya, and closing the tool (when it is docked), the dockCloseEventTriggered is actually being called! But no when it is Not docked.
This has definitely stumps me. Even so, the solution does not seems to work for me when it is ‘un-docked’ though.
I added some debug code for hide and hideEvent and found that those are getting called instead of close and closeEvent. Once I pointed all the code to the right functionality, it works.
Hi there, thanks for getting back and sorry for my late response.
So, upon replacing dockCloseEventTriggered with the use of hideEvent, it seems to have rectify the issues I was having in Maya 2018! However it is not working when used in Maya 2017. This is weird.
Correct me if I am wrong (since I am not that proficient in Python or PyQt yet), but hideEvent is used if the widgets are hidden right? While it seems to work in my cause, will this cause this any issues (eg. the tool is still running in background etc)?
Seeing that in cases like this, one would presume the use of closeEvent to be the ideal scenario here?
I think if you’re closing the window when hideEvent is triggered, then the window won’t be running in the background, but I haven’t tested that yet. I usually follow the pattern of “When you try to open the window, kill the window if it already exists” when calling new windows.