This will hopefully not be something we need often, but if we improve
support for a divecomputer (either in libdivecomputer or in our native
Uemis code or even in the way we handle (and potentially discard) events),
then it is extremely useful to be able to say "re-download things
from the divecomputer and for things that were not edited in Subsurface,
don't try to merge the data (which gives BAD results if for example you
fixed a bug in the depth calculation in libdivecomputer) but instead
simply take the samples, the events and some of the other unedited data
straight from the download".
This commit implements just that - a "force download" checkbox in the
download dialog that makes us reimport all dives from the dive computer,
even the ones we already have, and an "always prefer downloaded dive"
checkbox that then tells Subsurface not to merge but simply to take the
data from the downloaded dive - without overwriting the things we have
already edited in Subsurface (like location, buddy, equipment, etc).
This, as a precaution, refuses to merge dives that don't have identical
start times. So if you have edited the date / time of a dive or if you
have previously merged your dive with a different dive computer (and
therefore modified samples and events) you are out of luck.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This requires a patched libdivecomputer that can return salinity of the
water the dive was conducted in. Experimental patches exist that implement
this for the OSTC. The code is designed so that it simply defaults to salt
water if libdivecomputer doesn't include the feature.
The patch also fixes the dive merge code to merge two other recent
additions to the dive structure (surface_pressure and visibility).
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>
There's no guarantee that gtk is thread-safe (apparently it can be
broken at least on Windows, even though it should be fine on top of X).
So don't update the progress bar directly from the dive computer import
code, instead just update the progress information in static variables,
and let the GUI thread update it while it does the idle loop polling
anyway.
Reported-by: Jef Driesen <jefdriesen@telenet.be>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For this you need to get the current libdivecomputer tree, reconfigure,
build and install it first. But this cleans up some of the silly error
handling too, and has just a single "dc_device_close()" call etc, rather
than duplicating that (and the new dc_context_free()).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 b0ba22a068
("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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. 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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1) since %lld is not defined in the MSVC runtime, use
the portable PRId64 macro from inttypes.h for 64bit integers
notice in inttypes.h from mingw-win32:
/* 7.8.1 Macros for format specifiers
*
* MS runtime does not yet understand C9x standard "ll"
* length specifier. It appears to treat "ll" as "l".
* The non-standard I64 length specifier causes warning in GCC,
* but understood by MS runtime functions.
*/
2) include unistd.h to disable warning:
warning: implicit declaration of function 'usleep'
Lubomir's code then caused a warning building natively under Linux, which
I fixed as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Remove casts from/to void*. They are unneeded in C, can hide problems
in the future, and are far too C++ish. Furthermore, they were
inconsistent with the rest of the code and even with regards to
themselves (at least in terms of whether or not to have space after the
cast).
In this case, we temporarily lose const specifiers in libdivecomputer.c
due to the unneeded cast, so it seems better to avoid the cast at all,
so you get warned about a const->non-const cast if you ever change it to
do something like this.
The casts in gtk-gui.c are just useless semantically, although they
might be useful as a hint to the reader that the void pointers are char
arrays.
Signed-off-by: Julian Andres Klode <jak@jak-linux.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When importing (or reading xml from files) new dives, we now renumber
them based on preexisting dive data, *if* such re-numbering is obvious.
NOTE! In order to be "obvious", there can be no overlap between old and
new dives: all the new dives have to come at the end. That's what
happens with a normal libdivecomputer import, since we cut the import
short when we find a preexisting dive.
But if any of the new dives overlap the old dives in any way, or already
have been numbered separately, the automatic renumbering is not done,
and you need to do a manual renumber.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
The libdivecomputer interfaces are pure crap. There are no generic
"open the dive computer" or "create a parser for the dive computer"
interfaces, instead each dive computer you support has its own open and
parser generator interface.
And they change. Happily fairly seldom, but they change. And two days
ago, Jef changed the interface for the Mares Icon HD computer in order
to support the newer HD Net Ready variant.
I've asked Jef to make a sane interface for "open the dive computer" and
"just create the parser" for libdivecomputer, but he claims that he
cannot just track the device model details internally. Which is
obviously a completely bogus claim, since the way *we* track the model
details is to just feed it back from the silly event.
libdivecomputer should just do that internally and not bother us with
its crazy internal model numbers. But whatever.
In the meantime, work around this braindamage, and hope that
libdivecomputer comes to its senses some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I don't know about other dive computers, but the Suunto Vyper Air is
slow as hell to import all the dives from. And libdivecomputer seems to
be importing dives "most recent first", so this just makes it stop
importing dives when it finds a dive that we've already seen.
Caveat: libdivecomputer has this fancy notion of "dive fingerprints",
and claims that's the way to do things. That seems to be overly
complicated, and not worth the bother.
If you worry about the import finishing early due to already having some
dives with the same date in your dive list, just import starting from an
empty state, and thus get a pure "dive computer only" state with no
early out. Then you can just load the old dives afterwards, and depend
on subsurface merging any duplicates.
But for normal operation, when you just want to import a couple of new
dives from your dive computer, the "exit import early when you see a
duplicate" is the right thing to do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Parse them, save them, take them from libdivecomputer.
This doesn't merge them or show them in the profile yet, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ignore surface events - they are meaningless anyway and just add noise.
Print out other events properly, including correct time offset etc.
We still don't actually *save* the events, but now it might be worth
doign so.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As reported by Mauro Dreissig, the progress bar doesn't work and causes
a SIGSEGV due to a missing allocation. The code broke when Dirk
separated out the GUI from the core code, and I hadn't tried
divecomputer downloads since.
Reported-by: Mauro Dreissig <mukadr@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
Passing it around is just annoying, and we only ever have one. Let's
not burden all the users with the silly thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the hackiest thing ever, unless you count the previous code that
was even hackier (and just called the gtk main routine at random
places).
The libdivecomputer library is not really set up to be part of the gtk
main loop, and cannot afford (for example) to have lots of mainloop
events while it's parsing. Some dive computers are very timing
sensitive for the communication.
So just start a thread for doing the libdivecomputer stuff, and just
continually call the gtk main loop while that thread is running. I'm
sure we could actually use some gtk signalling thing to make the thread
exit do the right thing, but instead we just poll the status every
100ms.
I did say it was hacky. It does seem to work, though. No more
temporary graying out of the windows when they don't react in a timely
manner because libdivecomputer does some blocking operation.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I never really liked 'diveclog' as a name - it's not like the C part is
all that important. And while I could try to just make up another slang
word for despicable person (in the tradition of naming all my projects
after myself), I just can't see it.
So let's just call it "subsurface".
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>
Linus clearly wanted to make SURE that we use /dev/ttyUSB0
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's quite often obvious crap for the "doesn't exist" or "plain air" case.
So if it's reporting 100% O2, we just ignore it. Sure, it could be
right, but for the dives I have I know it's just libdivecomputer being
wrong.
Same goes for obvious crap like 255% Helium.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
So this actually reports the dive data that libdivecomputer generates.
It doesn't import special events etc, but neither do we for the xml
importer.
It is also slow as heck, since it doesn't try to do the "hey, I already
have this dive" logic and always imports everything, but the basics are
definitely there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of writing out the progress events, use them to update a real
progress bar.
Also, we need to handle gtk events while busy with the dive computer
reading. That should *probably* be done with a threading model, because
libdivecomputer does seem to have some timing sensitivity - I'm getting
"failure to read memory block" if I make that loop do the standard
while (gtk_events_pending())
gtk_main_iteration();
thing. Besides, even if we did do that loop, it would still cause
problems when the libdivecomputer code is stuck reading a serial line
that doesn't respond or whatever.
But for now this ugly hack is "good enough" to get further.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This actually gets me far enough that it prints out all the dives on my
dive computer. It doesn't actually turn them into real dives yet,
though - only a series of ugly 'printf's so far.
And it hangs after printing the last dive. So I'm doing something wrong.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. fill in the event parsing. This doesn't generate the fingerprint
like the example does, I just don't care about that yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. this now registers the dive parsing callback, and starts to parse the
data. So I can see the last divetime on my Suunto Vyper Air now.
Still a lot more boilerplate stuff to go, though. The libdivecomputer
interfaces really are pretty insane: why should the caller set up the
dive parsing for each computer type, when libdivecomputer knows what
types it has? IOW, much of that boilerplate should be hidden inside of
libdivecomputer, rather than exposed to the user.
But whatever. I'm taking pieces from "examples/universal.c" as I go
along (it's under LGPL 2.1). I want to do it in small chunks just to
feel that I understand what's going on, rather than just blindly copying
it all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. start some error reporting, and register some early (empty)
callbacks.
This still doesn't actually do anything. But commit early, commit
often: when I start seriously breaking things, I want to have a "hey,
this still at least compiled" state.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ok, so this is quite broken right now: it doesn't actually really *do*
anything, and it now requires that you have libdivecomputer all set up
and installed.
That is fairly easy:
mkdir ../src
cd ../src
git clone git://libdivecomputer.git.sourceforge.net/gitroot/libdivecomputer/libdivecomputer
cd libdivecomputer
autoreconf --install
./configure
make
sudo make install
but you may feel that this is not exactly useful considering that
nothing actually *works* yet.
Some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
