better connection handling in QML UI

[Dirk Hohndel]

> On Jul 17, 2017, at 11:20 AM, Jan Mulder <jlmulder at xs4all.nl> wrote:
>>> 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.
> 
> I have one paired DC, and it is detected correctly at start (and any restart). The new "connection" field is empty, and I can select 3 options (classic BT address, BLE BT address, and FTDI). The selected connection option is not preserved over sessions, and the connection option is empty again on a new start. So my "concern" is that I have to select the connection type again and again.

That's odd. It should pick the correct address, not leave it empty - why isn't it matching this correctly? Is this again an issue with us not recognizing the name correctly?
But yes, we could of course remember the last selected connection.

>>> 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.
> 
> I will file an issue.

Thanks

/D