Implement Hierarchy View in Scene Inventory App

[davidlatwe]

This enables a better view for hierarchical (nested) subset type like setdress in Scene Inventory App. Able to switch between normal flat view and hierarchy view.

Outdated


Jump to latest

[davidlatwe]

Outdated

About this change on Scene Inventory, next I am going to do is implementing dependency view, for asset type like `lookDev` or `animCurve`. But since the Scene Inventory is *software-agnostic*, those extra checkbox might not suitable for other DCC apps, perhaps these kind of change should be refactored at some point, like moving DCC specific code to `avalon.host`, and let the GUI load them on startup. For now, I'll continue implement the feature for Maya and push them here, then see what need to be changed or refactored when the time comes. Wondering what you think ? Any inputs are welcome :)

[tokejepsen]

Could you elaborate on what you mean with dependency view and how you imagine it looking like?

[davidlatwe]

Thanks @tokejepsen :D

Outdated

Here's some screen shot and mockup on a scene which have a `setdress` type asset loaded: * This is what we currently have now, every thing is flat

PIC


* Hierarchy view, just like gif above Since `lookDev` does not have the hierarchy, they stay on the ground.

PIC


* Dependency view (Mockup) In dependency view, `lookDev` is nested under each `model` assets.

PIC


### Visualize relationships So what I am trying to do is making Scene Inventory to be able to visualize some relationships between containers, since in *Maya*, depend on `subset` type, some of the container may have hierarchical relation, and some of them were in dependency.

[davidlatwe]

Here's some latest progress on hierarchy view...

Outdated

* Implemented version and text filtering. * Implemented version outdated and child item outdated highlight. * Able to properly passing containers to actions. In hierarchy view, subset which version is outdated might hiding in the hierarchy, so I added a yellow color to indicate that. And here's some improvement on both view mode: * Renamed column "name" to "Name" so that able to display namespace on GUI without losing container data. * Able to select GUI items by actions. * Moved action sub-menu to the top. I think the most interesting function is able to select view items by action, the motivation I implementing this was, I was trying to find a way to quickly know which asset assigned that *look* in Scene Inventory, and the implementation of *Dependency view* I mentioned before was making things to complex, so I thought why not use `InventoryAction` to tell me and there it is. Hope you like this.  In above GIF, the action "Lucky Pick" was randomly selecting one item in the GUI from the grouped containers.

[tokejepsen]

Sorry, I'm not actually very useful when it comes to feedback on the Loader since I've yet to try it.

Unrelated to the review, what are those red boxes in your outliner?

[davidlatwe]

Unrelated to the review, what are those red boxes in your outliner?

Oh, it's the referenced subset's group node, nothing fancy except with a custom icon for artist to identify them. :) Thanks !

[BigRoy]

Oh, it's the referenced subset's group node, nothing fancy except with a custom icon for artist to identify them. :)

Clever!

---

Have been unable to check the code yet though but visually it looks like there's quite some stuff here that could be interesting.

[mottosso]

Just want to say, this is stellar work @davidlatwe! I wish I had this in the pipeline I'm sitting in at the moment (shotgun toolkit, yuk!)

[davidlatwe]

I have changed the implementation of Hierarchy view from affecting all containers with a checkbox, to able to cherry-pick with right-click action.

GIF


You can keep cherry-picking as long as there are item to select, and maintain the selection. If the host does not have the concept of hierarchical containers, still able to use as cherry-pick only.

One minor tweaks:

• Previously, right click menu will show if there's any active index, even it's not highlighted, I have changed that. Now the right click menu will only present expand all and collapse all actions, if no item been highlighted. Only when there are highlighted selection will show full menu.

[davidlatwe]

Thanks @mottosso :D, new year is coming, my new year gift from asset artists is counting on this ! (JK)

I have edited the previous comment to point out one minor tweak.

Finally, I hope the combing of cherry-pick and hierarchical view make sense to you guys, I personally pretty happy about this re-implement, since there's only a few types of subset have nested containers, and cherry-picking things could help on managing big scene I believe (able to view in small portion). And the cherry-pick works for all hosts, which I think it's really nice. :)

[davidlatwe]

Here's final sums up about this PR:

Major New Features

• Cherry-Pickable View with hierarchy visualization (Require host to support hierarchy)
• Custom inventory action able to select back if returning a list (, set or dict) of container name.
• Enable custom inventory action to work without item selected. (dce0b51, 3c69e29)

Minor Tweaks

• Changed group node name format from "%s_%s: (%s)" to "%s . %s: (%s)" (8135f92)
• Moved custom actions sub-menu to the top of right click menu for faster access. (3a55f62)
• Child item name and version color is dimmed. (7fbbc24, 0332c45)
• Changed column name to Name, remapped the container "namespace" to item "Name". (d5b5ab8)
• Right click menu will not show all the actions if there's no highlighted (selected) items. (50037e5)
• When entering cherry-pick view, the widget border color will change to yellow as a hint.

[BigRoy]

Great work @davidlatwe!

Some notes from my end on that last summary:

Cherry-Pickable View with hierarchy visualization (Require host to support hierarchy)

So the Cherry-Pick is like an "isolate view", right? It seems nice.

Would it be possible to somehow support the cherry pick being enabled by a specific search query in the filter? Like it would push in "pick:asset-x" in the Search bar so that the proxy automatically filters it.

