Expanding on App Install URI Protocol Support - Winget Package URIs #2733
Conversation
| .FirstOrDefault(); | ||
| _log.Information("Starting add-apps-to-cart activation"); | ||
| _navigationService.NavigateTo(typeof(SetupFlowViewModel).FullName!); | ||
| _setupFlowViewModel.StartAppManagementFlow(queryType == ActivationQueryType.Search ? identifiers[0] : null); |
There was a problem hiding this comment.
why null if ActivationQueryType isn't search?
There was a problem hiding this comment.
That's because we only want to do the query prefilling into the search box piece in the search scenario.
There was a problem hiding this comment.
similar to the other comment, lmk if you think using a bool prefillSearch might help with clarity here.
There was a problem hiding this comment.
Do you know if null is passed anywhere else into StartAppManagementFlow? MainPageViewModel.StartAppManagementFlow throws if the string is null when trying to log the query.
There was a problem hiding this comment.
this is the only place we call StartAppManagementFlow -- it was added with the previous PR: https://github.com/microsoft/devhome/pull/2642/files
With the change to not log the query string, StartAppManagementFlow should not throw if null (tested locally to confirm)
tools/SetupFlow/DevHome.SetupFlow/TaskGroups/AppManagementTaskGroup.cs
Outdated
Show resolved
Hide resolved
tools/SetupFlow/DevHome.SetupFlow/TaskGroups/AppManagementTaskGroup.cs
Outdated
Show resolved
Hide resolved
tools/SetupFlow/DevHome.SetupFlow/ViewModels/MainPageViewModel.cs
Outdated
Show resolved
Hide resolved
|
After discussing this feature with @AmelBawa-msft, I will be refactoring this PR slightly to take in and utilize WingetPackageURIs instead of WingetIDs. This way we'll be enabling package sources other than winget with minimal extra effort and this can later benefit from any WingetPackageUri feature additions. Converting to draft until I get this change in. |
AgneLukoseviciute
changed the title
|
Has any thought been put into having the flow start at the "Review and finish" page since the URI may have already selected what the user wants to install and they can confirm the selection on that page? |
I could see both ways working. As it is now, this would give the user an opportunity to add additional packages while they're there/explore this Dev Home offering. Whereas starting at the "Review and finish" page would reduce a click for any users looking to install only the packages specified in the URI. @joadoumie @krschau any thoughts on this? |
I am also worried about users missing that we added items to the "shopping cart", hence my preference for going to the confirmation "Review and Finish" page. |
|
My concern with jumping right into the review page is that users can't really edit any of the selected packages there. They can potentially go to 'Previous' but that feels off. If a URI triggers Dev Home to open, I may still want to edit the list of packages that were included in the URI, so to me the cart feels the most fluid. I'm curious to see what @shakersMSFT @denelon think. |
|
Folks offline agreed to check in as-is, and we can re-evaluate in the future if we want to add the ability to go straight to the review page. |
Summary of the pull request
With this PR, if you win+R:
ms-devhome:add-apps-to-cart?WingetURIs="x-ms-winget://winget/Git.Git","x-ms-winget://winget/Microsoft.VisualStudioCode", "x-ms-winget://winget/Microsoft.PowerToys"[updated 5/22]You will be taken to this view of Dev Home:
This also adds a message dialog for when there is a machine configuration already in progress: [updated 5/22]
References and relevant issues
#2428
Detailed description of the pull request / Additional comments
This is mostly a refactoring of the code added in: #2642 to support the winget URIs scenario which allows for specifying multiple packages to select and unlike the "search" option this does not modify the search input box in the AppManagementViewModel.
Validation steps performed
Manually tested through win+R both the search and the new URIs query params.
PR checklist