> > So we agree that this is a reasonable way to do things. > > And then on the Subsurface side we use QtBluetooth plus a Windows specific > Bluetooth implementation. > > Correct? >
Yes. The Windows specific Bluetooth implementation could be either on Subsurface side or on libdivecomputer side. It will be beneficial to be on libdivecomputer because it can be reused by other applications and it was already started. But we don't have to decide this now. Its implementation doesn't depend on which side we choose and it is scheduled after the QtBluetooth one. The QtBluetooth implementation will be definitely on Subsurface side. We just have to find a way to pass the callbacks for basic operations. I believe that the solution should be compliant with API's modification that Jef intends to do for the new release and to imply a minimal number of changes to libdivecomputer project. For the moment I can add a new *dc_device_open* method which receives a reference to a serial structure and holds callbacks for basic operations, or I can use the idea proposed by Anton. I can check the serial type and if it is a bluetooth one then skip the *serial_open* and the *serial_configure* steps and replace the serial fd with the socket descriptor. As I said it before, I expect the current *serial_write* and *serial_read* methods to work with my socket descriptor. If they don't work, then we will pass references to some custom implementations.
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
