Closed purejava closed 1 year ago
Just for clarifiaction:
This PR requires a PR in integrations-win: https://github.com/cryptomator/integrations-win/pull/16
No, it is the other way round. This is the "root" PR, since it provides the service interface and attached classes. Providing an implementation is optional, hence the linked PR requires this one.
I don't fully understand the autoupdate logic: Why do two methods exist? (init and cleanup)
When is the autoupdate triggered? Or the check for it? What cleanups are needed for autoupdate when the app exits?
You can see (Win)Sparkle as an add-on: you init it and the handling is done by the add-on library, see https://github.com/vslavik/winsparkle/wiki/Basic-Setup
You can see (Win)Sparkle as an add-on: you init it and the handling is done by the add-on library, see https://github.com/vslavik/winsparkle/wiki/Basic-Setup
Ah, got it, thank you for the link. Does Sparkle and AppimageUpdate do work in a similar way or fit into this framework?
When i looked at the WinSparkle api (https://github.com/vslavik/winsparkle/blob/7ca9b991b632fa191d07ed18cd61a2f55a4c1675/include/winsparkle.h#L565), I found a "manual usage" section. I assume WinSparkle and the other implementations work also automatically? (aka calling init()
checks for updates, shows some UI and on request perform the update)
Ah, got it, thank you for the link. Does Sparkle and AppimageUpdate do work in a similar way or fit into this framework?
WinSparkle is oriented at Sparkle and adapted for Windows. AppImageUpdate is different. It has a limited functionality compared to the other two mentioned before. AppImageUpdates capabilities can be found here:
{"help", {"-h", "--help"}, "Display this help text."},
{"version", {"-V", "--version"}, "Display version information."},
{"describe", {"-d", "--describe"}, "Parse and describe AppImage and its update information and exit."},
{"checkForUpdate", {"-j", "--check-for-update"}, "Check for update. Exits with code 1 if changes are available, 0 if there are not,"
"other non-zero code in case of errors."},
{"overwriteOldFile", {"-O", "--overwrite"}, "Overwrite existing file. If not specified, a new file will be created, and the old one will remain untouched."},
{"removeOldFile", {"-r", "--remove-old"}, "Remove old AppImage after successful update."},
{"selfUpdate", {"--self-update"}, "Update this AppImage."},
So the idea is to bundle AppImageUpdate into our AppImage, so that a newer version of our AppImage can be downloaded next to the running one when an update got available, the running one is ended and the new one is started. I'm on the way to implement this.
When i looked at the WinSparkle api (https://github.com/vslavik/winsparkle/blob/7ca9b991b632fa191d07ed18cd61a2f55a4c1675/include/winsparkle.h#L565), I found a "manual usage" section. I assume WinSparkle and the other implementations work also automatically? (aka calling
init()
checks for updates, shows some UI and on request perform the update)
This method is intended to trigger checking for an update manually from the UI. This PR implements WinSparkle "the common way", e.g. it pops up on the second start of Cryptomator and in case you enable it, you get a prompt, when a new version for Cryptomator for Windows gets available and you can replace your currently installed Cryptomator installation with the latest one available. WinSparkle does all that for you.
This is the first part to provide Autoupdate for Cryptomator.
This PR requires a PR in integrations-win: https://github.com/cryptomator/integrations-win/pull/16