On Tue, Oct 28, 2014 at 12:25 PM, Dirk Hohndel dirk@hohndel.org wrote:
So yes, let's figure out a sane way to hand data like that back to the application.
.. the email you wrote was an answer to teh email where I already told you what my suggestion was. But you answered with the completely unacceptable "DC_SAMPLE_VENDOR", which completely misses the point, exactly because it is *not* defined to be strings.
Let me quote it:
"So I think we might want to introduce an event type that literally gives two strings: a description and a value. And then subsurface can show that in an information window or something (maybe similarly to how we show the dive computer name - hover over the name, and get the dive computer "random data" fields"
So I literally suggest just "DC_SAMPLE_STRING", which comes with a structure that has two constant strings: the "descriptor" and the "value". Nothing else. No structure, no rules except for "strings for human consumption".
For the battery thing, it could be
{ "Battery at start of dive", "Charge: 98%, Voltage: 4.157V" }
but it could also be things like
{ "Dive algorithm", "Suunto RGBM" }
or for things like the Uemis (if it were ever converted to libdivecomputer):
{ "Suit", "3-5mm wetsuit" }
just to give a non-EON-Steel example. The point being that most modern dive computers have these kinds of random fields that it definitely isn't worth trying to organize a data structure for.
And then, subsurface could certainly try to match some strings (ie maybe we could catch that "suit" thing), but others it would just show in a popup when you hover over the dive computer name. Or add to the "Notes" window by default (although that would probably be annoying). Or something like that.
Linus