I would say that if a user wants to use more of a standard Pyblish workflow, just let them use the filemenus in the different hosts.
@tokejepsen, do you still have that video of an ftrack Action launching Pyblish? Maybe that would be similar to how Shotgun Apps are launched?
This directly launched Pyblish from Ftrack in the browser. Is this similar to what you mean @dshlai? Guessing it’ll be launched from Shotgun desktop.
Shotgun in Maya is like this:
Most artists publish their work file in the host app, not from the Web UI.
And you were thinking that you’ll have another entry called Pyblish UI... underneath the Shotgun filemenu?
Right now I think its just cosmetics:) You can decide where to put the access to the Pyblish UI. Main point is to have the library of pyblish related code in pyblish-shotgun.
One thing to look out for would be that the pyblish-maya extension, automatic creates a Publish entry underneath File in Maya. This may confuse the users when they are used to go to Shotgun/Publish...
Yeah, that’s where I want to put it (in the Shotgun menu).
I haven’t install pyblish-maya extension yet. In this case I will probably opt not to install that at the same time. I will like to exam that repo as well to see it work under the hood.
If you aren’t going to be using Pyblish QML, then the integration isn’t going to do much for you.
The only thing of interest that I can think of are the plug-ins; the idea is for plug-ins of every host to have access to some basic facilities, such as getting the path to the currently open file through context.data["currentFile"]. That way you can bridge plug-ins by not relying on host-only libraries for that information. The more of that we have, the more flexible plug-ins can get in terms of where they run.
If you have a look at the plug-ins available for Maya (there aren’t many) and either copy those or implement your own, then your plug-ins should align perfectly with other integration packages.
I can provided my own integration if necessary. I am looking at the existing repo to see how the API and convention work.
After some consideration I think option 3 should be the way to go.
Since Shotgun Toolkit API provide several Engine to which the app can be build upon, usually in the form of tk-multi-xxx app. If I want to build app that can be run from multiple platform (i.e., shell, Shotgun Web, Maya, Nuke), this is the way to go.
To start I think I will start with Shell Engine which is the command line interface to Shotgun Toolkit.
We’ll be here if you need any help.
Use Shotgun Toolkit app as thin launcher for Pyblish-QML is working:
- from tk-shell (command line):
- from tk-desktop:
- from tk-maya:
1 Like
I think the extension will be a separate package/repo in order conform to the pyblish extension development style. If I launch pyblish-qml from within the shotgun toolkit environment I should be able to pass the instance data converted from SGTK Context object) to pyblish-qml easily.
Hmm, I think there is some confusion here about the role of the GUI.
Technically, the GUI isn’t running under any of the hosts, like Maya, Nuke or even FTrack. The GUI runs as an individual process (via subprocess), unbound by any other, much like how Maya itself runs.
Practically, you could launch Pyblish QML standalone, and let it run in the background. Then, a host such as Maya would connect with it when it comes time to publish. In fact this is the recommended workflow.
To get a better understanding of this workflow, I would suggest you launch Pyblish QML this way.
# From any shell
$ python -m pyblish-qml
This will launch QML, oblivious to Maya or Shotgun or what not.
And then, connect to it from a host, such as Maya, when it comes time to publish.
# In the Maya Script Editor
import pyblish_maya
# Start listening for commands coming from Pyblish QML
pyblish_maya.setup()
# Talk to Pyblish QML
pyblish_maya.show()
So, the general workflow, whether you use Maya, Ftrack, Shotgun or anything else, is to start Pyblish QML independently, preferably at start-up of the operating system, and then connect independently.
Hi!
I did refer to the pyblish_standalone repo and here is how I run it from within the Shotgun app code:
pyblish_integration.setup()
# ... run inside retry loop ...
pyblish_integration.show()
The launcher itself is a Shotgun Toolkit app but it is really there just to provide context object. The Toolkit code itself does not require any dependency other then Toolkit itself.
For some reason I didn’t get a notification about your reply, sorry about the delay.
Pyblish Standalone is designed to work without a host, purely within the OS, like from a directory. It launches an individual listener that can receive instructions from the GUI, Pyblish QML, in a terminal. I’m not sure it’s a good reference for your Shotgun integration.
Here’s what I think you need.
- Run
pyblish_integration.setup()in your host, or ideally,pyblish_maya.setup()as you will otherwise have to handle threading issues on your own; that is, being able to run Maya commands from a separate thread. If you don’t do this, you’ll deadlock the host. - Run
pyblish_integration.show()orpyblish_maya.show().
That’s it.
In other words, showing the GUI should have little to do with Shotgun; it’s the plug-ins that need to communicate with it.
I would suggest you give Pyblish Maya a go first, gain an understanding of how it works with Pyblish QML, and then think about how you can best integrate with Shotgun.
Thanks, I will try that. Yeah I think I need to understand more Pyblish work as well.
One quick question. So for Standalone does the listener process do the actual publish work while Pyblish-QML act like GUI for the user?
Exactly, it’s the listener process that performs the actual publishing. Pyblish QML is simply the messenger and visualiser, it doesn’t know anything about a host or your plug-ins. It just draws them.
Here is a quick introduction to the topic, called “IPC”, with which Pyblish (the core) communicates with Pyblish QML (the gui).