> > > > Given the lack of Bt support on Windows when just using bluez I wonder if > there is value in Anton's idea to modify libdivecomputer to use a callback > to open a serial connection and then have Subsurface (or other consumers > of libdivecomputer) provide that serial stream back to libdivecomputer. > > This way we could still use QtBluetooth on the Subsurface side but benefit > from the libdivecomputer download algorithms. > > Does this seem like a reasonable direction? > > /D >
Yes, it is a reasonable direction but I have to remind you that *QtBluetooth* doesn't have support for Windows. They probably started to work on it [1] but there is no information about the release date. Therefore for Windows we should use the *MS Bluetooth* stack. The same technology is used/will be used in *libdivecomputer* project. The only benefit with *QtBluetooth* API is that it has support for OSx, iOS, Android and Linux. I am not against *QtBluetooth* API, because I am already accommodated with the API but I believe that it would be more beneficial for both projects to have the Bluetooth implementation in the *libdivecomputer* project, since it is already started. I am a little confused about which direction to go. I read the link suggested by Jef and there are some drawbacks mentioned. Also, the discussions were from 2014 and I don't know if any idea from there was taken into consideration and it will be used in a new release. I remember that Jef said that he intends to do some major changes on the API in the next release. Also I believe that it would be helpful if the new API will allow applications to open the low-level communication transport (already implemented in the *libdivecomputer*, like Jef suggested) or to open a custom one implemented in the application which respects the same layout (like Anton suggested). It will require some extra code in the application side but it will cover a lot of usages. In this way we can create our custom implementation with the *QtBluetooth* API for its supported platforms, while for Windows we can finish the implementation from the *libdivecomputer* project. The applications will be responsible to implement features like pairing/scanning/hci control if they want to use Bluetooth protocol for communication and extract the address of the remote device. The job of the *libdivecomputer* will be to assure the communication and the data parsing. It will not be its responsibility to enumerate serial, usb or bluetooth devices or to expose an API to control the devices. [1] - https://bugreports.qt.io/browse/QTBUG-40698 Claudiu
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface