This is actually stored in minutes (which seems odd, given they allocate
16 bits for it... how much deco do these people want to be prepared for??)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The dive data contains the surface pressure prior to the dive, and that is
what we need to compare p_amb_tol to, not the standard 1013mbar.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The hold_depth field is rather misleading as it normally gives the safety
stop depth and only when the p_amb_tol goes "below the surface" does it
switch to showing the first deco stop depth.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far we don't parse air temperature data via libdivecomputer. Nor are we
set up to allow the user to manually enter it. We can parse it when
downloading from a Uemis Zurich, though.
This feature was suggested via trac.hohndel.org; this commit implements
only part of what is requested there, so I simply reference the ticket
here without closing it.
References ticket #7
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With this commit we not only use the getDivelogs command but also the
getDive command for each of the dives that was downloaded. Oddly, that
makes quite a bit of redundant (and at times slightly contradictory) data
available, but also many new things.
We now get weight, suit and notes that were stored with a dive in the
logbook on the divecomputer. There are a ton more data available that we
don't use, yet. For example information about altitude, a decoindex, dive
type and dive activity, other equipment information, etc.
I still need to decide how much of this I want to make available in
Subsurface (and how I want to present this - after all most of this is not
available from other dive computers).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Here is what Linus reported:
I think you have made a mistake in trying to translate some of
libdivecomputer.c
Translating some of those things based on locale is *wrong*, because
they are saved in the XML file.
That covers at least the warnings: they'll get translated when you
import them, and then saved to the XML file as that translation, but
now if you start subsurface in another locale, they will not get
translated back.
So translating XML file contents is fundamentally buggy. It just
shouldn't be done.
So all the "translations" for the event handling are buggy, and
generate crap. Please don't do that. Leave them as English.
And of course he is absolutely right. However, instead of not translating
them at all, this commit fixes things a better way - we now mark the
strings for translation but store the original English strings everywhere
(in the in-memory data structure as well as in the XML file). Only when we
actually display something on the screen (in a tooltip or in the filter
dialog) do we actually translate the strings into the native language.
This should address both Linus' issue and the desire to have localized
event texts.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the first step - convert the string literals, try to catch
all the places where this isn't possible and the program needs to convert
string constants at runtime (those are the N_ macros).
Add a very rough first German localization so I can at least test what I
have done. Seriously, I have never used a localized OS, so I am certain
that I have many of the 'standard' translations wrong. Someone please take
over :-)
Major issues with this:
- right now it hardcodes the search path for the message catalog to be
./locale - that's of course bogus, but it works well while doing initial
testing. Once the tooling support is there we just should use the OS
default.
- even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets
can't seem to agree) I went with UTF-8 as that is what Gtk appears to
want to use internally. ISO-8859-15 encoded .mo files create funny
looking artefacts instead of Umlaute.
- no support at all in the Makefile - I was hoping someone with more
experience in how to best set this up would contribute a good set of
Makefile rules - likely this will help fix the first issue in that it
will also install the .mo file(s) in the correct place(s)
For now simply run
msgfmt -c -o subsurface.mo deutsch.po
to create the subsurface.mo file and then move it to
./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo
If you make changes to the sources and need to add new strings to be
translated, this is what seems to work (again, should be tooled through
the Makefile):
xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c
msgmerge -s -U po/deutsch.po subsurface-new.pot
If you do this PLEASE do one commit that just has the new msgid as
changes in line numbers create a TON of diff-noise. Do changes to
translations in a SEPARATE commit.
- no testing at all on Windows or Mac
It builds on Windows :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I guess no one has ever tried to import Uemis dive data under Windows.
The glib-2 libraries for Windows (at least the ones that are part of the
mingw package, but my guess is this is true for all of them), force the
whole program to be compiled with Windows packing rules for structures.
That broke the structure we use for decoding Uemis binary data.
This commit changes the data structure to no longer use unaligned 16bit
values but instead two 8bit values and assemble them in the actual code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I removed the regex code from the uemis parser a long time ago, but forgot
to remove the #include <regex.h>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I clearly had never tried this with a dive that used the "just air"
setting the uemis. With this fix the cylinder data for that one tank is
read correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is something I wanted to do for a while. Every uemis sample is simply
a packed structure with no padding. Instead of grabbing random bytes from
the middle of an unstructured data blob let's just define the structure
and access its members.
And while we do that, add support for the more useful uemis events as
well.
A couple of the warnings are disabled by default (compile time flag) as
they are just crazy - any normal dive will give you dozens and dozens of
speed warnings. Same goes for the PO2 green warning (I haven't looked but
this seems to trigger on a PO2 over 1.0 or something). Completely useless
and just hides actually useful info.
I still want to redo the way we visualize events in general - just
printing the text ontop of the profile really is suboptimal. Especially as
the uemis really seems to love to repeat several of the warnings quite
frequently.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Turns out they use 202.6bar as default working pressure. WTF?
Also I had misunderstood the way I should record the pressure internally
(which happened to work since I didn't set the working pressure). This is
now fixed as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We can instead 'Open' these files as they are just bastardized XML files.
This gets us back to a more consistent point where 'Import' gets data
directly from the dive computer (and hopefully soon we will add the
ability to load a dive directly from a uemis SDA to libdivecomputer),
and 'Open' loads a file from the filesystem of the computer we are
running on (this last sentence phrased so awkwardly as the uemis Zurich
SDA is a computer and presents a file system when connected via USB - it
just doesn't have the dive data in an accessible format in that file
system).
As a bonus we get to throw away quite a bit of code (the uemis specific
file handling, mini-XML parser with helper functions, the file open dialog
in the importer). Yay!
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There are a few interesting issues with this:
- this requires a change to the SDA file format; thankfully I control that
format, too (the default files are not valid XML files)
- once again, the fact that adding samples can change the dive pointer
messes with me - I decided to change the interface of ALL of the
XXX_dive_match functions to take a struct dive**
I know this is not ideal as all the other functions don't need that -
but I would have hated the inconsistency
- there is the issue that we now overload two _different_ uemis formats in
the same function - that's certainly a potential point of confusion
- a minor detail is the problem that the SDA format is kinda odd to parse
and that we trigger on the duration field by it being the only float.
Yeah, that's not ideal - but again, I control the format, so I _know_
this is true.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Thanks Valgrind
This diff looks pointless at first until you see that I reference dive
again earlier in the loop and then after the end of the loop.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Admittedly the cuft ratings are stupid, but still, it's not that hard.
In order to correctly describe a tank based on the cuft system you need to
know the cuft AND the working pressure. But the uemis Zurich always
assumes that the working pressure is 200bar. That's pretty close to
3000psi and therefore works "good enough" for Aluminum tanks - but in
general this will of course fail (e.g. for HP or LP tanks).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The following are UI toolkit specific:
gtk-gui.c - overall layout, main window of the UI
divelist.c - list of dives subsurface maintains
equipment.c - equipment / tank information for each dive
info.c - detailed dive info
print.c - printing
The rest is independent of the UI:
main.c i - program frame
dive.c i - creates and maintaines the internal dive list structure
libdivecomputer.c
uemis.c
parse-xml.c
save-xml.c - interface with dive computers and the XML files
profile.c - creates the data for the profile and draws it using cairo
This commit should contain NO functional changes, just moving code around
and a couple of minor abstractions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
stole and fixed Linus' code in the uemis XML importer
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is missing a ton of the information in the .SDA files It only
parses the divelog.SDA file, not the dive.SDA file It ignores the
information on the gas(es) used and all the data on the tanks.
It still draws some strange artefacts at the end of the dive
But it correctly hooks into the import dialogue, it gives you a file
select box (somewhere, I'm sure, a gtk developer cries quietly) and then
parses enough of this file to serve as a proof of concept.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
