<p dir="ltr"><br>
On 14 Oct 2014 17:28, "Dirk Hohndel" <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> wrote:<br>
><br>
> So far Subsurface has been primarily designed around the idea that it<br>
> would collect the data from a divecomputer, visualize it in a compelling<br>
> way and add a few more items that seemed interesting to the initial<br>
> developers.<br>
><br>
> Reading through feedback, feature requests and reflecting on conversations<br>
> on IRC it has become clear to me that there are people who want a lot more.<br>
><br>
> There's Henrik (and I'm sure others) who want a dive site database.<br>
><br>
> There are a number of people who wanted a way to track equipment, serial<br>
> numbers, deadlines for service and replacement. We have / had the rather<br>
> sad "in memoriam Jan Schubert" feature request in trac...<br>
><br>
> There was an interesting discussion about the way we could improve<br>
> tracking of gear that people take on a dive; this started out with a<br>
> conversation about undergarment types and dry suits, but if you really<br>
> want to track the weight of your gear you need to be able to track lights,<br>
> cameras, action (sorry for the Wiggles reference).<br>
><br>
> So I've been mulling this over for a while, trying to figure out what this<br>
> means for Subsurface.<br>
><br>
> Here are a few ground rules:<br>
><br>
> a) this needs to work reasonably seamlessly with older data files<br>
> b) this needs to all be opt-in, i.e. people who don't want to track these<br>
> things shouldn't be bothered by them, they shouldn't clutter the UI, etc<br>
> c) this needs to be done in way that is intuitive and easy to use<br>
><br>
> Oh wait, we don't have a UI designer driving this. Crud. We so desperately<br>
> need UI designers. It's not even funny.<br>
><br>
> Having said that, here's what I came up with:<br>
><br>
> Equipment:<br>
><br>
> we could take the current Equipment tab and replace 'Weights' with<br>
> 'Equipment' and allow people to track everything that they take on a dive.<br>
> That could be done fairly transparently, even in more or less the same UI<br>
> we have today. I'm a bit worried about the 'weight' property because what<br>
> I /really/ care about is not the weight on land but the relative buoyancy<br>
> under water, but of course even for weights we don't track that (I always<br>
> find it amusing that most people don't get that... a one pound weight does<br>
> NOT add one pound of negative buoyancy...)<br>
></p>
<p dir="ltr">If only someone could devise a set of units that distinguished between weight and mass...</p>
<p dir="ltr">Even in metric countries where we should know better, we're just as confused.  Having said that, do you really care that 12 lb mass of lead has a buoyant weight of 11 lb?</p>
<p dir="ltr">The mass vs buoyant weight difference does become significant with less dense equipment, such as fins and lights.</p>
<p dir="ltr">> Then we could add a new screen (new window, new... something... where's<br>
> that UI designer?) where we allow people to track additional data for each<br>
> 'equipment' that is ever mentioned in a dive (so the same auto-completer<br>
> idea). We then add a number of columns. make, model, serial#, purchase<br>
> date, next service date, weight (see above)... what else is missing?<br>
><br>
> We then need a reminder function for the service date... no idea... Google<br>
> calendar integration? Suggestions?<br>
><br>
> And of course we need to store all this. That would likely be an equipment<br>
> section after the settings section in the XML file (and equivalent in<br>
> git).<br>
><br>
><br>
> Dive sites:<br>
><br>
> I would strongly want us to keep the current free form Location field.<br>
> We could then have some super-imposed structure in a dive site UI (did I<br>
> mention that we need a UI designer?). Something like<br>
> <site>, <city>, <coutry><br>
> I'm actually struggling here a bit. I really really want to keep this<br>
> entirely optional for people like myself (he...) and at the same time make<br>
> it useful for those who like more structure... so how could this be done<br>
> so that existing data can be parsed and then the dive sites database can<br>
> connect bidirectionally to the location field?<br>
> Anyway, the UI would include address, GPS (from the Info tab), additional<br>
> fields (Henrik?)<br>
> All this could then also be saved in yet another section in the XML / git.<br>
></p>
<p dir="ltr">I have no idea how or if it would work, but could the Marble libs be used to determine country/state/province of sites based on lat/long coordinates? Whether this is stored separately or calculated on the fly is another question.  It would avoid having to impose a structure on the location text.</p>
<p dir="ltr">><br>
> What do people think? Has the German water poisoned my brain? Am I<br>
> completely off in lala land? Or is this maybe something we should pursue?<br>
><br>
> /D<br>
> _______________________________________________<br>
> subsurface mailing list<br>
><a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.org</a><br>
><a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface">http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface</a></p>