> > One of the things that I would like to see as part of the project > deliverables is of course documentation / addition to the user manual. > There we need to be especially careful to do this in a way that makes > sense to the non-technical person... just a diver with a computer.
I will write the documentation after I will create a functional prototype for all the devices. So I wonder what a good message would be. We have a few messages that are > basically "This should never happen, please contact the Subsurface > developers and tell them <bla>" (I am paraphrasing, of course, but that's > the idea). I think that would be more appropriate. Yes, it is a better message. In this way the user will not be confused with unnecessary information. For the average diver... how many do you think can make any sense of that > Bluetooth address? Maybe show it if someone hovers over the name? But if > we have a name I really wouldn't show it in the UI > I thought that it will be enough to show the name of the device in the selection dialog and use its address on the device combo box. In the communication process I only need that address and it was easier for me to save it on the *ui.device* combobox. If you want I can fill the text with the name of the device. > The way the API works you would have to set the variable to NULL in the > caller - doing so in the function won't make a difference, right? Yes, it won't make a difference. The current native serial implementation doesn't set it to NULL. If someone wants to use the device after it was closed it means that there is a problem with its logic and the program should exit with failure. > Usually I find merging in git really easy, assuming you use the right > tools. Visual 3-way merge helpers like meld are really wonderful. > Thanks for the tips. I usually use Meld when I need to work with TFS repositories on a Linux platform. It is a great tool but in that day I totally forgot about it.
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface