Warning color indicator

Do we want to indicate in the UI whether there has been any warnings on a plugin/instance?

Colouring the checkbox yellow, would be good indicator that you need to check the terminal if you have the time.

Just to be sure, what are you using to trigger a warning?
Are you using logging to log a warning?

I think having a color indication for a warning would be sweet (if it’s not already in there)! :slight_smile:

Atm we are using logging to log a warning.

Sounds good to me.

Create an issue, and we’ll make it happen. Should be low hanging fruit.

+1 from me. that would be great

1 Like

+1 from me to.

It would be good to not just have success or failure.
I have for the time being sent a signal from my plugins which passes an enum stating its status. I guess it would be more correct to use the results from the context, but that only contains whether it succeeded or not.

Would be perhaps nice to be able to register some statuses and some how return a status from plugins. It could still have the default behaviour of setting it to failed if an error is raised in the plugin.

Edit: Just realised this post is a bit old, and perhaps this was implemented? I didn’t notice any mentioning of warnings in the documentation.

Hey @Philip_Scadding,

This hasn’t been implemented, at least not in pyblish-qml.

Would be perhaps nice to be able to register some statuses and some how return a status from plugins. It could still have the default behaviour of setting it to failed if an error is raised in the plugin.

What did you have in mind of statuses you want to return? Is it not enough with the default logging statuses; debug. info, warning and error?

Haven’t seen it implemented either. I think it’s still open. Yet I’m not sure an Issue was created for it either, since I can’t seem to find one.

@Philip_Scadding do you have a use-case where this could be useful? I think that having some practical use cases can help narrow down what it is that we need and why we need it.

Personally for me (looking at the team) they’d be very happy to have an “error level” between right and wrong, which acts as a warning. Something they should keep in their minds, or take note of in their scene, yet still continue publishing as it wouldn’t be pipeline critical.

Yes, I think we mentioned having a self.log.warning() message be visualised in the GUI by colouring an instance and or plug-in yellow.

It hasn’t been implemented, but it is still low hanging fruit if anyone is interested in taking charge. I try not to implement low hanging fruit and focus on more complex things, so as to give others a chance to contribute.

1 Like

From my part I’m not using the pyblish-qml, just the base framework.

As @BigRoy said an error level\severity would be quite good. For the moment though I’m content to just have passed, warning and failed.

I guess my use case could be:
Your nuke script doesn’t contain a write node. That’s not necessarily a problem, but the artist should be warned. Warnings are OK to ignore.

That said I reread the sections on reporting, and actually yeah that probably could work for me.
plugin would have:

def process(self, instance):
    detailedMsg = "Some more detailed stuff I want to provide to the user, How could you let this Happen!"
    shortMsg = "This Is Really Bad!"
    self.log.warning("%s %s %s", ReportType.Failed, shortMsg, detailedMsg)
    raise Exception()

then received within the validate callback

def validated(self,context):
    for aResult in context.data['results']:
        for aRecord in aResult['records']:
            if aRecord.args:
                reportType, msg, detailedMsg = aRecord.args

The report type is just an enum, but could be replaced with a int dictating the severity.

My only problem now is that the validation gets called at the end of validation rather than after each validation plugin called, so I can’t update my UI as It goes through them. I did have a signal being emited by each validation plugin but that wont contain the report. Ideally I would require a signal after each instance\plugin validation. I suppose this would be like the pluginFailed callback but submitted for success as well, and including the full report, which looking at the code it looks like pluginFailed doesn’t.