-
Notifications
You must be signed in to change notification settings - Fork 636
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
DYN-1874: I want to download missing graph package dependencies easily #9854
Conversation
src/WorkspaceDependencyViewExtension/WorkspaceDependencyView.xaml.cs
Outdated
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs
Outdated
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs
Outdated
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs
Outdated
Show resolved
Hide resolved
A few comments, but looks pretty good so far and thank you for adding row details function in an early stage. Since there are lots of new style changes, have you looked at reusing color defined from Dynamo style sheets instead of using hex codes? |
/// Class defining data for each column | ||
/// </summary> | ||
public class ColumnData | ||
public class NodeLibraryDependencyRow |
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.
did something weird happen to this file? The diff is pretty hard to read, it looks like a bunch of public classes were deleted? Or am I mis-reading the diff?
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.
(you can't delete the public classes if they get released with another version - however short lived that version is) it's safer to just obsolete them as we don't know what binary compatibility issues this will cause without extensive testing, and it's just not worth it IMO.
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.
@mjkkirschner Do you remember the last case this was an issue? This class is only used for data binding to the UI so we can't make it internal. If any class went out with a beta release that we can no longer rename, that sounds like too strict..
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.
I'm not talking about beta releases.
If it's in 2.3 then we should consider it stable, unless @scottmitchell wants to refactor 2.3 before release to not include this class and then redo testing there.
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.
Sure, I guess I am wondering if the API restriction need to be applied on extension level. I understand once it is in RC branch we should make it stable but this dll is not in our public nuget so I do not expect developers to consume it nor us maintaining the stability.. My 2 cents.. Unless you are talking about internal ones..
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.
@QilongTang - that's a great great point! I think it's acceptable to make this entire .dll not part of the API.
👍
I think we'll need to consider what consequences this has technically and also for build processes though.
Where do we communicate/document this?
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.
@mjkkirschner I don't think we have it specified according quickly glancing at https://github.com/DynamoDS/Dynamo/wiki/Dynamo-Versions or https://github.com/DynamoDS/Dynamo/wiki/API-Changes. And seems we also missed 2.x versions' API changes...
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.
regarding the API Changes doc... I find it kind of useless work - the API diff job now computes this for us - or something like
https://www.fuget.org/packages/DynamoVisualProgramming.Core/2.2.1.5204/lib/net47/diff/2.1.0.7465/
is SOO much better than that page - it's only missing the explanations/readme portion.
@mjkkirschner @QilongTang I think I've addressed all the comments in this PR. In terms of the API / semantic versioning issue for the WorkspaceDependencyViewExtension--I think this will be addressed by release notes and by a PR to 2.3 marking the view extension (and/or its classes) as obsolete/beta. |
src/WorkspaceDependencyViewExtension/WorkspaceDependencyView.xaml.cs
Outdated
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/IPackageDownloader.cs
Outdated
Show resolved
Hide resolved
break; | ||
|
||
case PackageDependencyState.Missing: | ||
iconPath = "NodeLibraryDependency_Missing.png"; |
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.
would it be possible to move these to a resx file? I guess we can do it as as followup - raw resources like this are difficult to manage and make patch installer issues much worse.
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.
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.
@mjkkirschner I spent some time trying to figure this out last night, but couldn't quite get it to work. If it's alright with you, I'd like to deal with this in a follow up UI pass.
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.
@mjkkirschner Finally got it. Turns out we have an existing utility for converting bitmaps to ImageSources: https://github.com/DynamoDS/Dynamo/blob/ec10f936824152e7dd7d6d019efdcda0d78a5264/src/DynamoCoreWpf/Utilities/ResourceUtilities.cs
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.
@scottmitchell one main concern about the API breaking change. Is there anyway to avoid adding the interface?
src/DynamoCoreWpf/ViewModels/PackageManager/IPackageDownloader.cs
Outdated
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs
Show resolved
Hide resolved
src/DynamoCoreWpf/ViewModels/PackageManager/PackageManagerClientViewModel.cs
Show resolved
Hide resolved
@aparajit-pratap @mjkkirschner Thank you for the comments. I believe I have addressed them all--the one thing I did not fix here that will need a follow up is moving the package state icons to a resx file |
@mjkkirschner I have moved the dependency state icons to a resx, and also added a "Package Manager Terms of Use" check to the new package download API (thanks for pointing this out @kronz). This PR should be good to go now. |
The TOU check and image changes looks good. Thank you for removing the static images so they will not pollute binary compatibility. Merging for testing in 2.5. |
DynamoDS#9854) * Add IPackageInfo interface * Add IPackageInfo interface * Add PackageManagerClient API to intiate download and install of a package * Add download button to test package download * Add IPackageInfo interface * Use PD state * Fix comment * Refactor Dependency Viewer UI * Rename ExecutePackage -> ExecutePackageDownload * Add PackageManagerClientViewModel to ViewLoadedParams * Add IPackageDownloader to LoadedViewParams * Move messages to resource file * Add state-based messages * Font size * Keep ReferenceType and INodeLibraryDepInfo internal * IPackageDownloader.cs -> IPackageInstaller.cs * IPackageInstaller comments * Move details message to resx * Fix resource conflict * Check terms of use acceptance before downloading package * Embed icons in resources.resx * Remove raw resources * Add summary to public class * Add summaries for PackageDependencyRow members (cherry picked from commit 8ca9d0f)
* DYN-1874: I want to download missing graph package dependencies easily (#9854) * Add IPackageInfo interface * Add IPackageInfo interface * Add PackageManagerClient API to intiate download and install of a package * Add download button to test package download * Add IPackageInfo interface * Use PD state * Fix comment * Refactor Dependency Viewer UI * Rename ExecutePackage -> ExecutePackageDownload * Add PackageManagerClientViewModel to ViewLoadedParams * Add IPackageDownloader to LoadedViewParams * Move messages to resource file * Add state-based messages * Font size * Keep ReferenceType and INodeLibraryDepInfo internal * IPackageDownloader.cs -> IPackageInstaller.cs * IPackageInstaller comments * Move details message to resx * Fix resource conflict * Check terms of use acceptance before downloading package * Embed icons in resources.resx * Remove raw resources * Add summary to public class * Add summaries for PackageDependencyRow members (cherry picked from commit 8ca9d0f) * merge conflict assemblyInfo * remove unnecessary API * update dev view UI when package installed. (#9915) * get rid of properties that were not set set package loader to update dep UI add this outisde the view to make it clear this is intended to be a singleton view * flipped usings (cherry picked from commit 9243c17) * review comments * sneaky equals
Purpose
This PR addresses JIRA task DYN-1874. It adds an API to the
PackageManagerClientViewModel
to initiate download and install of a package. It also adds the ability for the Dependency Viewer to download missing packages.Declarations
Check these if you believe they are true
*.resx
filesChanges to the API follow Semantic Versioning, and are documented in the API Changes document.This feature is in Preview ModeReviewers
(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)
(FILL ME IN, optional) Any additional notes to reviewers or testers.
FYIs
(FILL ME IN, Optional) Names of anyone else you wish to be notified of