First time subsurace usage surprises

[Linus Torvalds]

On Mon, Jul 30, 2012 at 4:28 PM, Lutz Vieweg <lvml at 5t9.de> wrote:
>
> subsurface does not seem to have a "default" file where it stores dive data.
> I wonder how many people actually favour to manually open and save their
> dive data file upon every start / ending of the program.
> (I will certainly apply a local patch for me to use a default data file name
> that is automatically opened / saved on start / exit.)

I don't know what the default file would be, but I don't hate the
idea. It didn't make sense originally, because the early workflow was
so much about "let's load and change and save to another file and
compare the differences", but that was really quite early. These days,
subsurface is useful for actual *users*, which changes these kinds of
interface decisions.

> When saving data, subsurface did not suggest a certain file extension, so I
> used none.

Yeah, that's just because I don't know the gtk file stuff well enough.
I'm sure there's some way to set the extension for saving, the same
way there's one for doing it on the loading side.

> I miss a feature to change attributes of several dive logs at the same time.

I do too. I'd love for the multi-selection to work for all the
equipment issues etc. It doesn't, and it's non-trivial to fix.

Some of the equipment stuff is very tightly linked with the "current
dive" thing, and worse, some of it is linked to not just the dive, but
the actual printing of the dive data in the current view. You can see
that when you do a "Add new dive", and get the cylinder equipment
thing: it's actually getting the data from the dive that was displayed
when you selected "Add new dive". The creation of the model for the
cylinder is incestuous with the actual display routines.

That needs fixing, since it causes actual buggy behavior even with
that single dive case, but it's nasty gtk internal stuff, and I didn't
get around to fixing it properly when I did the "add new dive" stuff.

> While reading data from my D9 I got some "failed to receive the answer"
> messages.

Jef already answered this one. The occasional one is not a problem,
just ignore them. I'd love to show them in the GUI (and *hide* them if
we get good data afterwards), but most of those things are actually
stderr output from libdivecomputer.

> (And actually, USB drivers of all kinds are amongst the least stable drivers
> I have ever experienced under any OS... *shudder*... ;-)

In this case, it really isn't the cause of USB. The Suunto electricals
are just not very nice. They chose to do a two-wire communication
model, so it has the whole half-duplex issue *and* it's electrically
apparently not very stable. No clock lines, no nothing. So it's just
rather timing-sensitive.

> The print-feature looks really good - but I miss a feature to print a much
> more simplistic one-line-per-dive list that I would like to carry in my
> luggage (I don't want to waste precious air luggage weight by printing a
> thick book of details on all my dives... :-)

I like our printouts, and we spent some effort on it, but yeah, I
could imagine a denser text-only format without the profile.

Patches welcome.

           Linus