Dirk,
Sorry for the slow response. Been busy with real life.
On 2015-06-17 16:45, Dirk Hohndel wrote:
I don't know which other apps use libdivecomputer, but the ones that I
know about...
Subsurface: happy to implement a Bluetooth backend, happy to use the
existing libdivecomputer
On Wed, Jul 15, 2015 at 08:57:22AM +0200, Jef Driesen wrote:
Sorry for the slow response. Been busy with real life.
I know that feeling well.
On 2015-06-17 16:45, Dirk Hohndel wrote:
I don't know which other apps use libdivecomputer, but the ones that I
know about...
Subsurface: happy
On 2015-06-15 20:26, Thiago Macieira wrote:
On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote:
On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote:
I did already think about this :-) See [1] for some more background info.
In a nutshell, the serial layer will be changed from a
On Wed, Jun 17, 2015 at 04:20:42PM +0200, Jef Driesen wrote:
On 2015-06-15 20:26, Thiago Macieira wrote:
On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote:
On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote:
I did already think about this :-) See [1] for some more background info.
Hi,
On 17.06.2015, at 16:45, Dirk Hohndel d...@hohndel.org wrote:
No one suggested that the application HAS to provide that functionality.
What we are suggesting is to make this an OPTION. If the application wants
to do this...
I did not follow this discussion in all details. But maybe I
On 15 June, 2015 - Claudiu Olteanu wrote:
Ok. In the beginning I will try to implement the downloading
entirely in Subsurface and re-implement the dive computer
protocol for HW OSTC family.
I think this is a bad path.
I would rather suggest something like implementing a serial backend in
On 2015-06-15 13:46, Anton Lundin wrote:
On 15 June, 2015 - Claudiu Olteanu wrote:
Ok. In the beginning I will try to implement the downloading
entirely in Subsurface and re-implement the dive computer
protocol for HW OSTC family.
I think this is a bad path.
I would rather suggest
On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote:
I did already think about this :-) See [1] for some more background info.
In a nutshell, the serial layer will be changed from a concrete
implementation into an abstract interface. This will allow us to have
multiple
On Mon, Jun 15, 2015 at 12:19:32PM +0300, Claudiu Olteanu wrote:
Ok. In the beginning I will try to implement the downloading
entirely in Subsurface and re-implement the dive computer
protocol for HW OSTC family.
To be honest I believe that a better idea would be to
continue the work you
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
On Monday 15 June 2015 06:13:54 Dirk Hohndel wrote:
On Mon, Jun 15, 2015 at 03:01:44PM +0200, Jef Driesen wrote:
I did already think about this :-) See [1] for some more background info.
In a nutshell, the serial layer will be changed from a concrete
implementation into an abstract
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
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 :-(
Well, no.. Sorry to disappoint you. For Qt 5.5 it is planned
to offer support for iOS and OS X and a stable
On Mon, Jun 15, 2015 at 10:03:32PM +0300, Claudiu Olteanu wrote:
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 :-(
Well, no.. Sorry to disappoint you.
On 2015-06-14 23:43, Claudiu Olteanu wrote:
Thanks for your suggestions, Jef!
I can definitely do that but I was looking for a solution which
doesn't imply changes on *libdivecomputer* project. An ideal
solution which is implemented on *Subsurface* project and
doesn't need to re-implement the
Hi,
As you can see I am having some troubles and I don't
know in which direction to go. If we want to implement
the data transfer using the Qt Bluetooth API, then we
should find a way to integrate it with the implementation
of the serial port communication from *libDC* project.
If this is not
No; I thought I explained this before we started...
libdivecomputer has two reasonably distinct parts.
The communication with the dive computer and the
parsing of the data that was downloaded from the
dive computer.
My goal is to do the communication with Bluetooth
based dive computers
Thanks for your suggestions, Jef!
I can definitely do that but I was looking for a solution which
doesn't imply changes on *libdivecomputer* project. An ideal
solution which is implemented on *Subsurface* project and
doesn't need to re-implement the dive computer communication
protocol.
Although
On 14-06-15 21:56, Dirk Hohndel wrote:
On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu
Do you have any suggestions how to do that? Do you
believe that this is a bad idea? Should I give up with the
Qt Bluetooth API and move further?
I think you should consider just using the parser from
On Mon, Jun 15, 2015 at 12:22:36AM +0300, Claudiu Olteanu wrote:
No; I thought I explained this before we started...
libdivecomputer has two reasonably distinct parts.
The communication with the dive computer and the
parsing of the data that was downloaded from the
dive computer.
On Jun 14, 2015, at 12:00 PM, Claudiu Olteanu
olteanu.vasilica.clau...@gmail.com wrote:
Hi,
As you can see I am having some troubles and I don't
know in which direction to go. If we want to implement
the data transfer using the Qt Bluetooth API, then we
should find a way to
21 matches
Mail list logo
