-
Notifications
You must be signed in to change notification settings - Fork 129
Publisher: Prepare publisher controller for remote publishing #3972
Publisher: Prepare publisher controller for remote publishing #3972
Conversation
…actions and validation errors
…o feature/OP-4194_Remote-publisher-controller
Houdini 19.5 with python 3.9:
|
Should work now. I swapped arguments. |
another one:
|
Good catch. Should be fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is still looking like some bug. The editorial publishing had finished at 100% and the bottom bar is green like it was successful publish but as the image is showing It says the publishe was paused and I have to hit Publish button to continue
Notice the log is showing that all plugins were completed.
When I hit Publish as it was suggested to me, then this happen:
Traceback (most recent call last):
File "C:\CODE\__PYPE\OpenPype\openpype\tools\publisher\widgets\publish_frame.py", line 513, in _on_publish_clicked
self._controller.publish()
File "C:\CODE\__PYPE\OpenPype\openpype\tools\publisher\control.py", line 1928, in publish
self._start_publish()
File "C:\CODE\__PYPE\OpenPype\openpype\tools\publisher\control.py", line 1949, in _start_publish
self._publish_next_process()
File "C:\CODE\__PYPE\OpenPype\openpype\tools\publisher\control.py", line 1993, in _publish_next_process
item = next(self._main_thread_iter)
StopIteration
Yep, fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no additional problems in Houdini
pure awesomeness |
Brief description
Preparation for remote publisher UI. Controller was modified to not be Qt based and the import of base Publisher controller does not require available Qt binding in python/sys path.
Description
Main change is that UI does not have ability to work with logic related objects directly (e.g. with creators, publish plugin or their actions). For that purposes were created warpper classes that hold just information and reference to real objects. They can be serialized and deserialized so they can be passed across processes. Attribute definitions have required attribute
type
and can be serialized/deserialized too.CreatedInstance
has prepared few helper functions to recreate data and pass their changes to origin object. Creators are wrapped intoCreatorItem
which contain all information needed for UI and to trigger it's logic. All triggered events in controller must contain only json serializable data which simplified some logic. Attribute changes that were "dynamic" now have explicit setters which trigger event about the value change which helps to send that information from client controller to remote controller.All of that is based on object idenfitiers as strings. For instances is used instance id for creators it's their identifier for actions on publish plugins it's their ids. Asset document ids are for UI purposes also converted to string.
Idea is that one controller is running in client (DCC) and second controller in different UI process. There must be 2-way communication between them so controller in client can send data to process where UI is running and UI can trigger callbacks on client side.
Additional info
Remote controller is not tested and will probably require some tweaks and changes based on first feedback (probably in Unreal). This is preparation PR to make the feature available the default behavior should still work the same way as before.
Testing notes:
PR is based on branch from this PR.