search

pyblish / pyblish-base

Pyblish base library - see https://github.com/pyblish/pyblish for details.
Other
127 stars 59 forks source link

QML #48

Closed mottosso closed 9 years ago

mottosso commented 10 years ago

I'd like to propose evaluating QML for the GUI portion of this project.

For those new to QML, I would recommend wetting your beaks in these videos.

In a nutshell, QML is the successor of Widgets - officially - and the future of UI development - in my opinion :)

Some of the immediate benefits are.

Whereas some disadvantages are.

Some learning resources.

Discuss!

ljkart commented 10 years ago

What about compatability with Maya and other application, I dont think Maya support QDeclarative(QtQuick)

mottosso commented 10 years ago

Yes, good question.

The way I've been approaching the GUI and Publish in general so far is for it to run as a separate process, outside of Maya and all other hosts, and for it to communicate over an inter-process layer, such as TCP, using ZeroMQ.

From the users point of view, this isn't noticeable - which is important - but for us it means we can develop a single application and have it run identically across hosts, as well as standalone.

This is something I'd propose regardless of whether or not we got with with QML, because even though we are fortunate enough to have some of our hosts ship with Qt, none of them use the same version and some of them doesn't have access to it at all. And so relying on this luxury would mean quite a bit of additional glue to compensate for their differences and quite a bit of additional bugs, compared to the one-off cost of getting started with inter-process communication.

It's something I've been doing internally for other apps and something I'm familiar with and know works well, but this is something we should discuss here as well.

Edited: Better wording

madoodia commented 10 years ago

Very Good Issue! I really like QML, it is so nice. and i promice if you use that you will love it. thanks for your choice marcus. i agree with using QML.

achayan commented 10 years ago

QML will be better a good post about qml : http://jontheechidna.wordpress.com/2012/05/19/my-thoughts-on-qml-and-the-desktop/

mottosso commented 10 years ago

@achayan, nice link!

From the article:

As of now, Qt does not offer a set of common components like we see with the current set of QWidgets.

This article was from 2012 and this has been implemented in Qt 5, as shown in the Qt Quick Controls video above.

ljkart commented 10 years ago

Yeah, this is a nice thought. But if we are thinking somthing outside then even we can consider web apps with huge support of HTML5 and CSS3 with other libraries!

mottosso commented 9 years ago

Hi all,

Here's an update on the GUI/QML front. I've been spending the past week reading up on QML and am now finally able to say I'm comfortable designing moderately complex layouts.

So I present to you, a first cut, complete with animations and inter-process communication.

Architecture

We previously spoke about utilising ZeroMQ for IPC, but a slightly less involved method came to mind which is being used in this example; a Flask server with a RESTful interface. The benefit of this is native support in Python (and other languages) as opposed to the custom-compiled version of ZMQ we'd have to make otherwise.

There is however one major downside; talking back to our tool from hosts isn't as straightforward using this approach, but I think I've got an idea about where to go with that which I'll try and implement tomorrow. It's important as we need to display real-time information about what's going on in a host.

Bottom line is, installing Pyblish along with it's GUI is now a matter if pip install, no compilation or other tricks required!

From here

Next step is running a provider from within Maya, each host in fact, that the GUI will hook into upon start up. From there, the GUI will take over the publishing mechanism, executing each step so as to provide real-time feedback to the user, including the ability to cancel and pause.

I tried my best to match our mockups from the pull-request of @madoodia, and think there's lots of places to go at this point; for one, we'll need a visual method of selecting and inspecting instances - such as which plug-ins are about to process each - along with room for their status updates to take place.

Let me know what you think, and if you want to run it, simply install Qt 5.3 and run it! However, for integration, you'll have to be a little patient as I take her through the steps.

Best, Marcus

tokejepsen commented 9 years ago

Amazing work @mottosso:) Look forward to taking it for a spin in Nuke and Modo!

mottosso commented 9 years ago

Thanks, Toke.

About Modo, there is something you could try out, in preparation for the GUI. I'm fairly confident Nuke won't have a problem with it, but not sure about Modo.

We'll need to start a thread, from Python, and keep it alive for the duration of the Modo process. It'll start when running Modo, and get killed together with Modo upon quitting. In Maya, this isn't a problem, as Python is running continuously; but Modo may launch an interpreter upon running each command and thus kill any threads it starts immediately.

Here's a simple test, if you could run this, and ensure it does count all the way to 10, then we're in the clear.

import time
import threading

def counter():
    count = 10
    while True:
        if count <= 0:
            print "Done"
            return
        print "Number %i" % count
        count -= 1
        time.sleep(1)

t = threading.Thread(target=counter)
t.start()
mottosso commented 9 years ago

Here's an initial version for Maya.

untitled

Featurelist

I'll return with more details on how to set this up.

Best, Marcus

tokejepsen commented 9 years ago

Nice work on the Maya side, looks good so far.

Here's a simple test, if you could run this, and ensure it does count all the way to 10, then we're in the clear.

This is crashing Modo:) I'll ask on the forums about it.

mottosso commented 9 years ago

This is crashing Modo:)

Hah, did not expect that. :)

tokejepsen commented 9 years ago

