This PR enables the user to include a comment with his publish.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
