<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu <<a href="mailto:olteanu.vasilica.claudiu@gmail.com" class="">olteanu.vasilica.claudiu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">As you can see I am having some troubles and I don't </div><div class="">know in which direction to go. If we want to implement </div><div class="">the data transfer using the Qt Bluetooth API, then we </div><div class="">should find a way to integrate it with the implementation </div><div class="">of the serial port communication from <i class="">libDC</i> project.</div><div class=""><br class=""></div><div class="">If this is not possible and we still want to use the </div><div class="">Qt Bluetooth API, then we need to do some specific </div><div class="">implementation for each dive computer vendor. </div><div class="">This implies a lot of useless work since it is already </div><div class="">implemented in <i class="">libDC</i> project.</div></div></div></div></blockquote><div><br class=""></div>No; I thought I explained this before we started...</div><div>libdivecomputer has two reasonably distinct parts.</div><div>The communication with the dive computer and the</div><div>parsing of the data that was downloaded from the</div><div>dive computer.</div><div>My goal is to do the communication with Bluetooth</div><div>based dive computers from within Subsurface and</div><div>then pass the data buffers to libdivecomputer for</div><div>parsing.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">I already tested the <b class="">serial_write</b> and <b class="">serial_read</b> methods </div><div class="">from <i class="">libDC</i>, using the <i class="">QtBluetoothSocket</i> descriptor and </div><div class="">they work. These are the basic methods used to </div><div class="">communicate with the device in <i class="">libDC</i>. </div><div class=""><br class=""></div><div class="">The only problem is that I need to call somehow the</div><div class="">initialization method to initialize the <i class="">vtable</i> of the </div><div class="">device which stores functions pointers to some device </div><div class="">specific implementation for read/write methods.</div><div class="">As I said, the initialization is done in the <b class="">open</b> method </div><div class="">and I don't know how to fake its call. I cannot manually </div><div class="">initialize the <i class="">vtable</i> because the methods are declared </div><div class="">static.</div></div></div></div></blockquote><div><br class=""></div>I don't think that's the right way to go. Of course, we have</div><div>our own branch of libdivecomputer and we could always</div><div>make changes, but that would move us further and further</div><div>away from upstream which is the opposite of what I'd want</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">If I find a way to initialize the <i class="">vtable</i> and to replace </div><div class="">the serial port descriptor with my socket descriptor, then</div><div class="">I expect things to work.</div><div class=""><br class=""></div><div class="">Do you have any suggestions how to do that? Do you </div><div class="">believe that this is a bad idea? Should I give up with the </div><div class="">Qt Bluetooth API and move further?</div></div></div></div></blockquote><div><br class=""></div><div>I think you should consider just using the parser from </div><div>libdivecomputer and doing the downloading entirely</div><div>in Subsurface.</div><div><br class=""></div><div>/D</div><div><br class=""></div></div></body></html>