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