[GSoC] Week 3 (Native Bluetooth support)

[Claudiu Olteanu]

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150615/cee29a0a/attachment.html>