Some ideas to quickly toggle multiple instances;
- Family; toggle all instances within family.
- Dragging; click and drag over the check boxes to toggle multiple instances.
2 Likes
I’ll an extra one related to toggles. It would be great if GUI could remember what was toggled from last run. The problem is that if we have many instances and only want to republish 1. We open pyblish, untick most of the stuff, run it and it fails on validator ‘scene saved’. I save and want to re-run only to find that I have to untick everything again. A bit frustrating, considering it happens almost every single time, that some validation fails on the first go.
1 Like
+1.
The way I would implement this personally, is to store attributes somewhere in the scene that are then read in subsequent runs.
You can do this yourself now, by adding a user-defined attribute somewhere that artists could modify, and read this in any of your collectors.
I guess you could also make this more cross host, by saving the data next to the currentFile.
I’d store it in the Instance as publish=False. The GUI already knows about this attribute, and will de-toggle Instance's that have this attribute set.
I meant more like having some meta data next to the scene file, so it become less about storing the data inside the scene file.
Oh, I was actually thinking of that as an advantage.
The Instances that are de-toggled in a scene sounds quite coupled to the scene itself. Storing it in the scene would mean it would persist across computers and remain relevant the what’s actually in the scene at all times.
When you say cross-host, are you looking to have instances stay de-toggled across various hosts too? 
I agree:)
No, there are just some hosts where we can’t interact and store the data in the scene files. Pretty all hosts that use pyblish-standalone.
Having the data next to the currentFile, would mean it doesn’t matter about storing the data in the scene file. Could even become more of a core feature, as it doesn’t rely on the hosts.
Ah, I see what you mean.
Yes, I think in this case let’s stick with how the default CLI does it, which looks something like this.
$ pyblish_standalone --instance MyInstance --instance MyOtherInstance
Basically, passing it along with the command itself. Would that work you think?
How would be that be stored between publishing runs?
Would it need to?
I figure, since you’re passing the command explicitly, you can keep track of what you pass manually. Sorry, maybe I’m not seeing the usage for this.
Do you have an example?
The use case is still the same as before:
But the problem is with storing the attributes in the scene. So instead we would store the attributes in an external file, that we know the location of.
Ah, I see, you mean not calling Standalone by hand via the command-line, but launching it with the same command- line parameters each time and still have Instance be de-toggled at the start of the GUI.
Ok, complex, but I think I understand. 
Storing it in a file sounds like a good idea then, as a temporary space of sorts.
As for implementation, I was thinking of a collector that runs at the end of the collection stage. The collector gets the data from the external file, and injects the instances with the publish state.
Mm, that could work. The only problem would be getting the data out to begin with, as the interface doesn’t modify the Instance's as you toggle.
This is something I’ll have to implement into the GUI me thinks.
Ahh, I see. Didn’t think of that.
I think the way I’ll go about it, is to modify the publish attribute of the current. It would vanish as soon as you refresh, which is why I’d like this to persist in the scene somehow by default. But I can’t see that work uniformly across host and especially not uniformly across the various collectors folks may write. This has been one of the reasons this sort of thing has been put off.
Modifying the Instance as you toggle will at least enable you to store it’s state on your own (during e.g. Extraction) and later collect it. Storing it internally to the GUI is possible as well and would at least make it less painful then and there, with or without this additional collector.
I’m looking to get the toggle state of an instance in the UI, for a different case. Can’t you do that?
There’s no way to do that, no.
I think it will be the same feature, so when this works, that would work too.
Have we got an issue for this?
This feature is really useful when working with the context.