-
Notifications
You must be signed in to change notification settings - Fork 49
Launcher tool: Use webactions #1226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Can you elaborate on what this change adds as functionality, or why we need this change to begin with?
I'd say that each of those are quite problematic and are really only worth it if it provides us massive benefits another way. |
This PR was created to trigger discussion. It is a must have for planned per-project bundle feature.
Something that can be resolved, as mentioned in description.
Something that needs discussion, and I guess can be changed if needed.
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.
True. |
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 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. |
Ok, thank you for your input.
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.
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? |
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. |
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. |
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. |
@@ -4,6 +4,7 @@ description="AYON core addon." | |||
|
|||
[tool.poetry.dependencies] | |||
python = ">=3.9.1,<3.10" | |||
markdown = "^3.4.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, the dependency is already in AYON launcher, so it is not necessary to create new dependency package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in Nuke and PS
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.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.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?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: