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
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface