This repository has been archived by the owner on Sep 20, 2024. It is now read-only.
Fusion: Implement callbacks to Fusion's event system thread #3928
+165
−28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brief description
Implements "save", "open" and "new" OpenPype events based on Fusion notifications of certain events.
Description
Note that the Fusion events may not be 100% reliable. It could still be that a 'different action' might need to be listened to - but these events implemented now seemed reliable enough.
Additional info
This adds a background QThread with the OpenPype menu which will listen to the Fusion events for comp open, save and new comp. This has the downside that IF you were to ever open the OpenPype menu twice (or more times) that the Events will be heard multiple time and each running instance of the menu would then trigger the callbacks to happen.
As such - a next step likely would be to figure out a way for the menu to just get raised instead of re-requested to open if it was already opened for the current fusion session so that only ever a single OpenPype session/menu would be open for that Fusion session. This is difficult with Fusion because the scripts run in a separate background process each, disconnected from the Fusion app process itself.
Likely we'll need to keep a port open on the process that will highlight to fusion that the current process ID already has a menu open, or alike. However, at the same time - multiple Fusions might be open which do each want their own menu. So we'll still need to be able to identify per Fusion session too.
Testing notes: