[PATCH] QtBluetooth implementation

Claudiu Olteanu olteanu.vasilica.claudiu at gmail.com
Fri Jun 26 08:55:11 PDT 2015


Hello,


> Just to make sure we get the terminology straight... the "local device" is
> your computer or tablet or whatever Subsurface is running on, the "remote
> device" is the BT dive computer, correct?
>

When I said the local device I was referring to the local Bluetooth device
where the Subsurface is running on. The remote device is the dive computer
which has support for Bluetooth.



> I assume that means turn on/off BT support on your computer?


Yes, that is what I meant to say. I should have been more specific.



>
> This message seems off as a user facing message. The QtConnectivity
> libraries would have come with the install - either as dependency or Linux
> or bundled with the executable on Windows / Mac. What other reasons could
> there be for this test failing? Bluetooth turned off maybe?
> Think of this as something you tell the user so she can fix it...
>
>
If the Bluetooth is turned off it wouldn't be a problem. I faced this issue
when I played with the BlueZ and Qt versions and the Qt framework couldn't
connect to the local Bluetooth device using the BlueZ stack. One of the
reasons
was that that the qtconnectivity library was missing or the BlueZ was not
installed correctly.
If the dependencies are installed correctly this should never happen.



> Many BT UIs do that... I always wonder if it wouldn't be better NOT to
> show the hex address if you have a name...
>

Probably they use the address because it is unique. Two Bluetooth devices
may have the same name and you could easily choose the wrong one.



> So the close function above frees the device when it closes it.
> Is the caller required to set it to NULL? Because if someone
> passes a device to close() (and the memory gets freed) and then
> to read() (admittedly a bug) then you dereference freed memory
> here.
>
> I guess that's just how the API works?
>

Yes, you are right. I should probably set the device to NULL after
the memory was freed. For the moment this is not a problem
because the close method is called on libdivecomputer project
and after this happens no other operations are called.

Not having looked at the API in enough detail... but to me
> "get_transmitted()" sounds like how much has been transmitted,
> whereas "bytesToWrite()" sounds like a count of data in a queue...
>
>
The bytesToWrite function returns the number of bytes that are
waiting to be written. The native serial implementation uses
the ioctl TIOCOUTQ command to get the number of bytes in the
output buffer so I though that it would be ok if I will use
the bytesToWrite method to get the expected results.


Sorry if the messages from the commits had some spelling issues
or if they were too coincise but I spend a lot of time to resolve
the merging conflicts and after a while I decided that it would be
a lot easier for me to create a new branch and to commit again my
sources :-).

Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150626/b0f5933e/attachment.html>


More information about the subsurface mailing list