On 2014-05-21 16:42, Anton Lundin wrote:

I just saw that Qt 5.3 was released and that contains bluetooth support, and that includes android too: http://qt-project.org/doc/qt-5/qtbluetooth-index.html

I think it would be awesome if we could add Qt Bluetooth support to libdivecomputer, and while where at it, maybe Qt Serial support to. We would probably build them as a default-off build option.

Do you think it would be a patch you can accept Jef?

For serial communication I don't see the point. We already have a working implementation that requires no external dependencies. So why would you want to use Qt instead? Using Qt won't solve the usb-serial driver problem on Android for example.

For bluetooth communication I'm not sure yet. Qt is a rather large dependency for a small library like libdivecomputer. I'm aware that alone isn't a good enough reason to reject your proposal, but it is something to take into account. I also wonder whether a dependency on Qt would cause problems for non-Qt based applications (e.g. Gtk)?

It seems that the Qt Bluetooth only supports Linux and Android. So that means we'll still need something different on Windows and Mac OS X. For Linux we already have my prototype code, so Qt would mainly bring us Android support.

The truth is that I don't have a good answer to your question at the moment. I certainly don't mind prototyping with Qt Bluetooth, but I'm not sure whether this will be the best solution in the long term...

At least one if the libdivecomputer based apps, Subsurface, is built with Qt and it would be a nice way to abstract it away. And it would probably help a bit in getting Subsurface more usable on Android.

What do you mean with "abstract away"? If libdivecomputer would use Qt internally, that would be completely transparent to the application (e.g. not exposed in the public api).

Jef