On Mon, Jun 15, 2015 at 09:20:44PM +0300, Claudiu Olteanu wrote: > > > > > > > > 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.
The reason we explored QtBluetooth was that I was told that in Qt5.5 it was going to support all our platforms. It appears that this was wrong an it supports all except for Windows :-( > 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. You are right. > 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. OK. How are you going to implement the OS X Bluetooth stack in libdiveceomputer? How about Android? And (here's hoping) IOS? > 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. Part of the appeal to implement BT in the application and not in libdivecomputer is the whole question of a seamless experience to the user when it comes to pairing with a device. The application creates the communication and allows libdivecomputer to talk to the device through the socket it opened... /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface