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