Support for Comments


#1

Hi all,

Just finished writing a first draft of support for making comments in Pyblish QML.


This PR enables the user to include a comment with his publish.

comment_basics

Implements #9.

Format

Comments made via the editor is stored in the comment data member of the context, as a single block of text.

context.data["comment"] = "Summary goes here\nDescription goes here, on a new line"

This is similar to comments on Git commits, the first line being dedicated to a short “summary” of your overall commit, with an (optional) longer description.

You can just add a summary, just add a description, or both. The first line always results in the first line of your comment.

Features

  • Automatically show comment on presence of context.data["comment"]
  • Remember comment across resets
  • Dedicated signal commented for optional data persistence
  • Maximisable, type out your excellent comment in fullscreen
  • Comment template, provide users with a starting point of guidelines for their comment.

comment_fullscreen

comment_persistence

Signal

A signal is emitted when entering a comment, so as to support data persistence, e.g. in Maya or on disk.

from pyblish import api

def persist(comment):
   # write to disk here

api.register_callback("commented", persist)

The comment can then be read via e.g. a Collector into the Context which would then become visible in the GUI.

from pyblish import api

class CollectComment(api.ContextPlugin):
  order = api.CollectorOrder

  def process(self, context):
    context.data["comment"] = # read from disk here

#2

Very nice work @marcus!

Hope to get back to pyblish-qml one day.


#3

This is cool. I wonder if allowing persisting of any input type could be possible, to support use of simple forms?


#4

Yes, you can do that by adding comment to the context.data dictionary. It will then appear to the user on launch.


#5

That’s not really what I had in mind - allowing input of any input type, to support customisable publishing forms. Admittedly this is a pipedream right now.

So clicking another button might bring up a form I’d designed, with multiple text/select/option style inputs for example.


#6

Ah I think I understand.

I’d be happy to review a fleshed out version of this idea; Who is it for? What problem does it solve? What does it look like? How do you use it? How not to use it? Perhaps along with a few sketches, mockups or animatics.


#7

Well - for the scenario I’m thinking about I’m talking about capturing data that is to be stored in a production tracking tool against a shot. This information isn’t available within the file itself.

So for example, for a stop motion animator, we might want to publish a frame sequence and also capture the unit it was shot within.


#8

Have you considered relying on making an external query during publishing, to figure out things like units?

For example, if you set an environment variable before launching your application, such as UNIT, then could read this during publishing.

import os
from pyblish import api

class IntegrateFrameSequence(api.ContextPlugin):
  order = api.IntegratorOrder

  def process(self, context):
    unit = os.getenv("UNIT")
    # write to disk

If the information isn’t available until it reaches the animator who publishes the sequence, then you could have him “create” an instance that is later collected by Pyblish. For example, if publishing from disk you could have your animator produce a metadata.txt file with UNIT=24 inside. If this file is available at the time of publish, then it is read and included. You could go further and provide a GUI towards this file that the artist can interact with. Then, when published, the information could be included.

I wouldn’t recommend having the artist enter it during publishing, as it would mean the information would require re-entry for the next version. It’s important all information has already been prepared up-front when publishing. In this case, the information could be decided even before shooting, such as in a database like ftrack of Shotgun. Pyblish could then ask for it from there.

A comment is one of the few real outliers to this approach, as the comment depends heavily on what the artist did just now and is hard to predict or pre-configure elsewhere.

Does that make sense?


#9

That’s one approach, but I can’t see it being used in the scenarios I’ve worked on. It would require maintenance of the metadata and places a dependency on environment vars/configuration file. Unit is just one example, for dynamic attributes like the specification of hardware being used etc, they really need to be added at the time of publishing.

I could see something like a metadata file being used in tandem, i.e Provide an interface for entry and create the metadata (file or otherwise) to query for the next time, allowing it to be updated if necessary.


#10

Hey @ian

It sounds like you are collecting data from the user. You could make a collector that makes an input UI to collect data from the user.


#11

Yes, that’s exactly what I’d be doing…But isn’t that exactly what a comment is too, some dynamic data that needs to be collected from the user on each publish? If I could attach collectors to the UI in the way that this comment does, I could see that approach working.

I think I’ve high-jacked this thread a little with feature list requests. Apologies, this was only a pipedream in my mind.


#12

Not an issue, dreams shape the future. :slight_smile:

For this functionality, what do you think about specifying these things in your asset management solution, such as Shotgun?


#13

You mean post publish? I guess I envisage that these attributes would all be ‘set and forget’ from the publishing interface.

From a ux perspective I’d rather not make publishing a two step process where animators need to publish and then modify default attributes or otherwise via another tool. That’s how we’ve previously run things and it’s worked well.


#14

I’m thinking pre-publish, when you create and set properties for a shot.


#15

Oh I see. Again, seems like it’s complicating the process due to a technical limitation - adding a step where there wouldn’t ordinarily be one.


#16

Ok, I understand. Thanks for your patience in breaking it down!

If you put together a breakdown of your ideal workflow, along with an example scenario with a problem this helps solve and perhaps a drawing or mockup of sorts in an Issue on GitHub I think that would really help see this feature through.

If you’re up for a challenge, then you could submit a PR with some starter or working code, I’d be happy to review it.


#17

This has now been released!

$ pip install -U pyblish-qml
$ # Or
$ cd pyblish-qml
$ git pull