SG-14250: Disables window closing during loader2 actions to prevent crashing#28
SG-14250: Disables window closing during loader2 actions to prevent crashing#28thebeeland wants to merge 1 commit into
Conversation
…a single, tabbed window on OSX. Disables window closing while loader2 actions are in progress to prevent a crash.
There was a problem hiding this comment.
Hi Jeff, nice job figuring out the source of these two problems!
From our discussion during dailies, it seemed to me that these problems weren't only in AE but also Photoshop and potentially integration that runs Python as a subprocess, namely Unity. Because of that, it seems to me that these fixes should probably be deeper in our code.
What do you think?
| # tabbed together into a single window on OSX. | ||
| if sys.platform == "darwin": | ||
| from sgtk.platform.qt import QtCore | ||
| dialog.setWindowFlags(dialog.windowFlags() | QtCore.Qt.CustomizeWindowHint) |
There was a problem hiding this comment.
Should this fix be in tk-core instead? I think this problem happens in Photoshop as well, right? Maybe in the TankQDialog?
| self.parent.engine.import_filepath(path) | ||
| # If the loader2 dialog is closed during processing it causes some stability problems | ||
| # on Windows and OSX. We'll just not allow it to be closed while we're working. | ||
| top_level_widgets = [w for w in QtGui.QApplication.topLevelWidgets() if isinstance(w, TankQDialog)] |
There was a problem hiding this comment.
I'm worried here that we're using a class that is part of the internal API of Toolkit. It's unlikely to change, but it's still not part of the official interface of tk-core, which means that accessing it makes it official and we'll have to support this down the road.
From my understanding, during the meeting today you said that this was both an AE and a Photoshop problem. It's also very likely a Unity problem as well. So it's starting to look like a pattern. Maybe this fix should go in the loader app instead. In there we can easily call self.window() and edit the window flags for the current window only. If this sort of issue becomes more common place in other Toolkit apps then we can start thinking of another way to fix this and at least we won't have introduced a dependency on TankQDialog.
What do you think?
We've always had stability issues with our integrations in Adobe CC products (PS/AE) when a dialog is forcibly closed during a long-running operation in the application. This fix disables the ability to close the loader2 dialog while an action is in progress.
This also tweaks the window flags of dialogs spawned by the integration to ensure that sgtk apps will launch in their own windows instead of being tabbed together into a single window on OSX.