Simplifying the GUI

[mkolar]

What I think is the minimum that needs to be in the 'artist' view. When it opens up

• List of instances and ability to toggle them on and off. (practically the same as instances now, but maybe nicer design.)
• Any optional extractors

When it runs
* progress bar, ideally stating what it's just doing

After it finishes
* Any failed plugins so we can run actions on them, look at the problems and deal with them.

Actually concerning the plugins that show up in the 'artist' view. A simple flag in the plugin stating if it should show might be ideal. artist_view = True just like we use order, optional etc. That way developer could control what the artist will see. I might want to show them for example extractors that get the main data out as .abc, .obj. .ma, where some of those might be optional but not necessarily.

[marcus]

Actually concerning the plugins that show up in the 'artist' view. A simple flag in the plugin stating if it should show might be ideal. artist_view = True just like we use order, optional etc. That way developer could control what the artist will see. I might want to show them for example extractors that get the main data out as .abc, .obj. .ma, where some of those might be optional but not necessarily.

That's a great idea.

[tokejepsen]

Actually concerning the plugins that show up in the 'artist' view. A simple flag in the plugin stating if it should show might be ideal. artist_view = True

Sounds like a good idea. Was reading yours, and thinking that I wouldn't have extractor showing:) All studio related taste.

[mkolar]

Hence the artist_view flag.

When we transfer assets between softwares artists like to choose what they are exporting. Also I'd like them to know what is their output, so it's not fully magical in the BG

[BigRoy]

Actually concerning the plugins that show up in the 'artist' view. A simple flag in the plugin stating if it should show might be ideal. artist_view = True just like we use order, optional etc. That way developer could control what the artist will see. I might want to show them for example extractors that get the main data out as .abc, .obj. .ma, where some of those might be optional but not necessarily.

Was thinking along those lines as well, so +1.

I imagined it specifically useful for the Extractors (or even Integrators) if the Integrator has some Action to explore the integrated content on disk. So they might right-click the final output and "browse that location". Where of course browsing that location could be "showing it" through a proprietary asset management system when required, as usual Actions can be anything really. Just keeping in mind that some functionality from the "overview" would transfer to the "artist view".

[morganloomis]

Apologies that I've only skimmed this thread. With regards to plugin clutter, I feel like this could be solved just by grouping the plugins by collectors, validators, extractors and integrators. So by default an artist only sees 4 tasks in the list, and if one of them fails, the group could be automatically expanded to show the details of which plugins failed and why. I think this has the added benefit of drawing attention to the CVEI paradigm, since it's core to the pyblish workflow. Already I've starting prefixing plugins with "Collect: " etc. so that it's clear where the splits are between phases of the publish. I'd prefer that to an artist view, since in this case you'd be organizing information and keeping it accessible rather than hiding it.

[morganloomis]

Sorry just now saw this: https://github.com/pyblish/pyblish-qml/issues/189 which seems in-line with what I was thinking.

[marcus]

Thanks for sharing, @morganloomis.

Let me know if you would like an introduction to the QML or Lite codebases, I'd love to have you implement things!