First, it would be great if there were an option (either Monitor- or pane-level) to only visually group jobs by batch name if the batch name occurs more than once among all jobs. This logic would be applied before any filters in a Jobs pane, so if you had two jobs with the same batch name, and your Jobs filter only showed one of the two, that one job would still appear under a batch item. The use-case for this involves a user or process submitting a single job that may or may not spawn other jobs in the future. Right now, achieving similar behavior involves having the job modify itself at runtime, either using something like a web service script, or by directly updating its Mongo document and then touching LastWriteTime (assuming this is still considered a “safe but unsanctioned” thing to do).
Second, I would love to see Expand All/Collapse All buttons or context menu items in the Jobs pane when batching is enabled.
Finally, I know we’ve mentioned this previously, but it would be cool to see multi-level batching in the future.
Thanks for any thoughts or consideration on any of these.
Can you elaborate on why you wouldn’t want single jobs to be grouped in a batch? I understand that in older code we weren’t surfacing all the columns of the underlying Jobs in the actual group entry, but in newer versions (I can’t remember exactly when we changed this, but it’s definitely pre-8), I believe all the columns in the batch entry should be getting pulled straight from the single Job below it. Is it just an aesthetic thing, and that it’s a bit weird to have single-job groups?
Your second suggestion should be fairly straightforward to implement, I’ll add this to the todo list for v8
Third – regarding multi-level batching – some of the behind-the-scenes changes forthcoming in v8 help lay the groundwork for this in the future, but I don’t think we’ll be exploring this for 8 yet. We’ve already made tons of changes to the model code in 8, and I’d rather have a chance to let it ‘sit’ for a bit to make sure it’s solid before moving on to more crazy stuff.
Aesthetic, yes, but also informative to the end user. Within the context of some of our high-level automation code, we want to generate a single job with a batch name, and then if that job ends up generating more jobs, those new jobs would end up being grouped with the original job automagically. However, if no more jobs were generated, the fact that the first job wouldn’t be in a visual group provides the user with a piece of information for free up front (“This job didn’t create any more work”) without having to click on anything.
Makes sense to me. Just want to keep it on the radar.
Agree wholeheartedly. We have the same workflow, and the (1 job) batching is distracting / redundant. Due to this, most people ended up disabling job batching in their monitors completely.
Might be a lot of buttons, but I’m sure we can figure something out that looks nice
As for the other two feature requests in this thread… Hypothetically speaking, if both of these features existed, how would you expect those two things to behave together?
As an example, say you want to set up multi-level batching based on the following hierarchy: Shotgun Project -> Shot -> Task (which are in ExtraInfo columns).
What would it look like if you had one project that only had a single Shot? Would the hierarchy then be only Project -> Task until there’s another Shot? What if there’s only one task in that single shot? Jobs right under the Project?
How would you differentiate a Project that had one shot with multiple tasks, versus a project with several Shots that only had one Task each?
To me, having single-entity groups not ‘exist’ as a group would make this kind of setup extremely confusing. I just wanted to confirm your thoughts on how this would work before I (hypothetically) code myself into a corner
Yeah, I don’t know if buttons are necessary for the latter options. If the current left/right arrow key expand/collapse behavior (which I think is a default behavior of QTreeWidget/QTreeView) worked on all selected batches instead of just the most recently selected, that would pretty much cover it (and similarly, having the little spinner arrow apply the expand/collapse behavior to all selected batches).
In my vision of it, yes, grouping would never be applied at any given level unless there were two items at that level with the same batch.
However, I think it would be important to make this a preference-based feature, because what I’m after almost certainly isn’t for everyone. Maybe two separate options would be needed: One for whether to omit single-member grouping at the top level, and another for whether to omit them for nested batches. That way, if you wanted, you could guarantee that project-based grouping (to use your example) would always be applied, but people wouldn’t have to drill into shot- or task-level groups if they only contained a single job.
Again, yeah, that’s the way I would see it working. Based on the names of the intermediate batch groups, you would immediately be able to tell which group levels were being visually omitted.
The short answer is, “responsible naming conventions.” But since that’s not a given for every client, user control over this behavior would almost certainly be required.
Sure, and again, I understand that it wouldn’t be for everyone, so hopefully it would be possible to make it preference-driven so no one gets confused…
Gotcha, just wanted to confirm that would all be expected behaviour.
I agree it would almost have to be togglable. I was thinking probably at the Monitor/User level. The last thing I’d want is to change it, and then have a bunch of other people screaming at me to change it back
