Closed JonnyPhenomenon closed 6 years ago
Yes, this is well known, but and there are some efforts under way to move away from the chrome app, but nothing definitive is planned as of now.
It would be great if the ported App could support all three platforms; Linux, Windows, and Mac. (but I'm sure you've already thought of that) ;-)
(don't forget AmigaOS ;-P)
Hah! AMIGA!!!
;^)
Has anyone looked at how the inav-configurator are doing it?
They are now providing Windows and MacOS binary files (with Linux following soon apparently).
interesting.... Node JS by the look of it...
On INAV we already have workings builds using NW.js, but there are still some pending issues until the standalone apps can fully replace the configurator (e.g. automatic updates). Shouldn't be too difficult to port to ßF once we're done.
@fiam: Will have a look at what you are doing in iNav. Will have to do something similar for the openLRSng-configurator soon (involving as little effort as possible).
Good find, but looking at the Readme it says that chrome.usb
is not yet implemented, pretty much mandatory to use it for the BF configurator.
@richard-scott: That is one option. There seem to be a whole bunch of tools available that allow conversion of Google Chrome apps into electron / NW.js apps, some of them even claim to be able to turn the apps into fully self-contained apps for multiple platforms.
I will be looking into doing this for the openLRSng configurator (which is a much smaller and less refined app), and report back.
How about WebUSB API ? Chrome 61 already realized, and with WebUSB API you can host app as GitHub page, or or any hosting, allow to create user accounts, config share and backups, collect some board statistic, faster realize update and many other things.
@mosvov: I am not sure this is a good match for the configurator. I assume people will be wanting to use the configurator while in the field, potentially in places where there is no internet connectivity (or only painfully slow connectivity).
I agree with that, but with WebUSB API we can move away from the chrome app. It will be simple html5 application that can be used anywhere.
I just accidentally stumbled over this discussion. The offline capability would not get harmed by making it a native HTML 5 Application. There are ServiceWorkers which can help you serve the app offline. It would also make mobile devices run the application since they also support WebUSB (and ServiceWorkers even better). I don't know a lot about hardware nor the Betaflight Code, but I think it would be a great way to make the Betaflight configurator.
Are there any statistics of how supported WebUSB is across browsers? I'm sure it was suggested before and I could only find Chrome that implemented it.
Just to needlessly chuck another option into the mix, I'm all for a complete rewrite in a cross platform application framework such as Kivy.
That way you'd end up with native applications for each platform (as I understand, I've only used it for desktop applications so far) and I'll speculatively say more firmware developers know Python than JS.
Python is an interesting option indeed. Considering that the old jquery code is in dire need of a rewrite anyway, this ain't a bad option. But all things considered if a rewrite is to be done, it's probably best started after MSPv2 / parameter group based configuration exchange has been implemented in the firmware. A big chunk of boilerplate serialisation / deserialisation code is used for the MSP commands used to access the configuration, and being able to use generated, parameter group based stubs instead will eliminate a considerable amount of work from the overall requirements for the rewrite.
With Python you could run a server in the background and then have a browser connect to it. CouchPotato does this and it works fine. It's run with a console window hosting a web server on a loopback device and a browser is automatically directed to the host: ie. http://192.168.1.5:8000. I personally like how CouchPotato works but I think it can be confusing to the average user and isn't as clean as other methods available.
The official Chrome docs suggest migrating to a platform like Electron or NW.js. Going this route would allow devs to leverage the existing code base. These middlewares also support Node modules, which would allow lower-level hardware access to interface with the flight controllers. Parts of the code would need to be re-written to switch from the Chrome API to the new API but that should be a very small subset. Also, other commenters mentioned there is software available to help convert the APIs over.
Whatever solution is chosen, I think it's important to ensure the ease of installation and running of the app for the end-user. Currently, the Chrome installer makes it dead-simple to get the Configurator running. I'd hate to see any additional stumbling blocks put in place for non-technical users.
@jasonhamilton: Thanks for your suggestion. I think any involved setup like what you are proposing would have the drawback of making it hard to troubleshoot for users with problems, and one of our goals for the configurator is to provide a solution that requires a minimal amount of maintenance.
We already have added an NW.js build to the configurator, and we are currently working out some kinks in making it work on all supported platforms: https://github.com/betaflight/betaflight-configurator/releases/tag/10.0.0-RC2
Any feedback on this is appreciated!
@mikeller that's awesome! What's the roadmap/timeline look like to switch over to the NW.js version?
@jasonhamilton: Well, it's obviously going to happen before 01/01/2018. :grin: The standalone versions seem to be stable enough to be useful on all platforms, but the update notifier needs to be changed for the last release of the Chrome web app (so that users are directed to the GitHub release page when a new version is available), and then we are good to go (I think).
@mikeller .. and it’s happened! Chrome Apps are dead, as Google shuts down the Chrome Web Store section
Yeah, I noticed that.
Interestingly, in the email they sent out to app owners yesterday, Google states that the removal of support for running apps in non-ChromeOS will be delayed until later in 2018, because they are working on implementing some form of support for running standalone, non-browser apps (which sounds a lot like NW.js or electron), and want this to be available before removing Chrome app support.
In light of the chrome app removal, I am now maintaining an AUR package for Arch users.
Would it be possible to add Arch to all the other platforms supported and keep all in the same repo here? One set of unified sources in one place.
Unfortunately it cannot be added to this repo, but it certainly could be listed as a supported platform. As I use Arch exclusively and use betaflight regularly, I'll be sure to always keep it up to date and working.
That is odd. We can do Chrome, OSx, Windows, Debian etc etc but not Arch? Is that env so totally different?
No, it has to do with the way the AUR works. The AUR requires the package to be a unique repo that is formatted properly and provides the build script for Arch. It's essentially using the linux zip file from the release build, and then properly installing it.
Thanks for putting in the work to set this up, @FryDay. We are still looking into ways to centralise releasing new versions, so that a new release can be pushed to all the destination repositories by scripts, instead of requiring manual work to be pushed. How hard would it be to automate pushing new versions to AUR?
@FryDay , just in case you might have missed it; It would be nice if Arch also could be a part of CI here: http://andwho.sytes.net:8080/job/BorisB_BetaFlight_Configurator/ I really hope this could be moved to the better place at https://ci.betaflight.tech/. Really too low bandwidth and capacity at the current site for any serious business. Good for experimentation though.
Can we still manually install BFC on Chrome as an unpacked extension? My field/tuning laptop is a Chromebook and I am not going out and buying a Windows laptop to use BFC. I was able to install BFC 10.1.0 on my Chromebook following the directions on the BFC GH page, but am getting an error following the same instructions on 10.2.0. Anyone?
You can install it from the chrome store or as unpacked extension, but you need to execute a gulp release --chromeos
to generate the correct code.
Chrome store does not show any version of BFC over 10.0.0 anymore and I get an error installing as an unpacked extension. How/where do I execute gulp release --chromeos? I am using a Chromebook running the Canary version of ChromeOS. Thanks!
In the text of the homepage of the configurator you have both, the link to the chrome store and the instructions to build it.
@McGiverGim I see BFC is on the Chrome app store, but only version 10.0.0 (not the latest version 10.2.0). I followed the directions on how to manually install it as an unpacked extension by cloning the repo to a zip and extracting it to a folder. This worked to install 10.1.0 on my Chromebook, but is not working for 10.2.0. Can you point me to the instructions on how to build it myself? I am not a programmer, but can figure it out with proper instructions. Thanks!
@McGiverGim I guess you cannot help me?
@WiKDMoNKY: Sorry, for some reason version 10.1.0 never made it into the store. The idea is that we keep publishing it (at least for ChromeOS) into the foreseeable future. I'll see that I can get things going to get 10.2.0 into the store soon.
@WiKDMoNKY I was sleeping ;) I've seen that in the other issue some other has gave you instructions about how to build it (or use the continuous integration if you are not able). And as mikeller said, the idea is be up to date in the chrome store too.
Until Chrome Store is updated, you can get builds for all supported platforms, including ChromeOS, here: http://andwho.sytes.net:8080/job/BorisB_BetaFlight_Configurator/
If you use a locally installed version, just don't forget to switch back to the Chrome web store as soon as the version has been updated, or else you'll miss out on automatic updates.
This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.
Automatically closing as inactive.
I recently became aware of a decision by the folks at google to pull the plug on "Chrome Apps"...
The betaflight/cleanflight configurator (as well as Blheli config, and BB explorer for that matter) appear to all be "Chrome Apps" - which is why we install them from the play store, and how they show up in the "Apps" menu within chrome. ( chrome://apps/ )
Google has indicated that these apps will still work on Chromium OS or android devices, but not within the chrome browser on other platforms.
So, how will this affect these apps we use for betaflight? Are the developers of them aware of it? Or do these apps not quite qualify as Chrome apps, so we should be all set?
a couple links on the subject: https://www.google.com/search?q=chrome+apps+going+away https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html