Sprints
- "I as a user want to download an AppImage from the OCS Desktop app, the openDesktop.org stores an/or the original author's download page, and run it through AppImageUpdate in order to update to the latest version"
- "I as a user want to update an AppImage using the OCS Desktop app, regardless of where I had downloaded it from originally, and even if I copied it over network, USB, etc., in order not to have to manually manage repositories, etc."
- "I as an application author want to make my AppImage self-updateable from the menu, "Check for newer version and update..."
- "I as an application author who puts OCS-provided AppImages into openDesktop.org stores don't want to need to do anything special to have automatic updates work"
- "I as a zsync user want to be able to use the new infrastructure with existing zsync files and the old zsync with the new zync files to maximize compatibility"
- mock libappimageupdate: To find out how to consume this from OCS-Store ✅
- libzsync2: Convert the functionality of zsync-curl into libzsync (using libcurl), keeping librcksum and libzsync code, but rewriting frontend code), including new zsync2 CLI tool (demo app, drop-in replacement for zsync/zsync-curl) and Unit tests -- 7 days ✅
- libappimageupdate: Convert the functionality of the appimageupdate bash script into a C/C++ library, and test it with unit/functionality tests -- 2 days ✅
- appimageupdate: Write a CLI frontend for libappimageupdate providing the same functionality as the current tool - 1 days ✅
- (Qt based? - ideally small at runtime. Statically comiled Qt? FLTK if it looks native? Vala/GTK+ 2?) AppImageUpdate: Write a GUI tool using libappimageupdate that can serve as a drop-in replacement for the old AppImageUpdate GUI tool -- 1 days ✅
If time left:
- Spend 2 hours trying to understand how bittorrent works and how much it really differs from the above, and whether the two could be merged (timeboxed to 2 hours)
- Think about how AppImageUpdate could be embedded into AppImages, and how it could be detected by companion tools (such as the standalone AppImageUpdate or OCS-Store) ✅
Total: about 12 working days
- libappimageupdate: Finish the library and document its use for Akira to integrate into OCS-Store desktop app: 5 days ✅
- appimageupdate: Fix the remaining issues so that a) AppImageUpdate can update itself b) errors are properly handled with clear error messages 2 days ✅
- Make it easy to embed AppImageUpdate could be embedded into AppImages for a self-updating experience similar to Sparkle Framework for macOS: 1 day
- Work with Akira to integrate into OCS-Store desktop app 2-3 days
- Improve standalone tools' UX and feature completeness (zsync2 CLI and AppImageUpdate CLI/GUI) 2 days ✅
Total: 10 working days
- Implement remaining feature requests (consult GitHub issues of AppImageUpdate/zsync2) (5d)
- Work with Akira on integrating AppImage update feature into OCS-Desktop app similar to the screenshots provided (2d)
- Implement zsyncmake2 (2-3d)
- Last big feature missing for zsync2
- Introducing "custom headers" (prefixed with
X-) which can be used to store auxiliary information, e.g. by sites like openDesktop.org, or AppImageUpdate for more efficient updates - Ability to create a proper C++ API for use by third party applications (AppImageKit itself will probably make use of this)
- Finish self update concept
- Incorporate feedback from potential users
- Document in the AppImage wiki (0.5d - 1d)
- Add self updating to existing libappimageupdate guide (0.5d)
- Remaining time:
- Improve CMake configuration (fix issues, improve inter-operability)
- Move AppImageUpdate information to AppImage Wiki (reason: easier to find information on all things AppImage if it is not scattered around)
- Continue to work with Akira on integrating AppImage update feature into OCS-Desktop app similar to the screenshots provided
- Work with Alexis on writing and improving a libappimage for use within AppImageKit and third party projects
- Expose common functionality like desktop integration
- Improve code quality, improve portability (e.g., by removing the dependency on glib)
- Potential users: Linux distributions, potentially also other users like OCS-Desktop or OCS websites
Applications making use of libappimageupdate should implement one of two cases
Case 1: An application that "updates itself" (example: Krita). Role model is Sparkle Framework on the Mac. Implement a "Check for updates..." menu item that, when selected by the user, checks for updates and has a GUI similar to this:
Case 1: An application that "updates other AppImages" (example: OCS-Store app). Role model is Mac App Store on the Mac. Make the application find AppImages that exist on the user's system in certain directories (listed here), and offer a GUI similar to this:
Only in the case of errors, give additional information to the user and tell what happened in an error dialog box:
As a bonus, place an icon into the dock and a progress bar into the icon like this:
There is APIs for that on the Linux desktop: See https://github.com/AppImage/AppImageKit/issues/256