Fwd: feedback on experience with OSX packaging

[Jef Driesen]

On 2012-10-08 17:44, Mikko Rasa wrote:
> On 08.10.2012 11:28, Jef Driesen wrote:
>> One of the things you could do is enumerate the serial ports on the
>> system, and list them in the GUI (a dropdown or something). It's 
>> already
>> a bit more user friendly than having to find the device name 
>> manually. I
>> even considered adding support for enumerating ports in 
>> libdivecomputer,
>> but it turned out to be pretty difficult to implement correctly. On
>> Windows the enumeration api is different for each Windows version, 
>> on
>> Linux I don't know how to do it all, and Mac OS X probably has an 
>> api
>> for it too, but I'm not very familiar with it.
>
> On Linux, you'd go through /dev/tty* and ignore those with just a
> numeric identifier (virtual consoles).  The most common patterns are
> ttyS* (traditional serial ports), ttyUSB* (USB-serial converters) and
> ttyACM* (USB modem class devices I think).  There's also /dev/rfcomm*
> for bluetooth devices, but I don't think those are relevant here.

Scanning the /dev filesytem for a few well known names is also the best 
solution I can come up with. But it's maybe not the most reliable 
solution. If there happens to be a device with some non-standard name, 
it won't be detected.

The PySerial project also searches for some well know names (with the 
names adapted for several unix variants):

http://pyserial.svn.sourceforge.net/viewvc/pyserial/trunk/pyserial/serial/tools/list_ports_posix.py?revision=455&view=markup

The rfcomm entries are relevant too. We already support one dive 
computer that uses bluetooth rfcomm (the Heinrichs Weikamp Frog), and 
another one is being worked on (Shearwater Predator).

BTW, this enumeration problem exists for IrDA too (e.g. the Uwatec 
Smart/Galileo dive computers). In this particular case, the enumeration 
is done internally, and we just pick the first match (e.g. basically any 
device with "Uwatec" in its name). This works as long as there is only 
one device present. If you happen to have two, or name some other device 
"Uwatec", you'll have some trouble downloading your dives :-(

>>> Of course of different dive computer cables require different 
>>> device
>>> names we may need to change the DC selector that we have today into
>>> something more like "Suunto (Gecko, Vyper Family, etc) with Suunto
>>> cable", "Suunto (Gecko, Vyper Family, etc) with Idea cable", ...
>>
>> With a list of the available ports on the system, that shouldn't be
>> necessary. It's very unlikely a user will have multiple types of 
>> cables
>> connected at the same time, so normally the list will contain just 
>> one
>> entry.
>
> While there's perhaps likely to be only one dive computer cable,
> there may be other serial ports as well.  USB-serial converters are
> fairly popular with all kinds of embedded devkits, although I'd
> imagine the users of those know what they have connected to their
> system.  Windows machines might also have all sorts of random virtual
> serial ports.
>
> Not that listing the available ports would be a bad idea, but having
> more than one port is a very real possibility.

Sure, there can be multiple serial ports present. That's fine, but I 
assume the majority of the users will have just one (or very few). Even 
if you own multiple "gadgets", they are probably not permanently 
connected, especially on a laptop.

Anyway, in most cases (e.g. a real rs232 port, a generic usb-serial 
converter, etc) it's impossible to figure out whether a serial port is 
associated with a dive computer interface or not. In that case, listing 
the available ports is about the best we can do. (In theory we could 
probe the serial ports too, but it's not technically possible for all 
devices and probably also slow.) The user is still responsible to pick 
the correct one, but at least he doesn't have to find the possible 
choices manually. I think it's safe to assume the average end-user 
doesn't  know how to run "ls /dev/tty*" in a terminal :-) And ideally 
that shouldn't be necessary either to use subsurface (or any other 
similar application).

Jef