GUI Context Reordering

[tokejepsen]

Goal

To enable the GUI to change the order of its context, effectively changing the order of when instances are processed.

Motivation

The base library can already reorder the context, so without using the GUI, you can change the order of the instances between plugins. The problem is that the GUI has a “copy” of the context, that doesn’t get updated.

The original use-case was to sort the context to a more human readable list of instances; [solved] Collection sorting. This was implemented, but also paved the way for refreshing the GUI’s context. The refresh happens after collection.

Now I have another use-case for updating the GUI’s context, but its between plugins. The idea is to reorder the context with a context plugin, so other instance plugins process the instances in the right order; https://github.com/pyblish/pyblish-deadline/issues/27.
Unfortunately updating the GUI after each plugin, is a significant performance hit, so we’ll have to look at explicit updating, meaning a plugin will have to tell the GUI to update the context.

My suggestion is to have a flag on the plugins, that tells the GUI it needs to update the context after processing the plugin. Here’s an example of such a plugin:

class ValidatorB(pyblish.api.Validator):

    gui_refresh = True

    def process(self, context):
        context.reverse()

[marcus]

Reading your use case now actually rings a small alarm bell in my head.

What are we expecting this to look like visually?

The list of instances would shuffle sporadically at run-time, and what’s worse, one plug-in reordering things would have side effects for subsequent plug-ins, who would be forced to use this new order. What is perhaps even worse, this behaviour completely eliminates any possibility of multiprocessing, as the order could never be changed simultaneously by two plug-ins, without causing havoc.

Now I’m thinking that maybe the GUI does it right, and maybe we’ll need to update pyblish.util.publish() for consistency instead.

[tokejepsen]

The list of instances would shuffle sporadically at run-time, and what’s worse, one plug-in reordering things would have side effects for subsequent plug-ins, who would be forced to use this new order. What is perhaps even worse, this behaviour completely eliminates any possibility of multiprocessing, as the order could never be changed simultaneously by two plug-ins, without causing havoc.

True.

Now I’m thinking that maybe the GUI does it right, and maybe we’ll need to update pyblish.util.publish() for consistency instead.

What do you mean?

The Deadline use-case is rooted in that I need to process the context because the instances need to be submitted in a specific order, to setup dependency rendering. The problem with processing the context, is that the user has no idea of knowing how far the process is. But maybe I should focus my attention on progress bars instead?

[marcus]

The problem with processing the context, is that the user has no idea of knowing how far the process is.

Ahaaa, so you want to process each instance instead so you get visual feedback on the submission.

In this case, I think it’s better to use a local copy of the order of instances within the plug-in and send it across without modifying the GUI, and yes, if you need progress, a progress bar might be the way to go.

Since it will be a single plug-in doing things, we might have to start looking at emitting progress messages to the GUI from the plug-in, as there would be no other way to estimate how long it will take.