At the moment, the GUI would report any instance for which it didn't result in
True would still appear green. I've been thinking for some time now to include an option to "signal" a result, other than success (i.e. nothing) or failure (i.e. raising an exception).
Something along these lines.
def process(self, instance):
That could then provide the GUI with a hint that "Aha, it didn't raise an exception, but whatever it did shouldn't count as success.
I got this from working with events in Qt, that have both an
As an aside,
accept() in their case stops an event from propagating further. It's likely we could do this too, where an instance would not pass on to subsequent plug-ins. The thing I don't like about that is that we become more dependent on the order of things, and I'd preferably like to keep the floor open for multiprocessing down the road.
Ok, this makes sense. I'm just a little weary as to how practical it is.
Let's keep it in mind for now. What I want are real use cases from the production floor with pros/cons against the only other option. If it turns out that it simplifies things in a majority of cases, then that would be enough reason to build support for it.
We also need to think about how to actually represent this visually, it might require modifying the current check-this, check-that approach.
Permanently active and inactive plug-ins are based on what's registered and what the plug-in itself defaults to. pyblish-lite maintains state internally inbetween resets - so that they remain as they are when a user resets - and odds are pyblish-qml will too. Neither persists them across sessions at the moment, but I don't see why not.
I think the important thing is to not make it surprising, and to retain some power to the developer in terms of what the defaults are. For example, it might not be a good idea to store it globally in a file of sorts.
Haha, like it.