Launcher tool: Use webactions

[iLLiCiTiT]

Changelog Description

Show webactions in launcher tool.

Additional info

This PR changes basic functionality of launcher tool. The tools shows webactions the same way AYON WebUI does. The tool still does support local actions. With this PR only applications actions were replaced with webactions.

Downsides

We should probably use category in the UI somehow.

---

Applications actions lost functionality to "Skip open last workfile" checkbox because webactions do not support such modifications.

• Resolved by adding config to webactions (also added support for AYON FE). Since AYON server 1.8.3 but has no visual indicator.

---

Because webactions don't have "main label" and "variant label" some actions are not grouped as were before. For example 3 version of Nuke would show 3 actions instead of one action with 3 sub-menu actions for each variant.

• Resolved since AYON server 1.8.0 .

---

If launcher did not register scheme handler webactions cannot be launched which might be an issue for developers who usually don't have installed launcher. Also does not allow to run launcher from code. The launcher scheme should be probably handled directly without user's scheme handler registered for dev mode?

• Launcher type is handled manually by triggering the process instead of relying on system scheme.

Why we need this change?

This change is requirement for future "per-project bundle" feature where actions may differ based on selected project.

Testing notes:

1. It is possible to launch applications using launcher tool.
2. You can enable option to skip last workfile.

[BigRoy]

Can you elaborate on what this change adds as functionality, or why we need this change to begin with?
The list of features dropped with this change is massive, and we should have a good reason to drop those.

• Dropped "Skip open last workfile" toggle support
• No grouped applications
• The launcher does not work if no existing launcher install does not exist, making it problematic for devs. (because no web url scheme handler is installed then?)
• Launching apps is slower (delay of the web actions; 2-3s+ longer)

I'd say that each of those are quite problematic and are really only worth it if it provides us massive benefits another way.
We might want to target this PR to another branch then develop in which we continue to solve some of the dropped features before it makes its way into develop. Otherwise we'll have a period where launcher suddenly has a heavily downgraded feature set with no benefits yet.

[iLLiCiTiT]

This PR was created to trigger discussion. It is a must have for planned per-project bundle feature.

The launcher does not work if no existing launcher install does not exist, making it problematic for devs. (because no web url scheme handler is installed then?)

Something that can be resolved, as mentioned in description.

No grouped applications

Something that needs discussion, and I guess can be changed if needed.

Dropped "Skip open last workfile" toggle support

I can't tell how much is that a must have feature, again one of reasons why this PR is created. The feature is also reason that applications action is handled by ayon-core instead of applications addon, which is not ideal either. There is issue #1178 for that.

Launching apps is slower (delay of the web actions; 2-3s+ longer)

True.

[BigRoy]

This PR was created to trigger discussion. It is a must have for planned per-project bundle feature.

This might need more explanation - why does it need to go through 'web scheme url' etc. Why can't we run it through own mechanism?

---

Anyway, I'd merge this to a temporary dev branch dedicated to moving to web actions or per project bundles, instead of to develop to avoid getting worse feature set without benefiting from anything new.

E.g. we use "Skip opening workfile" a lot all over the place - and I can imagine others would as well.

Similarly without the grouped applications, launcher would really grow unusable for us. We have e.g. a few houdini versions in some projects, where each version has both a FX and Core variant. So that one button could easily become say six entries, etc. Grouping them is really helpful and UX would otherwise be way worse.

[iLLiCiTiT]

Ok, thank you for your input.

Anyway, I'd merge this to a temporary dev branch dedicated to moving to web actions or per project bundles, instead of to develop to avoid getting worse feature set without benefiting from anything new.

It doesn't make sense to push it to separate branch, the issues won't get resolved in different branch, it would only get merged to develop at some point without even looking into them...

But don't worry this PR probably won't get merged soon, as I mentioned, this needs a discussion. And I'm not here to defend the changes in the PR. You don't like it, I get it, but that won't help to resolve anything. At some point we will need to do it. The PR is opened here to see what it does, how it behaves and what we need to change first.

This might need more explanation - why does it need to go through 'web scheme url' etc. Why can't we run it through own mechanism?

The actions discovery has to go through webactions, because server does know about all addon versions assigned to a project and has access to it's code, so at the moment is the only entity in the entire system that is capable of telling launcher tool what actions should be shown for that specific context based on bundle, project bundle and variant. And because the webaction also defines what should actually happen, it should be processed the same way as webactions are processed in browser. As I mentioned above, that can be resolved to do it differently for ayon launcher scheme if it's necessary I just don't want to burn hours on something that might not be needed in future, so please stop being so aggresive about this PR, that really doesn't help.

[BigRoy]

The actions discovery has to go through webactions, because server does know about all addon versions assigned to a project and has access to it's code, so at the moment is the only entity in the entire system that is capable of telling launcher tool what actions should be shown for that specific context based on bundle, project bundle and variant. And because the webaction also defines what should actually happen, it should be processed the same way as webactions are processed in browser. As I mentioned above, that can be resolved to do it differently for ayon launcher scheme if it's necessary I just don't want to burn hours on something that might not be needed in future, so please stop being so aggresive about this PR, that really doesn't help.

This may have been miscommunication - I did not intend to be aggressive at this all, merely expressing my opinion about the downsides and not knowing the full extent of why it's needed.

Even with this explanation I'm still not convinced why we can't just have a call to the server that tells us what to do and end up doing it directly instead of requiring to go through the scheme url. Even if all we'd need from the server is a URL to trigger, I feel like we can request that 'url' or 'identifier' directly from the server and run it directly? Or is it because the running of the action would need to go through completely different launchers? Like project X may use launcher v1.1 but project Y uses launcher v1.2?

[iLLiCiTiT]

Reason why we do this is to support per project bundles. And the validation just can't be possible with per project bundles, as you don't know which applications addon version will be used at the end.

[antirotor]

Also, I know why you can't easily filter applications on frontend, but could we filter available webactions locally? That would show different items and that itself can be issue though.

[antirotor]

Reason why we do this is to support per project bundles. And the validation just can't be possible with per project bundles, as you don't know which applications addon version will be used at the end.

I see. I have a feeling that if we are struggling with this using per project bundles, we are just opening pandora box for other ugly things waiting for us.

[iLLiCiTiT]

Just to clarify, the dependency is already in AYON launcher, so it is not necessary to create new dependency package.

[kalisp]

Tested in Nuke and PS