Visual parent navigation

[tokejepsen]

This PR implements #28

Before:

After:

[davidlatwe]

Hi, @tokejepsen, got a few questions for you :)

If I click the Animation at sq001 then jump into Maya or other hosts, am I able to publish my work in this context ? If so, where would it be (file path) ?

I imagine this is for assembling or reviewing all the child assets of sq001 at a higher level ?

[tokejepsen]

I have updated the description with how it looks before this implementation.

If I click the Animation at sq001 then jump into Maya or other hosts, am I able to publish my work in this context ? If so, where would it be (file path)

Yeah, you would be able to publish your work in the sq001 > Animation context. How your config/workflow deals with this, is entirely up to you. Having episode/sequence/shots is existing behaviour in Avalon. Technically they are all just assets in the database.

What this PR focuses on is the logistics of navigating such hierarchies. As you can see before it would just show a long list of assets in the database, even though they are a hierarchy in the Project Manager which supports visual parents.

What might be slightly confusing now, if that the silo is still called "shots" when it contains episodes and sequences as well.

[BigRoy]

@aardschok what do you think?

I am not too sure about how much priority the tasks get when browsing into one of the parents. Logically it makes sense, but browsing to children becomes slower because of the arbitrary amount of tasks you need to "ignore". I am not too sure about this one.

[mottosso]

I actually prefer the previous behavior.

For 10+ shots it might get a little cumbersome to navigate though, but I'm not confident solving that with more clicking is the best approach. Maybe a search field at the top? Default to any keyboard events being entries into the search field?

[tokejepsen]

I am not too sure about how much priority the tasks get when browsing into one of the parents. Logically it makes sense, but browsing to children becomes slower because of the arbitrary amount of tasks you need to "ignore". I am not too sure about this one.

We could put the children at the top, instead of the tasks?

@BigRoy have you guys had a production with episodes/sequences?

[tokejepsen]

For 10+ shots it might get a little cumbersome to navigate though, but I'm not confident solving that with more clicking is the best approach. Maybe a search field at the top? Default to any keyboard events being entries into the search field?

Another way of showing the shots would be similar to how the Project Manager shows it, with a tree view. Although that is a bigger rewrite of the launcher.

[tokejepsen]

Update :)

• Group Tasks.
• Use labels for breadcrumbs.

[mottosso]

Another way of showing the shots would be similar to how the Project Manager shows it, with a tree view. Although that is a bigger rewrite of the launcher.

Actually I think a tree-view is what we have at the moment; they just aren't collapsible. Could it be worth looking into how Pyblish QML does it?

E.g. this

[mottosso]

Or wait, now that I look at it, the "before" gif doesn't make sense at all. The sequences are in the same list as the shots, but not "parented" appropriately.

Maybe it would be a bigger rewrite..

[tokejepsen]

Maybe we should re-evaluate my approach here.

The current main issue is that when having visual parents like in the case of episode > sequence > shots, the Launcher currently does not visually show how the assets are related to each other.

For 10+ shots it might get a little cumbersome to navigate though, but I'm not confident solving that with more clicking is the best approach

How about having a fake tree view?
Instead of fully rewriting the Launcher, we could just visually setup the items in the list to better show their relationship. For example:

ep0010
- sq0010
-- sh0010
-- sh0020
- sq0020
-- sh0010
ep0020
- sq0010
-- sh0010

Maybe there are other better ways of showing this, but this would means we have a long list of assets to select, rather than diving into a hierarchy of assets.

[tokejepsen]

How about displaying the visual parent like this?

[mkolar]

Just a note as it's been hanging here for a while. We've been using this for a while now and it's definitely more convenient than previous behavior. Especially in cases with many episodes/sequences/shots. It's impossible to find anything in the long list flat list, that it was before.

[tokejepsen]

We've been using this for a while now and it's definitely more convenient than previous behavior.

Sorry, what version of this have you used? The traversing or forward slashed flat list?

Also any comments from production?

[mkolar]

Traversing. Flat list is unusable on project with 900 shots. That being said. we only have launcher as backup option and practically no-one really uses it. All artists prefer launching directly from ftrack.

[tokejepsen]

How do we feel about this PR? Think maybe going back to traversing is best then merge.

[jasperges]

Now I know about visualParent, I got this to work. :)
The traversing option would definitely work the best in my opinion. That's what I have now set up for myself.
But like @mottosso mentioned, a tree view might be best. Maybe the same way as in the Project Manager to keep things consistent? How much work would that be? I'm willing to give it a shot, but I don't have any QML experience. Also, does it make sense or would it be better to spend time on Launcher 2.0?

[mottosso]

Launcher 2.0 has become Allzpark, and I'll be putting together a transition guide for this next week once the first release is out. It goes a little beyond what Launcher (1.0) is able to do, and touches on a number of additional important aspect of pipeline management, like how developers distribute software to artists, and how to replicate a local environment remotely, for e.g. rendering and archiving/retrieval and perhaps most importantly how to manage a reproducible environment for projects and applications with associated libraries/dependencies/plug-ins.

The way I'm picturing this visual parent to fit, is by appending a tree-view browser to the current project selection widget.

[jasperges]

@mottosso I did have a quick look at Allzpark. Seems very useful. For now I will simply stick to a 'hacked' version of Launcher 1.0 and later have a more thorough look at Allzpark.

[tokejepsen]

Going to close this PR now.

There are talks about a launcher 2.0 which might address this problem, but also the non-QML launcher by @BigRoy has the tree widget which is much better than any of this.