On 2017-08-21 16:51, Dirk Hohndel wrote:
BTW: I have added some annotation in the Subsurface-branch to help us
decide which dive computers to offer as choices on mobile devices
(this is in src/descriptor.c):
[...]
This basically just adds a comment at the end of every line that
follows a strict syntax: two slashes, one space, then a token. There
can be more than one such comment, e.g.:
/* Shearwater Petrel family */
{"Shearwater", "Petrel", DC_FAMILY_SHEARWATER_PETREL, 3},
// BT // BLE
{"Shearwater", "Petrel 2", DC_FAMILY_SHEARWATER_PETREL, 4},
// BT // BLE
{"Shearwater", "Nerd", DC_FAMILY_SHEARWATER_PETREL, 5},
// BT
{"Shearwater", "Perdix", DC_FAMILY_SHEARWATER_PETREL, 6},
// BT // BLE
{"Shearwater", "Perdix AI", DC_FAMILY_SHEARWATER_PETREL, 7},
// BLE
(yes, I know this looks wrong, as the Petrel has no BLE version, but
the Petrel 2 unfortunately identifies itself as Petrel).
Would you be willing to take a patch that adds this for
libdivecomputer master? This would make our lives easier and it
certainly shouldn't cause any problems on your end as this is all just
comments...
Please let me know and I'll be happy to submit one clean patch to just
add that.
I don't understand what you gain with those comments. I mean it's just
comments. Don't you need this kind of info at runtime instead? Something
like what I proposed for the I/O refactoring:
For the I/O refactoring, I'm already planning to add an extra field with
the transport type. Since some devices support multiple transports, the
transport type will need to change into a bitfield. So something like
this:
{"Shearwater", "Petrel 2", DC_FAMILY_SHEARWATER_PETREL, 4,
DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE},
With this information, an application knows exactly which transport
types are supported for each device, and can setup the appropriate I/O
channel (built-in or custom implementation).
To find out what goes wrong, you'll need to enable the libdivecomputer
logfile checkbox. Without the logfile, we have no idea where exactly
it goes wrong. Screenshots are useless because they don't give the
low-level detailed info.
I keep wanting to improve the error messages that we are able to give
- right now the useless default error that implies incorrect
permissions does a lot more harm than anything else. I just can't seem
to find the time with all the other things on my plate. A feeling that
I know you are well familiar with, Jef.
But until then, the libdivecomputer log file certainly is the correct
next step. Actually, I might be able to add a quick and dirty change
that suggests this to the user... then at least people using the test
builds would get that hint.
Just an idea: Why not always enable the logfile? Then whenever the
download fails, you can notify the user about the error as usual, but
also point to the log file. You probably don't want to show the contents
of the log, but just the location of the file. That makes it very easy
to report errors, because all the info is right there. Diving Log does
something similar, and it works very well.
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
