Fusion: Implement callbacks to Fusion's event system thread #3928
+165
−28
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BigRoy
commented
Sep 28, 2022
Comment on lines
+45
to
+51
| class FusionLogHandler(logging.Handler): | ||
| # Keep a reference to fusion's Print function (Remote Object) | ||
| _print = getattr(sys.modules["__main__"], "fusion").Print | ||
|
|
||
| def emit(self, record): | ||
| entry = self.format(record) | ||
| comp = get_current_comp() | ||
| if comp: | ||
| comp.Print(entry) | ||
| self._print(entry) |
There was a problem hiding this comment.
This is mostly an optimization.
There was a problem hiding this comment.
Warning: I've just found that this logic does not work in Fusion 17.2 (released around June 2021) but does work in Fusion 17.4 since the fusion instance does not have a Print method in the older Fusion.
We might need to introduce a fallback to support older fusion versions.
BigRoy
commented
Sep 28, 2022
Comment on lines
+22
to
+27
|
|
||
| # We don't need to call Test because PyRemoteObject of the app | ||
| # will actually fail to even resolve the Test function if it has | ||
| # gone down. So we can actually already just check by confirming | ||
| # the method is still getting resolved. (Optimization) | ||
| if app.Test is None: |
There was a problem hiding this comment.
As comment explains this will mostly result in less delays (since calling Test() actually called against the main fusion UI).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: