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