Add support for register_gui

[mottosso]

Dropping any reference to pyblish_integration and pyblish_qml.

To use.

(1). Launch Pyblish QML, or have Pyblish Lite on your PYTHONPATH. (2). ..

import pyblish.api

# Register multiple; last is preferred, previous used as fallback
pyblish.api.register_gui("pyblish_lite")
pyblish.api.register_gui("pyblish_qml")

# Add to filemenu, like before
import pyblish_maya
pyblish_maya.setup()

(3). Click File -> Publish and witness either Lite or QML launch before your eyes.

For QML, requires 0.7.0

[mottosso]

Qt.py is included for continued support for Maya 2017/PySide2.

[tokejepsen]

Very nice work😀

[mottosso]

Thanks. :)

There is one thing to discuss, which is how the fallback is determined. At the moment, a registered GUI is deemed unfit if it is not found on the PYTHONPATH. But a GUI such as Pyblish QML not only requires inclusion on PYTHONPATH, but also that it's running in the background already.

Other GUIs may also throw an error when attempting to show it.

One potential problem about trying each GUI and seeing whether it fails, is if there are 5 GUIs registered, and each take a considerable time or memory to even try. Maybe that's unlikely to ever have though?

So the question is, should a fallback be used when one GUI fails to show, or when it simply has not been found?

I'd expect other integrations to follow suit on this.

Another question may be about the use of PySide/PySide2 here for the scenario where no gui is registered, and the Publish button is presset. Currently, it shows a QMessageBox with some information. Creating a dependency on PySide/PySide2, requiring the wrapper Qt.py. But it could equally well be written using maya.cmds. The downside, if it even is, is that the code to display this message box would have to be unique per integration, and could not be copy/pasted or shared as it could if it were written with Qt.

[tokejepsen]

There is one thing to discuss, which is how the fallback is determined. At the moment, a registered GUI is deemed unfit if it is not found on the PYTHONPATH. But a GUI such as Pyblish QML not only requires inclusion on PYTHONPATH, but also that it's running in the background already.

I would have thought that you get an error if GUI is not available, so pyblish-maya can cycle quickly through the GUIs.

One potential problem about trying each GUI and seeing whether it fails, is if there are 5 GUIs registered, and each take a considerable time or memory to even try. Maybe that's unlikely to ever have though?

Maybe we should tackle that problem, when it becomes one?

So the question is, should a fallback be used when one GUI fails to show, or when it simply has not been found?

I think its a good idea to have a fallback sequence of GUIs, since it'll make it easier to pick up pyblish-lite instead of pyblish-qml and vice versa.

Another question may be about the use of PySide/PySide2 here for the scenario where no gui is registered, and the Publish button is presset. Currently, it shows a QMessageBox with some information. Creating a dependency on PySide/PySide2, requiring the wrapper Qt.py. But it could equally well be written using maya.cmds. The downside, if it even is, is that the code to display this message box would have to be unique per integration, and could not be copy/pasted or shared as it could if it were written with Qt.

I think it'll be custom per integration. If we can copy/paste, then that's great, so using Qt for pyblish-maya could be reused in pyblish-nuke and pyblish-houdini, but we will need to make a custom message box for hosts like After Effects.

[mottosso]

I would have thought that you get an error if GUI is not available, so pyblish-maya can cycle quickly through the GUIs.

Think about this. When both pyblish-qml and pyblish-lite are registered..

registered = ['pyblish-qml', 'pyblish-lite']

If pyblish-qml is not available, having an error pop up whenever you open pyblish-lite might not be what you want.

Instead, I'd expect it to try, and silently fail until it hits one that succeeds. If none does, then it'll popup the message box, saying none was found (and how to get one).

Maybe we should tackle that problem, when it becomes one?

We could, and probably will, it's just one of those things that would be difficult change in a way that maintains backwards compatibility.

[tokejepsen]

Instead, I'd expect it to try, and silently fail until it hits one that succeeds. If none does, then it'll popup the message box, saying none was found (and how to get one).

Exactly what I had in mind:)

We could, and probably will, it's just one of those things that would be difficult change in a way that maintains backwards compatibility.

More than 2-3 GUIs seem like a reach to me, but I get your point. Could you not fail fast when trying to show a GUI?

[mottosso]

Could you not fail fast when trying to show a GUI?

It's these kinds of things that worry me.

my_gui.py

import heavy_library
import another_heavy_library

def show():
  try_to_show()
  # fail!

And then it goes on to try the next gui.

I guess it could be up to the GUI designer to make sure they only import essentials. We could write it here:

• http://api.pyblish.com/register_gui.html

[mottosso]

Exactly what I had in mind:)

Came to think of a problem with this.

I was thinking of having pyblish-qml and lite registered by default, such that qml is tried and falls back to lite if it isn't found or isn't working.

But the problem is that, trying to show qml when qml isn't running means making a remote connection. And that connection typically lasts 200-500 ms. Which at the end of the day means a delay of half a second every time pyblish-lite is eventually chosen and starts loading.

I thought that maybe we could do it once, and remember that "ah, qml isn't working, I won't try again" but at that point things get complex and too smart. I can just see someone trying, and then setting up qml correctly, only to find that the button no longer does what he'd expect.

[tokejepsen]

And that connection typically lasts 200-500 ms

Does all connections/communication with qml take that long?

Maybe it should be the other way around? lite, then qml?

[mottosso]

Does all connections/communication with qml take that long?

Only those that can't get through. It's the time it waits to hear back before giving up, like a web request in a browser.

[tokejepsen]

I guess you can't assume a lower response time, if qml is active?

[mottosso]

I guess you can't assume a lower response time, if qml is active?

It can probably be tuned to something much lower, that's true, but the point I'd like to make it that other GUIs may have similar or worse behaviour.

Detecting via PYTHONPATH availability on the other hand is more easily controlled and can be tested earlier; such as at startup. I think I'll try this first, until we run into issues. It's easier to go back on as well. Always easier to add complexity than take it away.

[mottosso]

Adding nice dialog should no GUI currently be registered.

[tokejepsen]

Very nice😀

[mottosso]

Also see updated README, with install, Usage instructions and visuals.

• README.md