Chore: Applications settings

[iLLiCiTiT]

Changelog Description

Refactored applications settings. Removed unnecessary settings from known applications like icon and label. Added option to define available applications and tools in settings instead of attributes.

Additional info

Using settings instead of attributes for available applications and tools is for now by default turned off, that is to avoid possible confusion on update and to keep opened doors if we find out possible issues with current settings.

The possible issues might be that tools cannot be set per task, but only per folder type and task type, which is more less granular approach, but at the same time easier to set up.

Removed settings for icon and label, known applications have both hardcoded in code.

Screenshot

UX enhancements

I would say that the labels in settings might need a change. As there is a lot of places where Applications and Tools is visible in UI.

Also I've used labels from settings labels in launcher, which might be wrong? (e.g. Maya became Autodesk Maya.) Removed company name from application labels.

Tools now have filtering by application and host name in tools definitions. It might be also added to profiles. But I think that current model is better, as the tool define application and host name, whereas tools profiles define context where it will be used, maybe?

NOTE: This PR requires minor version bump.

Testing notes:

1. Change version in package.py to higher minor version (e.g. 0.3.0-settings). Version in PR already changed to 1.0.0-dev.1 .
2. Run python ./create_package.py and upload the package to AYON server.
3. Use the addon in a bundle and set the bundle as production (or current dev).
4. With that done, you should see applications in launcher as before, using attributes.
5. Copy settings from older version of applications addon.
6. Now you should have ayon+settings://applications/project_applications/enabled and ayon+settings://applications/project_tools/enabled set to False They are both enabled by default, but copying of settings from older version should change it. Change it to True, so you can test new features.
7. Create new profile in ayon+settings://applications/project_applications and define applications that will be shown. You can add different profiles for different task types or folder types.
8. Launcher should show applications based on the settings profiles.
9. Create new profile for tools in ayon+settings://applications/project_tools and define tools that should be used.
10. Launch application and validate that correct tools were used based on the settings profiles.

[LiborBatek]

I would like to note something...just my thought (no deal breaker for Approval)

Once user switches to Aplication Profiles he basically have zero apps in the Launcher available then...which makes sense.

Questionable being if when user creates very first Profile without any filter set (aka matching all typesof folders and tasks) if he should define all of the aplications and tools manually or it could be theoretically kept empty meaning again all types of aplications and tools ...not sure about this one, maybe its correct atm. @iLLiCiTiT ?

[iLLiCiTiT]

if he should define all of the aplications and tools manually or it could be theoretically kept empty meaning again all types of aplications and tools ...not sure about this one, maybe its correct atm.

100% no for me. You don't want to use all tools if they are empty (you usually don't want to use tools), and you may want to not show any applications for certain task types.

[LiborBatek]

@iLLiCiTiT I got ya, makes sense...

one more to ask...wouldnt be lovely to use some sort of labeling for profiles? I mean header with name/label so admin can organise those profiles which creates??

[iLLiCiTiT]

NOTE: There is internal discussion related to tools.

[iLLiCiTiT]

Changes made:

• using attributes can be enabled/disabled for applications and tools separatelly
• using attributes is by default disabled, but is auto-enabled when settings are converted from older version of addon
• task path in tools filtering was replaced with folder path and task name

[iLLiCiTiT]

[iLLiCiTiT]

We are going to filter applications using task types instead of project names.

It can be overriden per project. So, technically we're adding additional filter, and you set application at one place instead of 2.

We are going to filter tools using folder paths and task types or task names.

Yes.

Folder paths: For the first glance, It looks unfamiliar. as I don't have a regex pattern that works with all of my test project. but, then I remembered that it can be overridden in project settings anyways!

Well, that's why it can be overriden per project.

[iLLiCiTiT]

I really miss that search bar. it looked so cool in the project anatomy.

Probably can be changed on frontend to add search for multiselection enumerator in settings @martastain @Innders ?

EDITED: I actually have search bar there. Maybe update frontend?

[LiborBatek]

I have to agree with @BigRoy that there should be option to have all aplications enabled by default in AYON (aka no need to set filter and manually cherrypick all apps first)

[iLLiCiTiT]

This functionally is massively shitty without the AYON server copying studio and project settings on addon updates. Because this easily means everyone needs to manually go into all projects to tweak their project overrides, the whole time.. on every update.

Agree, I think it is worked on right now.

The launcher is massively slow switching tasks when ayon+settings://applications/only_available is enabled and a lot of applications are enabled. We have this disabled in our productions, but it's something we should improve for any new users coming to AYON with the new default of "All applications" enabled by default?

I've noticed this too, I though it's because I had running too many processes. Creating issue for it.

I have to agree with @BigRoy that there should be option to have all aplications enabled by default in AYON (aka no need to set filter and manually cherrypick all apps first)

That's what default does.