Waiting on forum respondes but it doesn't look good for python threading according to this; http://community.thefoundry.co.uk/discussion/topic.aspx?f=37&t=75764. Its a year old thread, but I don't think it has been addressed yet.

tokejepsen commented 9 years ago

And python threading has been confirmed not to work in Modo.

mottosso commented 9 years ago

Ok, we may still be able to work around that.

We'll need one of these:

  1. A method (any method) of executing commands from outside of Modo; like Maya's commandPort.
  2. Any way of setting up a server; possibly via a plug-in. How does one write plug-ins for Modo?
  3. Can Lua run in a separate thread?

Can you do some digging?

Overall, smells like a good opportunity to get Pyblish into their heads; running custom GUI's in Modo. That's gotta be gold for those who don't even have PyQt to play around with. :)

mottosso commented 9 years ago

This looks promising from a Lua perspective.

The question is, can Lua do this from within Modo?

tokejepsen commented 9 years ago

Commandports should be feasible; http://sdk.luxology.com/wiki/Telnet

Could probably open a port from the Pyblish startup scripts, and run through that. Personally I haven't used commandports before, so don't know anything about it.

mottosso commented 9 years ago

That.. is archaic. But it will do. :) Let me have a think about how to go about it.

Off the top of my head; I'd imagine that when booting up Modo, we'll also boot up an additional, windowless process. This will act as our server and it will communicate with Modo's telnet client, possibly using this: http://sdk.luxology.com/wiki/Modo_Socket_comms_wrapper

The process could either be started from a wrapper script, or from within Modo through Python's subprocess.Popen.

Either way, this will work just fine!

mottosso commented 9 years ago

Here's the schedule for the coming days, let me know if there's anything you value more or less, or if anything is missing. These are meant to be the highest priorities in a first release of a GUI for Pyblish.

System

General

Run-time

More things will undoubtedly come to mind as we go along, let's make sure to get the most necessary out first and then work our ways towards perfection.

tokejepsen commented 9 years ago

sounds pretty good to me:)

mottosso commented 9 years ago

Additional, non-critical features

Individual plug-in

This can be useful in cases where a user knows he might be violating certain standards and just wants to run it through the test, or if a test failed before and some changes has been made, the user can then run the test in isolation until it works allright.

Inspecting Parent Asset

This is a major feature and will align itself with the Web Frontend when the time is right. In a nutshell, I'd like for users to be able to inspect properties of the asset from which an instance was made.

Inspect, such as visualise any and all information there is about it - such as a thumbnail, original author, preview data such as meshes or additional screenshots, versions (although managing versions is NOT the responsibility of this GUI) and finally, a means of communicating/commenting on a per-asset/instance basis.

Commenting

Of course, we'd like for users to be able to provide additional, human information along with a publish, if any is available to give. This should be possible from an overall perspective - one comment for an entire publish, regardless of how many instances are going out (this may be the most common type of comment) - but also on a per instance basis, in cases where certain instances require special attention.

ljkart commented 9 years ago

Hi Marcus, That was excellent stuff, looking forward to see much more.

Thanks Liju K

On Tue, Nov 11, 2014 at 6:07 PM, Marcus Ottosson notifications@github.com wrote:

Additional, non-critical features

  • Run individual plug-in on selected instance
  • Inspect parent asset of instance
  • Commenting

Individual plug-in

This can be useful in cases where a user knows he might be violating certain standards and just wants to run it through the test, or if a test failed before and some changes has been made, the user can then run the test in isolation until it works allright. Inspecting Parent Asset

This is a major feature and will align itself with the Web Frontend when the time is right. In a nutshell, I'd like for users to be able to inspect properties of the asset from which an instance was made.

Inspect, such as visualise any and all information there is about it - such as a thumbnail, original author, preview data such as meshes or additional screenshots, versions (although managing versions is NOT the responsibility of this GUI) and finally, a means of communicating/commenting on a per-asset/instance basis. Commenting

Of course, we'd like for users to be able to provide additional, human information along with a publish, if any is available to give. This should be possible from an overall perspective - one comment for an entire publish, regardless of how many instances are going out (this may be the most common type of comment) - but also on a per instance basis, in cases where certain instances require special attention.

— Reply to this email directly or view it on GitHub https://github.com/abstractfactory/pyblish/issues/48#issuecomment-62589885 .

mottosso commented 9 years ago

Take a few moments to have a look at some of the proposed user interface additions, here.

Each issue comes with illustrations and animations.

Let me know what you think, and subscribe to the repo if you want to stay on top of what's happening or want to join in!

mottosso commented 9 years ago

This one is ongoing.

mottosso commented 9 years ago

After a couple of months implementing a graphical user interface in QML, here are a few more points I've discovered along the way.

Performance

Performance comes in two flavours; playback and initialisation. Playback performance is good, which facilitates smooth animation and even games. It's pure OpenGL which means it reaps the benefits of the graphics card. Initialisation on the other hand means generating geometry and textures and passing that to the GPU, something I'd expect to take longer but after some tests I might have to change my mind.

QML handles simple tasks about 26x faster in the best case, 42x slower in the worst case, with an average of about 12x faster.