Dirk Hohndel [Fri, 10 Aug 2012 20:43:16 +0000 (13:43 -0700)]
Don't print a total weight of 0 in the weight column
For consistency with the rest of the dive_list we should interpret "no
weight systems recorded" as "no information" and therefore print nothing
instead of printing a total weight of "0" for these dives.
Dirk Hohndel [Tue, 7 Aug 2012 18:24:40 +0000 (11:24 -0700)]
Add total weight column to divelist
This adds the total weight carried on the dive in different weight systems
to the divelist. The column is by default not shown, which can be changed
in the preferences. The column is sortable.
Dirk Hohndel [Mon, 6 Aug 2012 21:03:24 +0000 (14:03 -0700)]
Fill the list of weightsystems from data in existing dives
This was simply an omission in the current implementation. All the
plumbing was there but never got hooked up with the fixup_dive function as
intended.
Dirk Hohndel [Mon, 6 Aug 2012 20:56:46 +0000 (13:56 -0700)]
Remove weightsystem entry with no description
This existed in the initial implementation to deal with an implementation
problem that was long since resolved. So now it just created just an ugly
empty line in the drop down menu for weightsystems.
Dirk Hohndel [Mon, 6 Aug 2012 19:55:55 +0000 (12:55 -0700)]
Remember the last weight used per weightsystem
With this change, if the user adds a new weightsystem to a dive, on
subsequent edits the weight amount for this weightsystem no longer
defaults to 0 but to the last weight that was used with this weightsystem.
So when the program imports a set of dives from the divecomputer and the
user starts editing them, once they enter the weight for the "integrated"
weightsystem the first time, for each of the consecutive dives that same
weight is the default once "integrated" is selected - which usually will
be the correct amount.
Andrew Clayton [Thu, 12 Jul 2012 22:28:47 +0000 (23:28 +0100)]
file.c: Fix a file descriptor leak in readfile()
In file.c::readfile() the file was being opened once at fd declaration
time and then again a few lines later and only being closed once. Remove
the open() at fd declaration time leaving the later one where the fd check
is done.
Signed-off-by: Andrew Clayton <andrew@digital-domain.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update for libdivecomputer pkg-config include file changes
Subsurface doesn't compile on OS X any more, because libdivecomputer
changed the way the header inclusion works: the include path from
pkg-config no longer includes the final "libdivecomputer" component, and
instead of doing
#include <header.h>
for libdivecomputer headers, we're now supposed to do
#include <libdivecomputer/header.h>
instead. Which is cleaner anyway.
The reason this only bit us on OS X is that I never trusted pkg-config
that much for non-system libraries on Linux (maybe it works, maybe it
doesn't, I've seen it go both ways), so on Linux we just used our own
version of the include path, and thus weren't affected by the
libdivecomputer config change.
Clean up the includes while at it - we no longer need (or want) the
device-specific header files, since we just use the generic functions.
Fix a couple of possible divide-by-zero conditions in statistics
Several people reported the average time problem, but there's another
one lurking there too: if the dive duration is zero, you get bogus
average depth information too (but because that one was a floating point
divide, and by default they are unsignalling on x86, it didn't crash, it
just resulted in bogus results).
Linus Torvalds [Thu, 28 Jun 2012 01:56:41 +0000 (18:56 -0700)]
Make the 'Add Dive' dialog at least slightly less butt-ugly
I still suspect that using spinbuttons for the time handling is the
wrong way, and I'm a bit surprised the Calendar widget doesn't have a
mode where you can see/set the time too.
But this makes things at least minimally prettier, and initializes the
time entries to the current time (which is obviously not what anybody
really wants, but looks a lot better than defaulting to "midnight" or
some other random time that *also* won't be what anybody actually
wants).
I think this might be something we can live with, although I hope
somebody with good taste comes along and say "don't use spinbuttons, do
this: xyzzy" and makes things look better yet.
Also, I have this suspicion that I should put the time/depth/duration
stuff to the right of the calendar. Most displays are wider than they
are tall, so tall and skinny dialogs are bad especially if you have
limited vertical pixels. I still have flashbacks to my netbook-using
days, hating applictions that did that.
Linus Torvalds [Wed, 27 Jun 2012 21:29:29 +0000 (14:29 -0700)]
Add depth entry to new dive edit dialog
Christ, if you look up "Ugly dialog" on Wikipedia, I think it has a
picture of this "New dive" thing. Or it should have.
But it kind of works. Although with only a "max depth" entry, you can't
currently set average depths etc, so SAC-rates etc cannot be calculated
for these kinds of dives.
And the dive numbering is wrong. We do auto-number new dives that get
added at the end, but we do it as we add them, so when you *edit* the
dive information (before it has been added) the dive number shows up as
"#0".
Linus Torvalds [Wed, 27 Jun 2012 20:11:54 +0000 (13:11 -0700)]
Rough "Add new dive" infrastructure in the divelist
Do a right-click to get a menu with the "Add dive" entry. Should do
delete too, but that's for later.
What's also apparently for later is to make this *useful*. It's the
butt-ugliest time entry field ever, and there's no way to set depth for
the dive either. So this is more of a RFC than anything truly useful.
Linus Torvalds [Fri, 22 Jun 2012 20:37:39 +0000 (13:37 -0700)]
Update to new sane libdivecomputer interfaces
This does mean that you have to build subsurface against a new version
of libdivecomputer, and that version is likely going to have various
slightly incompatible changes. But the new interfaces allow for easily
adding new supported dive computers without subsurface having to be
updated for each new vendor and model, so some slight pain is definitely
worth it this time.
I'm not even going to try to have some backwards-compatible version
here, the libdivecomputer interface changes are so extensive. Native
enumeration of devices is just the smallest part of it: the constants
and types that libdivecomputer uses now have much nicer names that all
start with DC_ or dc_, so you don't get the kinds of name clashes we had
with "gasmix_t" etc.
Linus Torvalds [Wed, 20 Jun 2012 05:41:44 +0000 (22:41 -0700)]
Fix cochran CSV pressure data import
The cochran CSV pressure data is actually in units of '4 psi', not in
just psi. That seems to be the resolution cochran internally keeps
things in, and unlike the depth reading there's no conversion to
standard units in the export (for depth, the quarter-foot depth
resolution is converted to tenths of feet when exporting).
Yeah, none of this makes any sense to me either, but I knew it was the
case. I had just forgotten that factor-of-four when I did the importer.
With this fix, I get the same subsurface data (modulo some rounding
differences particularly for temperature) whether I go through David
McNett's UDDF converter, or just import the CSV data directly.
Linus Torvalds [Wed, 20 Jun 2012 03:07:42 +0000 (20:07 -0700)]
cochran: add support for importing the exported CSV files
The Cochran Analyst software can export the basic dive information as
CSV files (comma-separated values).
Individual CSV files contain just one particular type of information:
depth, temperature or cylinder pressure, which is rather inconvenient.
However, the way subsurface works, you can just import these CSV files
all as individual dives, and then subsurface will automatically merge
the dives with the same date and time - and in the process it will also
merge all the samples.
So it turns out that we don't really need any special handling. You can
literally just do
subsurface <list-your-cochran-export-files-here>
and you're all done.
Of course, the CSV files really *are* pretty useless, since they don't
contain all the nice information about where the dive took place etc.
So you literally just get the dive profile. But that's better than
getting nothing at all.
I'd love to actually be able to parse the real native Cochran Analyst
software CAN files, but in the meantime this is at least a starting
point. And if I'm ever able to parse those nasty CAN-files, this makes
comparisons with the exports much easier.
Linus Torvalds [Wed, 20 Jun 2012 03:06:59 +0000 (20:06 -0700)]
Add a few more conversion helper functions to dive.h
Convert feet to mm, psi to mbar, and F to mkelvin. We do this elsewhere
too, but I'm going to need it for the Cochran CSV files, so let's do the
helpers now.
Linus Torvalds [Tue, 19 Jun 2012 19:13:50 +0000 (12:13 -0700)]
Update cochran depth precision: it's in 3-inch increments
The Cochran CSV depth exports are indeed in tenths of feet, but the
decimal is always 0, 3, 5 or 8. Where the 3 and 8 are obviously 0.25
and 0.75 rounded up to one decimal place.
So Cochran does seem to be very much about imperial units, with depth
and cylinder pressure scaled by four (depth in quarter-foot increments,
pressume in 4-psi increments)
Linus Torvalds [Mon, 18 Jun 2012 23:52:41 +0000 (16:52 -0700)]
Add some more cochran data parsing code/comments
The code is pretty useless, the comments perhaps equally so. I'm trying
to figure out what the data pattern is for the cochran CAN files. There
definitely *is* a pattern, but it actually seems to be different for the
files of different people - and it's not obvious in any case.
There probably are multiple versions of the format, and there might be
things like "David has a high-pressure sensor, and Alex does not" going
on too.
Linus Torvalds [Mon, 18 Jun 2012 19:45:09 +0000 (12:45 -0700)]
Add tankpressure parsing for UDDF files
David McNett sent me some example Cochran CAN file data, along with his
UDDF exports of same. I still have absolutely no idea how to decode the
CAN files (although the subsurface decrypting code seems to correctly
decrypt the data, and I see binary patters rather than just noise), but
at least I can make sure we parse the UDDF portion better.
See also
https://github.com/nugget/cochran2uddf
for David's tool to convert the Cochran CSV exports into UDDF.
Data-source: David McNett <nugget@macnugget.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It is really annoying to have to type the device name each time you need
to import a dive from your computer, if you are not using the default
device name. This will save the device name in the configuration file and
matches the logic currently used to save the dive computer name in the
configuration file.
Linus Torvalds [Sat, 12 May 2012 19:53:41 +0000 (12:53 -0700)]
Allow overriding the default xslt path
It's very annoying to have to do "make install" to test a new xslt file,
just because the default xslt path has the standard install path as the
first entry.
At the same time, we do want to default to just using the standard
install location first.
So to allow both testing, and having a nice sane default, just add
support for a SUBSURFACE_XSLT_PATH environment variable that overrides
the default one if it exists.
So then you can just do
SUBSURFACE_XSLT_PATH=xslt ./subsurface
to run subsurface from inside the git tree itself, using the current
files in the git xslt subdirectory.
Linus Torvalds [Sat, 12 May 2012 19:28:40 +0000 (12:28 -0700)]
Suunto SDE conversion: add boat name to notes if it exists
This is, I think, the last piece of relevant information that I can find
in Szymon's SDE file.
Which is not to mean that we get all the conversions right, or that we
handle the more complex cases (still no multi-cylinder import, for
example). But it should be much better than it used to be.
Linus Torvalds [Sat, 12 May 2012 19:21:32 +0000 (12:21 -0700)]
Suunto SDE updates, take 178: add weight and visibility info
This converts the weight information into subsurface weights, and also
adds visibility info (if it exists) into the notes for the dive.
More fall-out from me looking at the nasty suunto xml files, now that I
have a few that actually have some info that isn't just from the
computer download.
Linus Torvalds [Sat, 12 May 2012 19:01:38 +0000 (12:01 -0700)]
Fix more Suunto SDM xml conversion problems
Looking at the XML of the two dives Szymon Kosecki sent out to the
subsurface list, I notice that our cylinder size conversion was wrong.
It looks like CYLINDERUNITS is what determines whether the cylinder size
is in metric (0) or imperial (1) units.
Of course, if you gave a cylinder size in cuft and didn't give a working
pressure, subsurface will just ignore the size as the random crap it is.
We *could* default to a working pressure of 3000 psi, of course.
This also picks up the CYLINDERDESCRIPTION value, although neither of
Szymon's dives actually had any description.
I need more SDE xml files to figure out how multi-cylinder dives look
etc, but I think this gets most *simple* SDE files converted almost
correctly now.
Linus Torvalds [Fri, 11 May 2012 21:13:45 +0000 (14:13 -0700)]
Fix dive notes import from Suundo SDM
The xslt translation didn't add the <notes> tag for the notes, so while
it did select the notes from the SDM file, that never made it into the
subsurface notes.
Also added weather info to the notes, mainly as an example.
There are probably other things we could do, but this fixes at least the
trivial test-case from Szymon Kosecki.
Khalid El Fathi [Mon, 7 May 2012 17:08:39 +0000 (19:08 +0200)]
Fix subsurface manpage - missing description and parsing problem
It's missing a brief description. The "NAME" section is parsed by
lexgrog and used to generate a database that's queried by commands like
apropos and whatis. Replacement a hyphen by a minus sign.
Signed-off-by: Khalid El Fathi <khalid@elfathi.fr> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 3 May 2012 23:04:07 +0000 (16:04 -0700)]
divecomputer importing: show the date of the currently importing dive
I'm hoping most other dive computers are quicker to import from than the
Suunto I have, but mine can take minutes to import all the dives. Sure,
we have that nice progress bar, so it shows that it's doing something,
but it's not really showing *what* it is doing.
So instead of showing just "Parsing dive X", let's show the date of the
dive. That way, when it takes two minutes to import all the dives, at
least you can see "oh, it's going back to the dives of last year" and it
then feels like you have some good reason for the delay.
Linus Torvalds [Thu, 3 May 2012 00:40:39 +0000 (17:40 -0700)]
Show dive import text updates in the progress bar
Instead of using printf() to print the string updates ("Parsing sample
data" etc), introduce a function to show those strings in the graphical
progress bar itself.
Subsurface hasn't been a text-mode application in a long time ;)
This partially fixes the second todo entry from commit b0ba22a06879
("Show dive import error messages in the import dialog") and generally
makes for a more helpful import - at least for the largely error-free
cases.
Sadly, the messages that really come from within libdivecomputer itself
(like "suunto_vyper2.c:193: Failed to receive the answer.") when things
go really wrong are not caught. libdivecomputer does have a notion of a
logfile (set with "message_set_logfile()"), but that ends up being
really inconvenient.
Maybe we could use some pipe setup or something. Oh well.
Linus Torvalds [Wed, 2 May 2012 20:45:52 +0000 (13:45 -0700)]
Change the Dive computer import button from "Ok" to "Retry" on error
This was a todo item in commit b0ba22a06879 ("Show dive import error
messages in the import dialog") which made the import dialog able to
retry the import on errors.
Linus Torvalds [Wed, 2 May 2012 19:56:01 +0000 (12:56 -0700)]
Move the "Import" function from the File menu to the Log menu
Sure, you can import a file too, but it really makes more sense to have
the actions related to importing new logs under "Log", I think. I don't
think of it as a file operation.
Linus Torvalds [Wed, 2 May 2012 19:49:03 +0000 (12:49 -0700)]
Show dive import error messages in the import dialog
.. not in the main window. And leave the import dialog open, so that
you can either try doing it again, or cancel. This makes it much easier
to re-try a failed dive import, and actually makes the failure more
obvious too.
Todo:
- make the "Ok" button change to "Retry" when an error happens
- try to see if we can catch the actual status update messages from
libdivecomputer and show them too in the import dialog. Right now
they are printed out to stderr by the library.
Linus Torvalds [Wed, 2 May 2012 17:26:34 +0000 (10:26 -0700)]
Remember the default dive computer setting
Always having to re-select the same dive computer got really annoying
when I had trouble importing the dives. Let's not force the user to do
that, since we could just remember the last dive computer used, and
default to that one.
Linus Torvalds [Wed, 2 May 2012 17:03:48 +0000 (10:03 -0700)]
Don't close config file when changing preferences
On Linux and MacOS the subsurface_close_conf() doesn't really close the
config file (it flushes writes on MacOS), but on Windows it does
actually close the registry hkey.
Which is bad, if you change the settings multiple times - we assume that
the config file is open the whole time.
So add a "subsurface_flush_conf()" function, and call *that* when
changing configuration parameters. And call the close function only at
the very end.
Alternatively, maybe we should just open the config file separately
every time. I don't much care, maybe somebody else does.
Linus Torvalds [Wed, 2 May 2012 16:36:55 +0000 (09:36 -0700)]
Make subsurface compile with current libdivecomputer git tree
libdivecomputer has the absolute worst interfaces to any library *ever*,
and randomly changes those crappy interfaces when it adds support for
new dive computers.
It would have been much better if the interface was just a "open this
device" with a device descriptor structure pointer, so that when Jef
adds support for new devices, the old descriptors still stay around and
work the same way - there's just a new descriptor structure that you
*can* use if you want. Along with a data structure to name the devices
and their descriptors, this would actually mean that users could just
support pretty much any random device that LD supports.
But no, that's not how libdivecomputer works. It has random enums and
crazy different ad-hoc interfaces for different dive computers. Or,
like in this case, crazy different ad-hoc interfaces for the *same*old*
dive computer.
Right now, for example, the support for the new Heinrichs Weikamp "Frog"
computer added a flag to the interface for the old OSTC_2 support.
Breaking any libdivecomputer users even if you didn't need Frog support.
And is there a version number in the header files to check for? Yes,
there's a version number. But no, it's not useful, since it doesn't
actually change with the interface changes. This time, Jef actually did
change the version number (from 0.1.0 to 0.2.0) as part of new
development version, but there's no reason to believe that it will
change in the future as the interfaces change - it never has before.
So it's actually safer - and easier to understand - to check for the
existence of the new header file inclusion mechanism. A new version of
libdivecomputer that supports the HW Frog computer will include the
"ostc_frog.h" header file when you include the libdivecomputer device.h
file, and that will result in HW_FROG_H being defined.
So we can check whether libdivecomputer has the new interface and
supports the Frog by doing an "#ifdef HW_FROG_H" hack. Ugh.
Linus found this embarrassing bug: double clicking on a weight system in
order to edit it launched the edit function for the first cylinder
instead. Oops.
... but only do it if the numbering of subsequent dives was consecutive
to begin with.
Note that we do accept unnumbered dives (and will stop the sequence
check if we find one), but in order to renumber dives on delete, we
require that starting with the dive we delete, the subsequent numbered
dives have to be a nice incrementing series. If that is the case, then
we fix up that numbering as we delete the dive.
Put another way: if the dive numbering was an incrementing sequence
before the delete, then it will be a sane incrementing sequence after it
too. But if you had missing dives before the delete, we will turn the
delete into just another missing dive.
The basic rule is that we never renumber any dives unless that
renumbering is "obviously correct". It's better to leave old numbers
as-is (and expect that the user is going to do an explicit re-numbering
operation) than it is to change dive numbers in a sequence that we don't
understand.
I do suspect that we should possibly check the dive number "backwards"
too, but this doesn't do that.
This interface works the same way the "edit dive" menu item does: it's a
text entry meny item on the dive text entries (ie buddy/divemaster/notes
sections). Except you pick the "Delete" entry rather than the "Edit"
entry.
It kind of works, but it really is a pretty horrible interface. I'll
need to add a top-level dive menu entry for just deleting all selected
dives instead. And it would be good to be able to get a drop-down menu
from the divelist instead of having to do it from the dive text entries,
which is just insane.
But that requires gtk work. I'm not quite ready to get back into that.
Thus the "exact same insane interface as the explicit 'Edit' mode".
Fix reference tank information for LP steel tanks.
Commit f9bb3f79106b ("Clean up reference tank information table") had
cleaned up the tank info list so that you could sanely do tanks in
liters and with a working pressure in bar.
But the LP steel cylinders had somehow missed out on the ".psi =" part
of the equation, and as a result, what was supposed to be their working
pressure instead ended up being interpreted as their size in
milli-liters.
Oops.
Fix that, and also make the standard tank info filling code actually
verify the sanity of the reference tank table, so that if this happens
again, it will complain loudly instead of using nonsensical values.
Miika Turkia [Fri, 30 Mar 2012 05:10:05 +0000 (08:10 +0300)]
Fix broken average SAC calculation
old_sac_time was always 0 when calculating average air consumption.
Thus the results were incorrect. Move the counter to stats_t structure
as suggested by Linus.
Björn Spruck [Sun, 25 Mar 2012 15:16:21 +0000 (17:16 +0200)]
Added support for Mares Darwin, M1, M2, ... from latest libdivecomputer.
Only M1 has been tested.
Darwin Air will most likely not work as an additional model flag seems to be needed.
This is not foreseen in current GUI.
Linus Torvalds [Sat, 24 Mar 2012 04:07:53 +0000 (21:07 -0700)]
Merge branch 'weight' of git://subsurface.hohndel.org/subsurface
Pull weight management from Dirk Hohndel:
"This is the fifth or sixth version of this code, I'm begining to lose
track. I still struggle with the balance between code duplication and
unnecessary indirectness and complexity. Maybe I'm just not finding
the right level of abstraction. Maybe I'm just trying too hard.
The code here is reasonably well tested. Works for me :-)
It can import DivingLog xml files with weight systems and correctly
parses those. It obviously can read and write weight systems in its
own file format. It adds a KG/lbs unit default (and correctly stores
that).
The thing I still worry about is the code in equipment.c. You'll see
that I tried to abstract things in a way that weight systems and
cylinders share quite a bit of code - but there's more very similar
code that isn't shared as my attempts to do so turned into ugly and
hard to read code. It always felt like trying to write C++ in C..."
* 'weight' of git://subsurface.hohndel.org/subsurface:
Add weight system tracking
Fix up some trivial conflicts due to various renaming of globals and
simplification in function interfaces.
Miika Turkia [Wed, 14 Mar 2012 17:01:34 +0000 (19:01 +0200)]
Show statistics of selected dives
If at least 2 dives are selected, show statistics of these dives on
Overall Stats. Otherwise, show the statistics of all dives. Temperature
is also added to the shown statistics.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Minor change to avoid adding statistics.h (moved the global variable and
external function declaration to display-gtk.h).
Another minor change to the text displayed for the "Stats" notebook page.
Linus Torvalds [Sat, 28 Jan 2012 02:27:30 +0000 (18:27 -0800)]
Cochran: fix up dive data descrambling
This seems to do the dive data descrambling right for both files I have
access to. Except it uses a hardcoded (different) offset for the two.
I have yet to figure out how to automatically detect the offset itself
properly, so you have to compile for the right file.
I'll figure it out, but I'm committing this as a reasonable point in the
process.
Linus Torvalds [Sat, 28 Jan 2012 01:36:42 +0000 (17:36 -0800)]
Fix up Cochran dive header decoding offset
It turns out the odd "different CAN files have different header offsets"
came from the fact that the decode block was different lengths, and I
had not picked the correct place to start - and instead had found two
different places that were at different offsets due to the decode block
length differences.
This fixes that up, and it looks like the dive header is correctly
descrambled (but what the data *means* is unclear, although there is now
an ASCII date and time visible, so at least one part of it is pretty
obvious).
The actual dive data unscrambling is still different for the two
test-files I have to play with, I do not know why.
Linus Torvalds [Fri, 27 Jan 2012 23:11:34 +0000 (15:11 -0800)]
cochran: do a partial header de-scramble
This descrambles at least parts of the header data. Some of it has the
same pattern of data 4kB apart, it may be that there is a dive hiding in
there too (ie what I currently call a "header" may in fact be a header
_plus_ a dive).
But the 4kB thing may well be an artifact of the crazy scrambling code
itself. Who knows what kind of chunking the Cochran Analyst
"encryption" uses.
As with the dive data, there seems to be some offset differences between
different CAN files.
Linus Torvalds [Fri, 27 Jan 2012 22:10:55 +0000 (14:10 -0800)]
cochran: do the full de-scramble for one case
So this descrambles all the dives in *one* of my cochran test files. I
still don't know what the dive data *means*, but it's not a random
jumble of bytes any more: there are very clear patterns.
However, the magic offsets that work for that particular CAN file are
not generic, because they don't work for another. So there is some
magic dynamic decoding that I don't know about. There is probably more
decode information in the initial decode block, over and beyond just the
scrambling bytes.
(The scrambling array is 234 bytes starting at 0x40001, but the first
actual *dive* data starts at 0x45e03, so there's tons of unknown stuff
in the file even outside the dives themselves)
Linus Torvalds [Fri, 27 Jan 2012 22:02:50 +0000 (14:02 -0800)]
Make cochran debug output a bit easier to use directly
Just do the hex-dump in the program, and print all the results to
standard output. Avoid the need to do 'od' by hand etc to see what
happens when you play with the decoder.
Linus Torvalds [Fri, 27 Jan 2012 20:43:40 +0000 (12:43 -0800)]
Add some initial cochran CAN file parsing
It's broken, and currently only writes out a debug output file per dive.
I'm not sure I'll ever really be able to decode the mess that is the
Cochran ANalyst stuff, but I have a few test files, along with separate
depth info from a couple of the dives in question, so in case this ever
works I can at least validate it to some degree.
The file format is definitely very intentionally obscured, though.
Annoying. It's not like the Cochran software is actually all that good
(it's really quite a horribly nasty Windows-only app, I'm told).
Cochran Analyst is very much not the reason why people would buy those
computers. So Cochran making their computers harder to use with other
software is just stupid.
Linus Torvalds [Fri, 27 Jan 2012 18:56:36 +0000 (10:56 -0800)]
Import: always open and read the file before checking the filename extension
Most of the parsers will want the content in memory, so keep them
simple. The fact that the Suunto parser uses "libzip" that has to
re-open the file is annoying and causes us to re-open the file etc.
But it's the odd man out, so don't design the "open_by_filename()"
function around it. Pretty much everybody else will want to avoid
having to cook up their own IO routines.
Also, when reading the file, NUL-terminate the buffer. This allows us
to just treat text files as large strings if we want to, and doesn't
matter for binary files (we still pass in the length explicitly).
Linus Torvalds [Fri, 27 Jan 2012 16:11:24 +0000 (08:11 -0800)]
Fix typo ('suundo' instead of 'suunto')
I apparently was so congested that it affected my typing too when I
wrote that, and then copy-paste meant that the use and declaration
matched despite the misspelling.
Reported-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Fri, 27 Jan 2012 01:43:33 +0000 (17:43 -0800)]
Add "native" Suunto SDE zip file reading
You need to have libzip-devel installed, and pkg-config needs to know about it
for the build to pick up on it.
On at least Fedora, a simple "yum install libzip-devel" will make things
work, although you may need to force a rebuild of subsurface too (the
"file.o" file in particular - the Makefile doesn't track system
dependencies).
Linus Torvalds [Wed, 18 Jan 2012 04:02:33 +0000 (20:02 -0800)]
Merge branch 'info-split' of git://git.hohndel.org/subsurface
* 'info-split' of git://git.hohndel.org/subsurface:
Add statistics for longest, shortest, and shallowest dive
Create separate single dive and total stats pages
Separate out single dive statistics and total statistics
Dirk Hohndel [Sun, 15 Jan 2012 23:21:56 +0000 (15:21 -0800)]
Add statistics for longest, shortest, and shallowest dive
I don't really like calling the shallowest dive "min depth", but all other
texts that I could come up with that were reasonably short weren't any
better...
Dirk Hohndel [Sun, 15 Jan 2012 21:19:39 +0000 (13:19 -0800)]
Separate out single dive statistics and total statistics
Right now this just changes the infrastructure - nothing outside of
statistics.c is modified. This is simply in preparation to split out the
single dive info and the total dive statistics in the future (as we are
creating more info and more stats and they will overflow the screen area
available - so this will turn into two notebook tabs).
Use a more standard approach to save preferences on MacOSX
CFPreferences* seems to be the proper way to handle preferences on MacOSX.
This approach also eliminates a problem where the hard coded preferences
path couldn't be read.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
[ fixed small coding style issues ] Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linus Torvalds [Sun, 1 Jan 2012 23:12:28 +0000 (15:12 -0800)]
First try at converting user-manual to AsciiDoc
You can do "make doc" in the main directory to create the html version,
and if you want to play around with it, do "make show" in the
Documentation subdirectory to start firefox on the end result.
It's by no means perfect, but it gives somewhat reasonable results, and
this is enough initial work for people to play around with, I think.
NOTE! You need "asciidoc" installed to do this: it's a python program,
so it should be pretty easy even on non-Linux platforms. And on Linux,
most distributions package it, so you just have to do something like
yum install asciidoc
to get it (replace with apt-get/zypper/whatever).
Asciidoc can generate other output too (man-pages, LaTeX, etc), maybe
people want to play with that part too.
Linus Torvalds [Fri, 30 Dec 2011 21:09:17 +0000 (13:09 -0800)]
Move the gasmix cleanups from XML parsing to the generic dive fixup stage
Right now we do certain cylinder info operations only when importing
from an XML file, which is wrong. In particular, we do the "is the
gasmix air" or "what is the standard cylinder name" only at XML read
time, which means that if you import a dive directly from the dive
computer, it won't have the air sanitization or the proper default
cylinder names.
Of course, most dive computers don't actually save enough cylinder
information for us to do the cylinder name lookup anyway, but some do.
And all Nitrox-capable dive computers do have that O2 percentage that
needs cleanup too.
Reported-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix incorrect utf-8 in Documentation/user-manual.txt
Not sure, but us-ascii might have been intended.
Signed-off-by: Cristian Ionescu-Idbohrn <cii@axis.com>
[ And even if you do want to use utf8, you should use it correctly, not
with this "pick random character" approach - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jacco van Koll [Fri, 23 Dec 2011 18:43:58 +0000 (19:43 +0100)]
Version 0.0.6 of user manual
Corrected some typo's
Modified chapter 12. Importing dives from JDivelogAdded chapter 13.
Importing dives from Suunto Divemanager 3.*
Added Appendix B: very tiny example script for importing Suunto
Divemanager 3.* xml files
Signed-off-by: Jacco van Koll <jacco.van.koll@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linus Torvalds [Mon, 19 Dec 2011 02:30:31 +0000 (18:30 -0800)]
parse-xml: read the file into memory separately
Using xmlParseFile() was simple, but I'm planning on extending the file
parsing past just XML, since we want to be able to import other formats
too. And quite frankly, that means that we'll want to read the file
into memory to look at it before we start parsing it.
We could decide do it by file extensions too, and I'll look at that
approach as well, but regardless of how we do things it's almost
certainly a good idea to do the file access in one place. The XML
parsing might as well happen from a memory buffer instead anyway.
Miika Turkia [Sun, 18 Dec 2011 12:36:28 +0000 (14:36 +0200)]
Multiple cylinder support for JDiveLog import
Support for multiple cylinders and gas change events when Importing
JDiveLog logs to Subsurface. This is tested with manually crafted data
and not real data (originating from dive computer).
NOTE: Subsurface does not handle importing multiple cylinders
correctly but imports only the first cylinder. However, manually
converting data to a file and opening that in Subsurface works
correctly.
(xsltproc jdivelog2subsurface.xslt jdivelog-gas.jlb > gas.xml)
Some minor tweaking on importing JDiveLog specific fields to notes
fields in Subsurface is also included.
Linus Torvalds [Thu, 15 Dec 2011 02:19:48 +0000 (18:19 -0800)]
Merge branch 'forlinus' of git://git.hohndel.org/subsurface
* 'forlinus' of git://git.hohndel.org/subsurface:
Improve Makefile for MacOS
Add reasonable default device names for divecomputer import
More intuitive label for "not saving" when exiting
Dirk Hohndel [Wed, 14 Dec 2011 19:22:12 +0000 (11:22 -0800)]
Improve Makefile for MacOS
Some macs appear to need "-framework CoreFoundation" added to the linking
step, others (which appear to have the exact same OS and tools installed),
don't. But as it doesn't appeart to hurt, I unconditionally add this.
Switched to using pkgconfig to find libdivecomputer on the Mac.
Tried to clean up the Makefile a bit
Signed-off-by: Dirk Hohndel <dirk@hohndel.org> Acked-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
projects / ext / subsurface.git / log