Skip to content

Conversation

@thebeeland
Copy link
Contributor

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.

…a single, tabbed window on OSX. Disables window closing while loader2 actions are in progress to prevent a crash.
@thebeeland thebeeland requested a review from jfboismenu October 9, 2019 23:49
Copy link

@jfboismenu jfboismenu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants