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>
