-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
feat(developer): introduce WelcomeFile property to packages 🎺 #9709
feat(developer): introduce WelcomeFile property to packages 🎺 #9709
Conversation
Fixes #9478. This adds a property WelcomeFile to .kps and kmp.json, which allows us to move away from the hardcoded welcome.htm filename in the future, and makes transform from Markdown (#9477) a simpler operation, and just generally starts the cleanup of the messiness of hard-coded filenames. The package compiler will fallback to injecting welcome.htm into this property if (a) welcome.htm is present, and (b) the property does not already have a value. This doesn't buy us much because we still need to support welcome.htm for existing legacy packages, but does mean that our .kmp package metadata will be more consistent for packages compiled with 17.0+ compilers.
User Test ResultsTest specification and instructions
Test Artifacts
|
@@ -697,16 +708,23 @@ procedure TPackageOptions.LicenseRemoved(Sender: TObject; EventType: TPackageNot | |||
FLicenseFile := nil; | |||
end; | |||
|
|||
procedure TPackageOptions.WelcomeRemoved(Sender: TObject; EventType: TPackageNotifyEventType; var FAllow: Boolean); |
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.
How doe the FAllow boolean fit in with these procedures?
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.
The FAllow
var parameter is an output parameter, allowing the function to prevent the removal of the item, which we never need to do, so it's safely ignored.
@bharanidharanj I think perhaps my test steps were not very clear, sorry! There is a new field in the Package Editor, called "Documentation File", in the Details tab, which we need to test. I don't have an image handy sorry as my machine is on a different branch, but it should be at the top of the "Optional Information" section of the tab, above the "Readme file" entry. Would you mind re-testing? Thanks so much! @keymanapp-test-bot retest |
@mcdurdin Thank you so much for your clarification! I will retest and add my post my results. |
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.
lgtm
Fixes #9478.
This adds a property WelcomeFile to .kps and kmp.json, which allows us to move away from the hardcoded welcome.htm filename in the future, and makes transform from Markdown (#9477) a simpler operation, and just generally starts the cleanup of the messiness of hard-coded filenames.
The package compiler will fallback to injecting welcome.htm into this property if (a) welcome.htm is present, and (b) the property does not already have a value. This doesn't buy us much because we still need to support welcome.htm for existing legacy packages, but does mean that our .kmp package metadata will be more consistent for packages compiled with 17.0+ compilers.
User Testing
Note: Keyman itself on all platforms still only supports the welcome.htm filename at this time, so do not expect documentation with arbitrary filenames to be visible in the client apps.
TEST_WELCOME_FILE: In the package editor in Keyman Developer, select a welcome.htm file in the new Documentation file field. Compile the package and verify that there are no errors. Add and remove the reference to the documentation file and verify that the field behaves as you would expect.