Enhancement: (Loader) Expand "My Tasks" toggle to menu with toggles for "My tasks" / "Linked breakdown / template"

[Sasbom]

This pull request aims to build on the recently added "linked breakdown / template folders" feature on the ayon backend.
There's currently no way to access these from the loader, when this feature would naturally lend itself well to composing
libraries of assets for artists to work with.

Let's say I'm working on a project that has some asset folders belonging to a certain environment / biome.
If I want to load them, I would need to keep in mind the environment I am currently working on, in order to not fetch the
foliage assets that belong to grasslands when I am working on a scene set in a forest.
One could argue that consistent naming and text search would do the trick, but I would argue that linking the right asset folders
on the backend could save a lot of headaches, and it provides a nice composable setup (you can link multiple folders).

This PR replaces the "My tasks" toggle within the loader ui, with a "Filters..." button linked to a QMenu specialized for holding all the relevant toggles. These toggles work together!

The logic is as follows:

• 'My tasks' filters out everything that isn't assigned to the current user
• 'Linked breakdown' / 'Linked template' uses the current folder context to fetch all linked folders
• If 'My tasks' already gave a result, 'Linked breakdown' / 'Linked template' will act as a filter upon that, think "linked breakdown folders assigned to me"

In the following example, my current context is "toonboom/sh0020" which is linked to "toonboom/sh0010" for testing.

Toggling "linked breakdown" filters out the folders that aren't linked to the current context, so in this case, it will only show
"toonboom/sh0010"

Changelog Description

• LoaderNiceCheckbox has been added as a specialization of a QMenu compatible, widget wrapped NiceCheckbox.
• LoaderFiltersMenu has been added to keep one reference to the menu and it's contents alive as well as manage signals.
• tools.utils.folders_widget :: FoldersFiltersWidget has gotten a baseclass, FolderFiltersWidgetBase to encompass just the text search. (This was to prevent awful popping / pushing of widgets to the layout.
• Existing FoldersFiltersWidget has been left intact so all other UI using it is not affected.

Testing notes:

1. Build the plugin
2. Make sure that on launch, the workfile you launch into is in a folder that has at least 1 linked "In" breakdown/template folder associated with it on the site.
3. Use the "Load" menu from your favorite Ayon integration.

Thanks for your consideration,

Sas @ Studio Submarine

[iLLiCiTiT]

Hi, thank you for the PR. We won't merge this PR in this state, because of multiple reasons. I might list them later, but before I'll dig into that, is this something we'd like to have @BigRoy ?

[BigRoy]

There's a few UX issues here I think. The filtering is really "give me all linked things to my current folder or task"?" which seems overly specific for something that just says "Linked breakdown" because it's unclear 'linked to what'?

Also, breakdown and template links I believe are default link types, but technically not required to exist (unless maybe by now they are). But if we are considering links, I think we'll need to consider all links of the right type, including custom ones. Meaning we'd allow to filter by any of the links a studio might specify.

Filtering to "Give me all entities that are linked to X" I think is a search filter I'd like to see happen, where X maybe can be a dynamic input of like "Current context" so that it's a dynamic view. It's also a filter that e.g. works in DCCs but not in launcher.

If we can find the right UX (and query!) it'd be great if we can present the user something that filters so granularly without massive performance hits to the server of course ;) (note that we have clients with e.g. 10.000 folders and 20.000 tasks; we may need to do some of these filtering server side hehe)

Anyway, in its current state: no. With the tool redesigns we're definitely focused on getting better filtering you can apply in these areas (and make standard views similar to frontend you can save and re-use, etc). Where then you can "Filter by Links" (on any of the matching link types) and one of the filter options (if you are in a current context) would be that you can filter to current context perhaps.

Once we have the filter bars + views in the core UIs. I'd love to see a revised PR @Sasbom ;)

[Sasbom]

There's a few UX issues here I think. The filtering is really "give me all linked things to my current folder or task"?" which seems overly specific for something that just says "Linked breakdown" because it's unclear 'linked to what'?

I was unsure how to clarify this, i absolutely agree that this should be clearer in some way.

Also, breakdown and template links I believe are default link types, but technically not required to exist (unless maybe by now they are). But if we are considering links, I think we'll need to consider all links of the right type, including custom ones. Meaning we'd allow to filter by any of the links a studio might specify.

I'm not sure about that. I just got prompted to implement at work since we are planning to use it in the way we described,
but if custom link types are possible, then that means that this is not the right solution indeed. I did not know about this beforehand!

Anyway, in its current state: no. With the tool redesigns we're definitely focused on getting better filtering you can apply in these areas (and make standard views similar to frontend you can save and re-use, etc). Where then you can "Filter by Links" (on any of the matching link types) and one of the filter options (if you are in a current context) would be that you can filter to current context perhaps.

Once we have the filter bars + views in the core UIs. I'd love to see a revised PR @Sasbom ;)

I'll keep what I have running local for now, and I'll see if I can implement anything worthwhile when the UI overhaul becomes usable, I've been looking at the preview and so far things are looking good.
Thanks for the context! I'm at least happy to have gotten across the idea of context-aware link-based filtering.