better connection handling in QML UI

[Jan Mulder]

On 17-07-17 20:07, Dirk Hohndel wrote:
> 
>> 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.

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.

> 
>> 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.

--jan