Update Pyblish window title in Plug-in

Feature Proposals
#1

Problem

Currently it’s possible to change the title of the Pyblish window yet it only updates when set before the GUI launched.

import pyblish_qml
pyblish_qml.settings.WindowTitle = "My Title"

Is this the preferred method?

Because it only updates after the GUI is “restarted” (closed and shown again) this means that Plug-ins can’t set the window title based on the information they collect. As such Plug-ins can’t have any decent effect on the Window Title.

Goal

I’ve been thinking about a way to trigger a window title update, similar to how one sets it.

This could be as simple as:

# pseudocode
import pyblish_qml
pyblish_qml.update_title()

With this a Collector (or any Plug-in) could directly set a related window title based on the current context.

Is this a feasible feature for the UI?

#2

Conceptually, I would like plug-ins to retain the ability to run simultaneously. At one point, there will be multi-processing, and furthermore, processing of any or all plug-ins on a different machine than the one you are on; either for performance reasons, permissions or other concerns.

For that reason, I don’t think plug-ins modifying the window a local host is a good idea.

The practice however I think could be useful, such as updating it with status messages or a percentage of completeness.

The question that need to be asked then is this. Since plug-ins are at the front line of this kind of information, how can we best involve them, without hampering their potential for multiprocessing?

#3

I think once multithreading is an option there should be a way for Plug-ins to identify that they need to be run in a single thread to avoid collision, similar to a lock on variables in a threaded environment.

# pseudocode

class CollectTitle(ContextPlugin):
    threadsafe = False
    
    def process(self, context):
        pyblish_qml.settings.WindowTitle = "0100 / animation"
        pyblish_qml.update_title()

Even if not UI related there might be conditions where a Plug-in should not run threaded to avoid possible conflicts. Theoretically similar control could be taken by giving each unique order values.

The benefit of threadsafe is that it would force it to be on its own and as such avoid conflicts in order, which can be likely when also working with shared plug-ins from others.

Another way would be to instead of using a Plug-in for changing the title it would become an Action that occurs just after Collection has happened. So one would register an “event” of sorts when it (for example) has processed up to an order of 1. As such the Action has access to the collected context.

The benefit of this is that it doesn’t conflict with other plug-ins, plus that it also won’t clutter the GUI as a plug-in.

#4

That’s exactly the kind of thing I want to avoid. I want plug-ins to retain the ability to run simultaneously.

Callbacks might work; have a look at how they work and try to think of how communication can happen. Especially consider what might happen when two plug-ins try and modify the title at the same time, and what the logical outcome should be. Also consider who, how and where the communication link should be established between a locally running plug-in, and the GUI, keeping in mind that establishing contact is a costly process.

#5

In a threaded environment or even when two plug-ins have the same order and the processing order isn’t known up front by the developer then any conflicts are on their behalf. Sure it’s a possible “problem” where, when used without care, will introduce confusing results. Though it’s very similar to two collectors retrieving data from the scene and appending it to a list. Say one separated out the behavior of collecting Joints from the collector of Meshes but they are just stored in the instance.

Once things start running in a parallel (or unknown order) it’s always easier to introduce conflicts. Even when two plug-ins set the same data key on an instance.

It’s unavoidable that in those cases some responsibility has to be transferred to the plug-in developer for the gains in speed/possibilities they get at the same time.

That’s exactly the kind of thing I want to avoid. I want plug-ins to retain the ability to run simultaneously.

Sure that’s a good recommendation, but people will still force an “order” of processing using order values since not everything can run in parallel. E.g. one might need to set values in a database or encode a video, then await its output/results and doing something else with it. Nice here is that it itself defines the order because we intended it that way, but there will be cases where intentions aren’t that clear (or even as much required), like appending to the same list from two plug-ins.

I’d imagine it’s just like another piece of data that transfers from the context, like context.data['"__title_update__"] = True. Where possible I would avoid trying to make additional connections. I wouldn’t imagine one plug-in constantly changing the window title (theoretically it could when processing a heavy extractor, then it could even show “percentages”).

#6

Please feel free to pop open a separate thread to continue discussing multiprocessing.

Sounds possible; have a go and see what works. I’m all for the feature itself.