As an Artist I would like the context menu in the Loader app to receive some improvements

[FuzzkingCool]

Is your feature request related to a problem? Please describe.

Currently the Loader app context menu is often very slow to load. As well, this menu is generally cluttered with no clear organisation.

Finally, the nomenclature of "import" vs. "load" is not consistent for some DCCs and the actions. For example, in Photoshop

Describe the solution you'd like

1. It would be preferable that when there are multiple representations for a single action, that these are grouped into a sub-menu. I know that there was discussion of having the menu the other way around ( representation > action ) ... either way would be an improvement from a menu that looks like this:
   
2. Get to the bottom of slowness of loading the context menu. Anecdotally, this seems to be especially bad in Photoshop.
3. Consistently use the term "Load" for the label of the Action when it is actually adding metadata to the current scene/file/project, rather than terms like import or the name of the plugin like ImageLoader. Use the label "Import" when you are just bringing the item in with no metadata. Use the term "Open" or "Open & Localise" when the loader will actually directly open a localised sandboxed version.
4. Consistently add "Open & Localise" actions in relevant DCCs. Photoshop and Harmony both would benefit considerably to have this feature!
5. Add config options for filters of which families should appear in a DCC so no menu items that cant be run ever show up.
   ( I could be wrong, but I think this is not yet fully implemented.

[cuID:OP-1044]

[antirotor]

As we discussed, there should be two modes - group by subset and group by loader - so user will set what he need for his workflow. Also - first row should be "Recently used ..." so user shouldn't dive into menu hierarchy for repeated tasks.

For this to work we need to be able to save user settings in Avalon. For that, we can move this piece of code from upcoming pype 3 to avalon and just implement from it Pype related stuff:

https://github.com/pypeclub/pype/blob/3.0/refactoring/pype/lib/user_settings.py

[BigRoy]

@FuzzkingCool looking at the dates this has been in the backlog for a while. I might be looking into this sometime soon. I do happen to have a few questions:

• Are you still actively using OpenPype?
• Are you somewhat up-to-date with recent versions?
• If so, could you confirm what of your notes is still relevant to be problematic to you?

[BigRoy]

@mkolar Since this is a long standing issue with few recent updates/comments. Could you maybe identify from the original issue what is still relevant - and maybe we should preferably separate 'bigger' issues onto their own?

In essence this was the orginal list from @FuzzkingCool

1. Group actions. ❔
2. Reduce slow speed of Loader actions pop-up - especially slow in Photoshop ❔
3. Consistently use terminology across DCCs with regards to either "Load", "Import" or "Reference". ❔ The proposed options are:
   • Import: load into scene without metadata (don't keep link to pipeline)
   • Load: load into scene with metadata (keep link to pipeline; has avalon container)
   • Open or Open & Localize: when directly opening the published file as workfile (and localising it as a new scene save)
4. Add Open & Localize to all hosts - this sounds like Open a published workfile from the "workfiles" interface #2442 but from the Loader instead. ❔
5. Should be implemented. Loader actions are filtered to hosts and families. ✅

[mkolar]

1. This has a few more caveats I think, but in general I agree that grouping is desirable. The discussion whether to group by loader or group by representation is a long fight of opinions and I don't have a straight answer on that to be honest. Empirically grouping by loader might work, considering that since this issue was created, we've added represeentations widget, where user can already do things per representation anyways.
   

2. This purely depend on how the loaders are individually implemented and requires to go loader by loader and digging though things like importing pymel on top of the loader file in maya, which takes ages, and is not needed until the loader is triggered. Don't think this is a single issue kind of thing.

3. I agree 100%, including the differentiation that you suggest @BigRoy

4. Somewhat useful indeed, but I agree that it should be solved by finishing Open a published workfile from the "workfiles" interface #2442

5. Yeah don't think this is a thing :D

[BigRoy]

The Multiverse PR #2908 added new loaders which used "Read" as label. Bringing that up in this issue (and noted in on discord) to keep a discussion trace.

Also the Label to load the Multiverse USD is Read USD by Multiverse which seems to differentiate a bit from other labels that read either "Reference" or "Import" or "Load" (e.g. Load VDB to Redshift).

Going from point 3) here would it unify to e.g. the following examples:

• Load USD to Multiverse - instead of the current label "Read USD by Multiverse"
• Load Reference - instead of the current label "Reference"
• Load VDB to Redshift
• Load VDB to Arnold
• Import Model - keeps no trace to pipeline

However, Houdini USD implementation e.g. has Reference USD and Sublayer USD - would those both become Load Reference USD and Load Sublayer USD?

[mkolar]

Agree on all the points. We should definitely do that and add to dev docs as well.

[pberto]

"Load USD to Multiverse" is good for me, feel free to change it once you have decided how to uniform the naming.

[pberto]

Actually I am doing it, so let me make a new PR (also with docs and other things I discussed with @mkolar).

[BigRoy]

@mkolar Should we close this PR and if needed separate out the remaining issues that might still be todo?

[mkolar]

Yes I'm closing this. It's been dead for a while and it's note very actionable in this state. We also haven't heard this outside of this issue.