Product / vendor on mobile download

[Dirk Hohndel]

On Wed, Jun 20, 2018 at 02:03:15AM +0900, Dirk Hohndel wrote:
> Hi Anton,
> 
> > On Jun 19, 2018, at 7:49 AM, Anton Lundin <glance at acc.umu.se> wrote:
> > 
> > Hi.
> > 
> > I got myself a new android device running 8.1, one of those who actually
> > runs selinux in enforcing mode and was planing to take a look at the
> > whole ftdi situation, but got sidetracked with that the whole download
> > thingie was broken.
> 
> And by "whole download thingie broken" you mean... that FTDI currently
> doesn't work at all?
> 
> > What actually fixed the issue in the end was:
> > 
> > diff --git i/mobile-widgets/qml/DownloadFromDiveComputer.qml w/mobile-widgets/qml/DownloadFromDiveComputer.qml
> > index 2f488586f..5a05d31fe 100644
> > --- i/mobile-widgets/qml/DownloadFromDiveComputer.qml
> > +++ w/mobile-widgets/qml/DownloadFromDiveComputer.qml
> > @@ -188,7 +188,9 @@ Kirigami.Page {
> >                                        // strip any BT Name from the address
> >                                        var devName = manager.DC_devName
> >                                        manager.DC_devName = devName.replace(/^(.*) /, "")
> > -                                       manager.appendTextToLog("DCDownloadThread started for " + manager.product + " on "+ manager.DC_devName)
> > +                                       manager.DC_vendor = comboVendor.currentText
> > +                                       manager.DC_product = comboProduct.currentText
> > +                                       manager.appendTextToLog("DCDownloadThread started for " + manager.DC_vendor + "/" + manager.DC_product + " on "+ manager.DC_devName)
> >                                        progressBar.visible = true
> >                                        downloadThread.start()
> >                                }
> 
> If this fixes the issue, are you sending a PR?

Instead of waiting for that, I decided to spend some time on reading that
code in its current form and trying to understand the intended flow of
information (hurray for the off-gasing day after a dive trip). I think I
now understand why this might fail - but I no longer understand why this
works at all for BLE downloads.

I have taken a slightly different approach from you to ensure that the
DC_vendor and DC_product are at all times correct (I hope - QML isn't
always easy to fully understand). Maybe that will address the issue?

My standard caveat - I don't have an Android device that allows me to test
any of this (and I actually didn't bring any FTDI dive computers on this
dive trip, anyway, and neither did Linus, it seems).

/D