edgetx
edgetx copied to clipboard
Companion: add download and process updates to firmware, Companion and other components
Summary of changes:
- remove OpenTX firmware and companion updates
- application settings new Updates tab
- updates for firmware, companion, sd card, sounds, themes, multiprotocol
- source updates from Github releases
- support release channels of releases, pre-release, nightly
- update check frequencies of manual and auto on startup, daily, weekly, monthly
- auto mode checks only those components flagged and gives the user a choice to install or not. Uses defaults to process any updates.
- manual mode only checks components flagged though gives user choices and access to options for each component
- when manually checking for updates runtime options per component (not saved between sessions). Some options disabled as locked from user update by design depending on the component
- download older releases via component options
- downloads, decompresses archives, copies to update folders (by default the Companion radio profile SD path), post update async installer
- prompt to write firmware to radio if radio profile setting set
- prompt to run Companion installer if application setting set
- prompt to run SD Card Sync if radio profile setting set using update folder as source rather than radio profile SD path (default) though they could be the same
- add OpenSSL DLLs to Windows installers
- add OpenSSL to github workflows and dev MSYS2 environment builds
- design objectives: expandable, modular, flexible, use Github REST API v3
- tested on Ubuntu 20.04 and Windows 64-bit
Please note: if testing on Windows 32 or 64-bit and not using 'make installer' you will need to have installed OpenSSL v1.1 32 or 64-bit respectively for compatibility with Qt 5.12.x.
Radio Profile Settings tab
Update Settings tab
Launch Manual Updates
Manual update (Note: only those components marked for checking in settings listed. The current versions are what were installed by Companion so earlier updates either manual or via Buddy or Flasher are unrecognised except Companion itself)
Component Options (Note: override defaults such as changing the release or selection filters)
Update progress status
Language pack selection based on radio profile language
You always know I'm game... But I will have a tanti if it breaks my Winblows system! 😆
But seriously, looks like you have been hard a work on this from the summary and screenshots... wow, just wow!
You always know I'm game... But I will have a tanti if it breaks my Winblows system! 😆
On the 8th day God created VMs for those risk averse amongst us....😜
Appears to be working though there are numerous test cases and I have gone thru them so many times. But hey why not let some others try and break it.
Wow, that was a lot of work, well done. now we need to find a way to have this also working for custom build options, to relieve @pfeerick from his duty as buildserver.
Wow, that was a lot of work, well done. now we need to find a way to have this also working for custom build options, to relieve @pfeerick from his duty as buildserver.
We have some stuff for that, but we need someone taking care of it and running it on cloud service.... (see https://github.com/EdgeTX/cloudbuild) @jurgelenas was taking care of it, but does not really have time for that right now...
@elecpower It may not happen in this order (just trying to get ducks lined up) but are you OK with #1374(model label PR if I put the wrong Id in on phone) merging before this as I expect there will be conflicts, and you're in a better position to resolve? Ideally that PR will go in in the next couple of days if complete enough now, with any minor stuff to follow separately. Need to check if cliff is ready though also :)
@pfeerick okay and I expect it will be a messy conflict resolution...
I'm hoping not so messy as it was recently rebased but cross that bridge when we get there...
Oh, it looks like it didn't break anything at all 🥳 So just that one line change in companion/src/storage/CMakeLists.txt
still.
Do you want to rebase it or shall I? It is better if you do it since it won't make you force pull.
I'll rebase
@pfeerick rebase done
Thanks Neil. I hit some sort of Companion crash - but I can't seem to precisely pin down the repeat case. It seemed to be some form of start Companion with following combo, hit update, get prompt that there is no update available. Then change the firmware to nightly, and try to check for updates again, Companion just crash completely. I did manage to get it to happen twice but it seems almost random, or there is a step missing.
Have you noticed there is a rate limit issue if we try to check for updates too frequently... any idea what specific rate limit we're hitting... as I'm seeing something like 5000 requests per hour, and that is way too high to be this?
And (unrelated to this PR) it looks like there is still an intermiettent issue with Windows builds and the File and Edit menus not being clickable - Edit is greyed out and File is non-responsive, and there doesn't seem to be any way to trick into getting access. However, if you hit the 'New' icon on the toolbar, Edit turns black like all the others, and while you can't click on it, you can get it to show up if you click on another menu entry and mouse across... ok, a video will probably explain this better.
https://user-images.githubusercontent.com/5500713/188300816-8318a899-ad93-46bd-acd2-3421c9823d26.mp4
Hm... am I doing something wrong here? This doesn't seem to get saved? It works, but if I go back into the dialog, it gets reset.
https://user-images.githubusercontent.com/5500713/188304846-512d9731-8d85-4f90-89dd-3c9775c989da.mp4
This is not a feature request... is it possible to rename when copying? i.e. I'd like to be able to convert mm-stm-serial-taer-v1.3.3.14.bin
to mpm-taer-v1.3.3.14.bin
while copying... but really don't care if I can't. Would just have be handy for B&W since they like shorter names ;)
Hm... am I doing something wrong here? This doesn't seem to get saved? It works, but if I go back into the dialog, it gets reset.
Not doing anything wrong refer comment from Summary above
when manually checking for updates runtime options per component (not saved between sessions). ..
Though should say between runs.
I considered saving in the registry/config but requires a rethink on the current helper functions as they use Qt magic which I would need to familiarise myself. Wanted to see how many want to always set the custom parameters to see if worth the effort.
This is not a feature request... is it possible to rename when copying? i.e. I'd like to be able to convert
mm-stm-serial-taer-v1.3.3.14.bin
tompm-taer-v1.3.3.14.bin
while copying... but really don't care if I can't. Would just have be handy for B&W since they like shorter names ;)
If you manually download you have to manually rename to shorten. To implement it would have to be another parameter per component per rule and would have to prompt for every file matching the filter.
Have you noticed there is a rate limit issue if we try to check for updates too frequently... any idea what specific rate limit we're hitting... as I'm seeing something like 5000 requests per hour, and that is way too high to be this?
The API does not use EdgeTX authentication but the user default 60 requests per hour which is a reasonable number enough to run a few times per hour. The meta data requests are cached in a Companion session to reduce the number of calls. You should get a http error status if the limit is reached.
And (unrelated to this PR) it looks like there is still an intermiettent issue with Windows builds and the File and Edit menus not being clickable - Edit is greyed out and File is non-responsive, and there doesn't seem to be any way to trick into getting access. However, if you hit the 'New' icon on the toolbar, Edit turns black like all the others, and while you can't click on it, you can get it to show up if you click on another menu entry and mouse across... ok, a video will probably explain this better.
I also struck this the other day in Ubuntu and like you it went away. Has it happened to you in testing other Companion PRs?
Edited: main branch seems okay by this PR is playing up so I'll look into.
I hit some sort of Companion crash - but I can't seem to precisely pin down the repeat case. It seemed to be some form of start Companion with following combo, hit update, get prompt that there is no update available. Then change the firmware to nightly, and try to check for updates again, Companion just crash completely. I did manage to get it to happen twice but it seems almost random, or there is a step missing.
Tried what I think you did and didn't crash. It has been stable for me for weeks but it must be a specific combination.
I also struck this the other day in Ubuntu and like you it went away. Has it happened to you in testing other Companion PRs?
Edited: main branch seems okay by this PR is playing up so I'll look into.
Yes, it has happened infrequently - it is not unique to this PR, and MervDale also mentioned it a while back.
If you manually download you have to manually rename to shorten. To implement it would have to be another parameter per component per rule and would have to prompt for every file matching the filter.
That's what I thought - just wanted to make sure there wasn't some magic expression I could use! :grin:
user default 60 requests per hour
Ok, that explains it... I just wasn't sure what the number was, and if it was user dependent.
when manually checking for updates runtime options per component (not saved between sessions) ... Wanted to see how many want to always set the custom parameters to see if worth the effort.
Fair enough. It was probably the fact the buttons are "Restore defaults", "Save" and "Discard" ... and Save isn't really ... saving! 😆 If you do make it save at a later point, it would be nice if it were also done by the auto-updater - i.e. you could essentially have an option button for each component in the update settings tab which is editing the same settings being used when you run it manually?
So, status of this PR... is it ready to go in or is there more to work on?
Fair enough. It was probably the fact the buttons are "Restore defaults", "Save" and "Discard" ... and Save isn't really ... saving! 😆 If you do make it save at a later point, it would be nice if it were also done by the auto-updater - i.e. you could essentially have an option button for each component in the update settings tab which is editing the same settings being used when you run it manually?
The button labels change for each OS (Linux below). Better if I rename Save to Ok and Discard to Cancel.
If you do make it save at a later point, it would be nice if it were also done by the auto-updater - i.e. you could essentially have an option button for each component in the update settings tab which is editing the same settings being used when you run it manually? Yes agree 100%. The parameters started life in the Update Settings but due to the save settings issue mentioned I moved them. I'll work to try and improve after this merged.
So, status of this PR... is it ready to go in or is there more to work on? Let me fix the button labels.
@pfeerick I think I have found some culprits blocking the File and Edit menus (see commits). This PR definitely better.
@pfeerick ready to go in
@elecpower: I have been working on translating all of your great work and believe I have pretty much managed to create all new contexts and items in the companion_sv.ts file. There was a few translations missing in the code, for the name of the components (Companion, Firmware, Sounds, Multi protocol, SD Card and Themes), so I have added those. Simple enough even for me :) One remaining translation that I can't get to work is for the filter patterns (Startswith, Endswith ...). What context should they be in? I have tried UpdateParameters and UpdateInterface (and a few more) but to no avail.
Here are my changes: https://github.com/ulfhedlund/edgetx/tree/additional_SE-translations
@ulfhedlund have you been following this How to https://github.com/opentx/opentx/wiki/Flow-for-the-Translators or crafting by hand?
I have a virtual Ubuntu build environment with Qt Linguist installed but have crafted the new/revised translations by hand. So this link is news to me!
There is a fair amount of old remnants from OpenTX in the .ts-file and certainly some missing contexts and items. Generating an up-to-date .ts-file would have been great if starting from scratch, I suppose, but I have added to an existing .ts-file originally from OpenTX.
Can this workflow be used to continuously add translations when new functionality is added? If I run the lupdate.exe now, would all existing translations be lost?
I have a virtual Ubuntu build environment with Qt Linguist installed but have crafted the new/revised translations by hand. So this link is news to me!
@pfeerick is there any reason https://github.com/opentx/opentx/wiki/Flow-for-the-Translators cannot be brought across and updated of course?
There is a fair amount of old remnants from OpenTX in the .ts-file and certainly some missing contexts and items. Generating an up-to-date .ts-file would have been great if starting from scratch, I suppose, but I have added to an existing .ts-file originally from OpenTX.
Based on the age of the source ts files looks like they haven't been regenerated since EdgeTX was forked except for a couple of languages but not linked to each EdgeTX release. There were very few helping with the translations in OpenTX so regeneration was very much on an as needs basis.
Can this workflow be used to continuously add translations when new functionality is added? If I run the lupdate.exe now, would all existing translations be lost?
Based on the Qt documentation https://doc.qt.io/qt-5/qtlinguist-index.html we should be running each release to update the github source ts files. An update is performed in the Companion compile but the updated files are created in the build directory and not brought back to github.
The Qt documentation says ldupdate.exe should merge changes though looks like some testing required to check especially if hand crafted. Since you have your own local copy of the source you can give it a try and see how good or bad the result, if you like.
Since this PR is closed I'll create a new Issue https://github.com/EdgeTX/edgetx/issues/2317 to keep the matter on the TODO list.
Running lupdate on the existing companion_sv.ts generated this result: Updating 'companion/src/translations/companion_sv.ts'... Found 2833 source text(s) (185 new and 2648 already existing) Removed 529 obsolete entries Number heuristic provided 3 translation(s) Same-text heuristic provided 29 translation(s)
Absolutely fantastic and so much easier than my tedious hand crafting!!! On the other hand I know understand a fair bit about how the code base is structured, so I have learnt a lot during my manual translations work.
It would be great if this information could be made available to other translators and if I can help in any way, let me know.