Pyblish_lite: Widget Api

Hi, all.

I would like to base my pipeline solutions on Pyblish but found poor customization abilities for user interface. I need to implement standalone publisher with ability to select files to publish and choose task and asset type to publish.

Also I would like to integrate Pyblish as a tab into ftrack Connect. But found that produce separate window and setup functions like css setup can not be reused.

In this sense I would like to discuss how custom interfaces would be implemented or changes to pyblish_lite to make this feature possible.

I think plugins would be able to generate custom controls. Also structuring widget methods would be useful, just separating important logic blocks into functions, like pyblish_lite.Window.add_tab(), pyblish_lite.Window.make_artist_tab() , so desired functionality would be achieved by subclassing.


Hi @kalemas, welcome to the forums!

My answer may unfortunately disappoint you. :frowning: What you’re looking for is a quite common request, and the simple answer is that Pyblish isn’t an authoring tool. It’s designed for output-only, to be idempotent and not make any changes to any data whilst running. That is to say, anything that needs editing in relation to publishing needs to happen prior to even opening Pyblish, alongside other kinds of authoring, like modeling or rigging.

That said, selecting files (assuming you mean contents in a scene, like Maya) to publish is at the heart of Pyblish and it’s data-driven nature. This is what Collectors do, they identify and designate what data in a given scene, such as a model, and determine its type, or as it’s called in Pyblish, “family”. So if an artist was working on a model, your collector would correctly identify the content being worked on as a model, and apply an appropriate family - for example, models could follow some convention such as all residing in a group suffixed _MODEL or have some attribute e.g. family="model".

You then implement plug-ins to handle this family, such as model, and guide it along its path through validation all to way through extraction and integration to becoming a file on disk and entry in ftrack.

Task falls into that same category; it’s the Collector that gathers information about a scene or environment, such that if your user is working on Animation, then a collector could query whatever mechanism you or ftrack has at your disposal to determine this task. This assumes that an artist is able to choose his task separate from publishing, such as prior to launching Pyblish or via some other user interface.

In this case, you have correctly identify that the Lite (and QML) interfaces make for poor customisation, because they aren’t designed to handle any user input, other than picking collected instances and any plug-in marked as optional = True.

Have a look at how Avalon manages this, along with Pyblish Starter. I believe ftrack, like Shotgun, has some means of users choosing a task as well that I think is well suited for a collector to respond to. In a nutshell, they implement a “task picking” and “asset creation” GUI for the user in order to define what they’re working on and in what context they’re doing it. This should give you much more flexibility than anything of what Pyblish could do; because typically, and what Pyblish was designed to handle, publishing attributes need to be defined and remain constant throughout any pipeline and each version being published, and as publishing is sent across any farm. Such attributes are ideally defined and stored alongside the contents of the scene.

Hope this makes sense, and sorry to disappoint!

Thank you for such quick reply!

I will take a look at Avalon.

The request is about outputing, why one publishing tool should not allow selecting context to publish? I found Pyblish suitable to validate publish artifacts like file set, names and presence of reviewable media, it is not so much but i’d prefer to base my work on mature framework than implementing my own.

I realize that Pyblish have no functionality i request, so if i decide to implement such functionality i count i have to discuss to have a chance it would ever be merged.

And it is not clear that your objections related to another part of my request to divide widget framework into logical parts so one would base his solutions on top of pyblish-lite, and those parts would be maintained and improved in future. At moment i would integrate whole pyblish_lite.Window into my application or built own interface basing on low level components so i need medium layer of classes, like ArtistTab, PublishButton e.t.c. to complete single-windowed approach for publishing with Pyblish. I will also investigate ftrack_connect_maya_publish because as far as i know it use Pyblish.

@marcus what do you think?

Sorry, can you rephrase that? Not sure I understand the question.

I wouldn’t be opposed to an implementation like this, but it isn’t on the map currently to enable that. Both Lite and QML are more akin to reference implemenations to how you would build your own GUI; with all core logic residing in pyblish-base as opposed to the GUI. I would be a little hesitant to complicate a GUI for the sake of using it for everything; but it would depend on how you go about it.

So, yes, if you have some ideas on “components” you’d like to use independently from any of the GUIs, do make a proposal and we can talk about details from there.

Sorry for ambiguity. You stressed that Pyblish isn’t authoring tool so I assumed that it is only publishing tool. I mind that general use publishing tool should be able to aquire everything required to publish arbitrary data, including context and to be able validate data if required (in sence of Maya data it would be External validation service). I realized that Pyblish is not supposed to run that way, but I don’t count this as a strength.

I m not lazy but I m programmer)) so if there is good enough solution for my task, I will use it. I appreciate you trying to make it simple, but dividing into reusable components would make it better organized and more clear.

First of all i 'd separate views into classes: ArtistPage, OverviewPage and TerminalPage, also i d outlined interface for adding tabs (and preventing any tab to be added, or hide them).

Generally I prefer to design interface with Qt Designer, so there is an idea to provide roles to widgets and implement automatic setup in main widget, so it would be possible to design interface in Designer and have very simple implementation.

Do you prefer to discuss this proposal in form of pull request? And if so does it make sense to base request on PypeClub fork?