> On Jul 17, 2017, at 11:20 AM, Jan Mulder <jlmul...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
