On Mon, Dec 22, 2014 at 08:40:35AM +0200, Willem Ferguson wrote:
> On 21/12/2014 22:43, Dirk Hohndel wrote:
> >So one of the things that I thought we should make easier for new users is
> >the ability to add dives that they have in a paper logbook.
> >
> >So what I think we SHOULD support is something like this:
> >
> >"dive number", "date", "time", "duration", "max depth", "avg depth", "air 
> >temp", "water temp", "start pressure", "end pressure", "location", 
> >"divemaster", "buddy", "notes", "suit", "rating", "visibility"
> 
> Two issues:

Only two? That's better than average for my proposals :-)

> a) The proposed headings. It would make things much more user friendly if
> the import could only require any or all of the above fields. Define a full
> set of headings recognised by Subsurface (like above) and require that there
> should be at least date, time, duration, depth. Then the user can use any
> subset or the full set of the remaining headings.

Oh yes, certainly.

BUT: I don't think it makes sense to parse the headings. We only get in
trouble with translations and stuff. We already have a fairly flexible
concept with the manual input where the user simply selects which column
is what. But the UI for that is HIDEOUS (no offense to the perpetrator).

At the bare minimum, it should do this:
The first checkbox I click gets column 1
The next checkbox I click gets column 2
etc.
Afterwards one can still use the spinners to change the values if the
order was wrong, but this will make things much easier.

What would be MUCH nicer would be this:

The CSV file is opened and the first few rows are shown in a grid.
We have tags for the different types of columns. And one can drag and drop
those tags to the top of the correct column. Beautiful, intuitive, easy.

Hey Tomaz, what are you doing today :-)

> Similarly on export, do not use any of the standard set of headings (above)
> which do not have valid data.

Just have an empty column. Case in point - the gentleman on scubaboard.com
who wants to add start and end pressure to his dives. Export a spreadsheet
that has those two columns that just aren't filled. Then he can just go
ahead and populate those two columns and re-read the same spreadsheet.

And by always exporting the full list we can indeed have THAT format as
one of the preselects (just like we have APD and Seabear already).

> b) The biggest problem, however, is the data format. For CSV I would expect
> a pretty formal comma-delimited format, probably enclosing strings with
> quotations, like in the list above. As far as I understand the current CSV
> import does not require a string delimiter because a field delimiter (comma,
> tab) is sufficient. Because, even with tab-delimited data, the headings and
> the rest of the data are unlikely to align nicely in a text file, a more
> friendly mechanism is required. With LibreOffice one has pretty good control
> over the export with options for both a text delimiter and a field
> delimiter. But Windows does crazy things. By default it has no string
> delimiter and it uses a comma as a field delimiter and as far as I can
> ascertain one cannot set the field delimiter to anything else than a comma.
> So TAB is out, as I discovered after opening the CSV export file using a hex
> editor. BUT, one can get a tab-delimited file by exporting it as a .txt
> file.

Excel sucks. Tell me something I don't know.

So the easy solution is to say "just download LibreOffice, it's free".
Or we could figure out an easy to reproduce way to create a tab delimited
file with the .txt export.
I have access to a couple different versions of MSOffice for Windows and
Mac. I could look into this if I was bored :-/

> So the biggest problem is defining a user friendly interface that allows
> rapid entry of the dive data and which allows for an export that Subsurface
> can recognise cross-platform (almost surely spreadsheet software). This is
> the part that will require the largest amount of planning.

See above. If we got this all to work in the next few days, I'd be tempted
to use that (plus the OSTC firmware upgrade) as enough features to justify
releasing Subsurface 4.4... :-)

> Currently LibreOffice and Excel should produce the same CSV files if a
> string delimiter is not used and a comma is used for a field delimiter. But
> comma-delimited files are a pain to fine-tune by hand, for instance if
> Subsurface finds some formatting problem on line 22 of the import file.

No, we should strongly urge people to use tab delimited files. In many
locales comma is a non-starter (see German where you have a decimal comma)

/D
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to