On 2015-03-19 14:23, Lubomir I. Ivanov wrote:
On 18 March 2015 at 05:48, Dirk Hohndel <[email protected]> wrote:
Thiago,
would Subsurface benefit from using Qt Bluetooth for our intended
Bluetooth integration?
This would cause some interesting architectural challenges with
libdivecomputer (as that most definitely doesn’t want to depend on
Qt), but I find it very intriguing that Qt now supports all of the
platforms we are interested in… or am I missing something here?
i can see that libDC has a parser API exposed, but i don't know if /
how does that works, but if Subsurface uses Qt's BT it can in theory
just use libDC as a parser (Thiago mentioned the same).
It works (almost) exactly the same as for data downloaded from a dive
computer. The parser doesn't care whether the data was downloaded with
libdivecomputer or not.
There is only one extra complication. After downloading the dives with
libdivecomputer, you typically use the dc_parser_new() function to
create the parser. For parser backends that require some additional
metadata (e.g. model number and clock synchronization timestamps), this
function will automatically take care of transferring the metadata from
the device layer to the parser. That's something you'll have to do
manually.
i think it would be better for the student to first help Jeff get the
BT working in libDC for Win32 and Linux and then start working on the
Subsurface side.
My prototype code is almost fully functional at this point. What's
lacking is the proper integration in the libdivecomputer api. The way I
did this for the prototype (with #ifdef's) is nothing more than a
temporary hack. I have some ideas on how to do this properly (see
details below). But this will require some major redesign of the api,
and therefore will have to be postponed until after the next v0.5
release.
The main idea for the api change is as follows. Instead of passing the
name of the serial port to the dc_device_open() function, and let
libdivecomputer open the serial port internally, this will now be
delegated to the application:
dc_serial_t *serial = NULL;
dc_device_t *device = NULL;
/* Open the serial port. */
dc_serial_open(&serial, devname);
/* Open a connection to the device. */
dc_device_open(&device, context, descriptor, serial);
/* TODO: Download dives here (same as before). */
/* Free resources */
dc_device_close(device);
dc_serial_close(serial);
The main benefit is that this change will allow us to pass something
else than just a string (with the name of the serial port). For devices
that use bluetooth communication, the application opens a bluetooth
socket, and passes that to the dc_device_open() function:
dc_bluetooth_t *bluetooth = NULL;
/* Open a bluetooth socket. */
dc_bluetooth_open(&bluetooth, macaddress);
/* Open a connection to the device. */
dc_device_open(&device, context, descriptor, bluetooth);
Note that applications can query the device descriptor to figure out
whether a device uses serial or bluetooth communication. That
functionality is already present.
There are two other important advantages too. This will also allow us to
expose the built-in serial port enumeration (and for bluetooth the
device discovery) to the application. It will also makes it possible to
implement user-space serial drivers for mobile devices (e.g. Android and
iOS) where we typically don't have the required usb-serial kernel
drivers.
but...if the OSX code is not going to be donated soon (or maintained
well in that aspect), i suggest we just use Qt's BT.
As Dirk mentioned, a dependency on Qt is far from ideal for
libdivecomputer. So I would like to avoid that. But at the moment I see
no reason to use Qt on Windows and Linux. The main problem will be Mac
OS X. But I think that if we can already support bluetooth on Windows
and Linux, that would already be a nice improvement. Worst case
scenario, Mac users will have to stick with the serial emulation a bit
longer.
there is also the option for libDC to expose API to allow the libDC
user to specify the BT backend (e.g.. built-in VS external C-wrapped
Qt BT), but that's probably a ton of extra work for Jeff.
I already considered this, but I believe it's a very bad idea in the
long term. Because the low level communication is maintained as a
built-in backend today, all applications are equal and are able to
support the same set of devices. But that will no longer be true when
applications can use their own backend. Then you'll end up with a
situation where application X can support a certain device, while
application Y can't. Remember that not all libdivecomputer based
applications are open source! (Note that I don't mind closed source apps
using libdivecomputer. But I do mind closed source improvements that are
not contributed back. I picked the LGPL license for a reason.)
Jef
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