Did you Implement the Cherry Picking through a Proxy Model? (didn't check the code yet)

Here's a reference for some Query language ideas: https://www.jetbrains.com/help/youtrack/incloud/Search-and-Command-Attributes.html

I was referring to something along those lines.

Moved custom actions sub-menu to the top of right click menu for faster access.

I wouldn't be a fan of this actually. I'd still prioritize the other actions as the ones the Artist would most likely end up using.

Child item name and version color is dimmed.

In the gif to me the children seem "greyed out" and I'm seeing them as "unloaded". Maybe it's just something to get used too - just wanted to let you know how it feels by just looking at the gif. It's a nice helper, but maybe it's slightly dimmed too far?

[davidlatwe]

• So the Cherry-Pick is like an "isolate view", right? It seems nice.

Oh yes ! That's the word I should choose it at first ! I'd like to change the action label from Cherry-Pick (Hierarchy) to Isolate (Hierarchy), it's a much common term for artist, right ?

• Would it be possible to somehow support the cherry pick being enabled by a specific search query in the filter?
• Did you Implement the Cherry Picking through a Proxy Model?

No, not by Proxy Model, it's by passing a set of objectName to the TreeModel's refresh, then filtering against all the containers collected from host.ls(). Something like this:

# app.py
class View(QTreeView):
    def enter_hierarchy(self, items):
        # Action to enter isolate view
        self._selected = set(i["objectName"] for i in items)
        self._hierarchy_view = True  # Will make `refresh` to take `selected` items
        self.hierarchy_view.emit(True)
        self.data_changed.emit()  # Trigger the `refresh`

# model.py
class InventoryModel(TreeModel):
    def refresh(self, selected=None):
        items = host.ls()
        if self._hierarchy_view and selected:
            # Filtering & child container collecting
            ...
            # Build Tree
            while items:
                ...
                    self.add_items(children, parent)
                ...
        else:
            # Build Tree
            self.add_items(items)

So no, I don't think search query can support this. Since it require to rebuild the model to visualize the hierarchy. :P

• I'd still prioritize the other actions as the ones the Artist would most likely end up using.

Yeah, it's true that the other default actions indeed use more often, but what I think was the custom action might be used repeatedly, depend on the function of that action, if there's some action is for selecting or diagnose-like function, then it would be repeatedly accessed. Hmmm, having that said, or maybe I shouldn't put such action in there at first place ?

• maybe it's slightly dimmed too far?

Yeah, a bit too far I agreed, perhaps I'll try increasing the row spacing, instead of dimming the color.

---

Thanks for the feedback @BigRoy !!

[davidlatwe]

• I'd still prioritize the other actions as the ones the Artist would most likely end up using.

Hmmm, I'll revert it back to the original position, since I think the user experience is much more at Colorbleed of course. I shall make it stay that way :)

[BigRoy]

Hmmm, I'll revert it back to the original position, since I think the user experience is much more at Colorbleed of course. I shall make it stay that way :)

Well, it's not only a Colorbleed thing of course. The Avalon core should be much wider than that and targeted much wider too. Anyhow, my feeling is if the actions are so particularly important to be under the tip of the fingers it might be even weird that they are in a submenu? ;)

I'd be happy to run it past the team to double check if you have some good arguments as to why the Actions submenu should be at the top.

Hmmm, having that said, or maybe I shouldn't put such action in there at first place ?

Yes, maybe if it's to be used so often it shouldn't be in a submenu?

So no, I don't think search query can support this. Since it require to rebuild the model to visualize the hierarchy. :P

What in particular is it rebuilding? It's (re)moving the top root nodes, right? I think even that could be possible with a AbstractProxyModel but I can see why it might be even more complex than just doing it in the top model. Note that a ProxyModel could even introduce new items (like perform grouping) but you'd have to write the proxy model yourself.

The code you have for now seems fine though.

[davidlatwe]

I think I have a good start on implementing different view via search query, kind of fun.

Here's a rough demo.

With $, will display hierarchy view, and adding one digit will expand to that depth. (Not picked-able yet) With # will auto expand normal view. With @ will enter headless (group-less) view.

I think we could define some simple query expression, like $<depth> <asset1> <asset2> : <subset> some sort.

What do you think ?

[mottosso]

Would it be possible to keep PRs as small and contained as possible, before introducing more features?

I think the search is good, but am a little concerned it doesn't handle a busy network or server very well. A Proxy model would contain processing to the local machine, and there should probably also be some delay between typing the search query and actually performing the search, so that when a network takes 500 ms to reply typing doesn't appear sluggish.

[davidlatwe]

Would it be possible to keep PRs as small and contained as possible, before introducing more features?

Ah yes, the latest commit should be a good stop point. Thanks for the heads up. :)

there should probably also be some delay between typing the search query and actually performing the search

About that, till the latest commit, it could happen when preforming cherry-pick action, since it will refresh the model, which will have database access.

As for the search query implementation above, the data model get built for all view modes only once at startup until next refresh or data change, when changing view with typing $ @ or #, there only preformed source model shifting.

But in both cases, when typing the keyword to filter out unwanted assets, it's handled in local pre-built model (filter proxy model), so won't be any latency. :P

[tokejepsen]

The search query looks cool!

Is it based on any existing query language?

[davidlatwe]

Is it based on any existing query language?

No, currently not, just got the idea from @BigRoy and trying a workable startup, and only defined those symbols which will not be used in asset naming, for differing default Regex search. Should be another issue for this. :)

[davidlatwe]

Final updates:

• Moved sub-menu back to bottom
• Brighten the child item color
• Reverted 8135f92, since that commit will break the current regex search.

If no other objections, I'll merge this next week (probably Tuesday) :)

[davidlatwe]

About to merging this :)