better connection handling in QML UI

[Dirk Hohndel]

> On Jul 17, 2017, at 10:55 AM, Jan Mulder <jlmulder at xs4all.nl> wrote:
> 
> On 17-07-17 17:14, Dirk Hohndel wrote:
>> I just uploaded a new Android APK and pushed my changes to master.
>> Yes, this includes the change to the action button that makes it harder to
>> read - sorry, we'll address that. But what I'd like people to focus on and
>> play with is the change to the download dialog, where the connection is
>> now a third dimension. This is currently broken when used with "Paired
>> Bluetooth Devices" (because I want to remove that option), but it should
>> work well and do the "intuitive" thing when selecting a dive computer.
>> I'd appreciate some feedback on this :-)
>> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.425-arm.apk
> 
> Tested the -425 version (as downloaded, so Dirk's build).
> 
> 1) Functional: somehow I expected the selected choice for the previously used connection type to be saved on exit and restored at a new start. Without looking at any code change (yet), I assume that this is known. As most users will use the same way of connecting all the time ... this would be a useful enhancement.

Let me poke at this a little bit. For the typical user with one dive computer
there will be one paired dive computer and that should be selected by
default.

So what is selected when you open the dialog for you? What did you want
to be selected? I'm guessing you have two paired computers and the "wrong
one" was selected? Or something else?

I just want to make sure I actually understand your real concern here.

> 2) Something that is not new (so not related to this specific set of changes), is that during a transfer, the Quit button does not quit, but only moves away from the download screen. For my OSTC3, there is a relatively simple workaround: just disable bluetooth on the mobile device, and quit the download on the OSTC3. It would, however, be much nicer when the quit, actually quits the transfer, and (for an OSTC3) sends the needed <end of communication> to get the DC back in non-download mode, before is taking forever to timeout.

Yes, we need to implement cancellation of download correctly.
Patches welcome, or please file an issue so we don't forget.

Thanks

/D