This became very obvious after commit df6a9ddd8a21 ("Auto-generate C file
dependencies, and make the build more quiet") went in; since not having
osm-gps-map is one of the few errors that aren't fatal for building it
seemed worth quieting this down.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does some rough auto-generation of header file dependencies for all
the *.c files, rather than our file-by-file incomplete hardcoded ones.
It also stops showing the whole compile line, because it's ugly and
distracting. Instead it just shows "CC file.c". If you care about the
full thing, you still see them with "make -n".
Only tested on Linux. It probably is missing some Windows or
OSX-specific header includes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This forces us to use the proper gtk accessor functions. It may not be
worth it if people actually do the Qt conversion, but if we want to try
gtk3 at some point, this might help.
This all came about because I was trying to explain on G+ what an
immense pain this all was to even figure out, if you don't actually know
gtk at all. Google and the gtk migration guide are almost useless, and
the gtk2 documentation itself actually uses the fields directly without
any accessor functions in several places.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a Makefile target to create the .nsi file from a template and to
hopefully create the right strings to magically get the correct version
strings in the Windows installer
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes sure that it's easy to tell from the about box whether this is
a released version or a development build.
If it is compiled at the exact location of the tag, "git describe
--tags" will just return the tag-name. Otherwise it will return
something like this
v2.1-393-ge03f31525aab
which means "v2.1 plus 393 commits, git SHA1 of tip is e03f31525aab",
which is a nice combination of git-readable (only the actual SHA1
matters) and human-readable (393 commits on top of v2.1).
And if you don't build from git sources, and don't have git installed,
it falls back on the old "v$(VERSION)" string.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This replaces the really lame "italics text" from commit abe810ca1a29
("Mark locations that have GPS location data attached") with a marginally
less lame GPS icon.There's a reason why I am not making a living as
graphics artist. But I think this is a huge step forward from what we had
before...
The satellite.svg file is very loosely based on a different icon that I
found as public domain here http://www.clker.com/clipart-30400.html.
From that I created the PNG and then that was converted into the
GdkPixdata via gdk-pixbuf-csource; a rule for that was added to
the Makefile but commented out as I don't know if this tool will always be
available in the path. Having this icon included in the sources avoids
locating yet another icon file.
Better icons are certainly welcome!
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While we are waiting for an autotools generated Makefile, this should allow
people to build that don't have osm-gps-map.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For each dive recorded, place their GPS coordinates onto a map using the
OSM-GPS-MAP library.
This map is accessible via the "log" menu or the shortcut ctrl+M (M as map).
We check for the GPS coordinates "0, 0" which are the default when we do not
have real GPS coordinates set.
[Dirk Hohndel: fixed int/float math confusion, fixed some whitespace and
coding style issues, cleaned up some comments, added a
missing cast to prevent a compiler warning]
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does the "don't save defaults" for numeric values too.
Also, move the preferences loading/saving to a new "prefs.c" file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A new file download-dialog.c now contains all code related
to the download dialog, which was previously defined in gtk-gui.c.
Also, a new file callbacks-gtk.h now has two macros
OPTIONCALLBACK, UNITCALLBACK shared only between
download-dialog.c and gtk-gui.c.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The legacy nickname wrappers (that use the device_info structure) are
left in gtk-gui.c. We can slowly start moving away from them, we don't
want to start exporting that thing as some kind of generic interface.
This isn't a pure code movement - because we leave the legacy interfaces
alone, there are a few new interfaces in device.c (like "create a new
device_info entry") that were embedded into the legacy "create nickname"
code, and needed to be abstracted out.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There should be NO other changes in this commit - just moving the code and
adjusting the includes (and adding the entry point to display-gtk.h).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This comes with absolutely no gui - so the plan literally needs to be
compiled into Subsurface. Not exactly a feature, but this allowed me to
focus on the planning part instead of spending time on tedious UI work.
A new menu "Planner" with entry "Test Planner" calls into the hard-coded
function in planner.c. There a simple dive plan can be constructed with
calls to plan_add_segment(&diveplan, duration, depth at the end, fO2, pO2)
Calling plan(&diveplan) does the deco calculations and creates deco stops
that keep us below the ceiling (with the GFlow/high values currently
configured). The stop levels used are defined at the top of planner.c in
the stoplevels array - there is no need to do the traditional multiples of
3m or anything like that.
The dive including the ascents and deco stops all the way to the surface
is completed and then added as simulated dive to the end of the divelist
(I guess we could automatically select it later) and can be viewed.
This is crude but shows the direction we can go with this. Envision a nice
UI that allows you to simply enter the segments and pick the desired
stops.
What is missing is the ability to give the algorithm additional gases that
it can use during the deco phase - right now it simply keeps using the
last gas used in the diveplan.
All that said, there are clear bugs here - and sadly they seem to be in
the deco calculations, as with the example given the ceiling that is
calculated makes no sense. When displayed in smooth mode it has very
strange jumps up and down that I wouldn't expect. For example with GF
35/75 (the default) the deco ceiling when looking at the simulated dive
jumps from 16m back up to 13m around 14:10 into the dive. That seems very
odd.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This small change to the Makefile allows you to call
make CLCFLAGS=-DDEBUG
or some other define directly from the command line. It gets added to the
CFLAGS without overwriting the CFLAGS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simplifies the vendor/product fields into just a single "model"
string for the dive computer, since we can't really validly ever use it
any other way anyway.
Also, add 'deviceid' and 'diveid' fields: they are just 32-bit hex
values that are unique for that particular dive computer model. For
libdivecomputer, they are basically the first word of the SHA1 of the
data that libdivecomputer gives us.
(Trying to expose it in some other way is insane - different dive
computers use different models for the ID, so don't try to do some kind
of serial number or something like that)
For the Uemis Zurich, which doesn't use the libdivecomputer import, we
currently only set the model name. The computer does have some kind of
device ID string, and we could/should just do the same "SHA1 over the
ID" to give it a unique ID, but the pseudo-xml parsing confuses me, so
I'll let Dirk fix that up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Simply call "make LIBDCDEVEL=1" and the libdivecomputer includefiles are
expected in ../libdivecomputer/include and the actual library is linked
from ../libdivecomputer/src/.libs
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>
The Makefile change simply gets us the same setup with make install-macosx
that we are getting from the gtk-mac-bundler - with the launcher script
and subsurface installed as subsurface-bin.
The changes in the README are what make the difference for getting a
working dmg - there are a bunch of .so files that are part of gtk that
didn't have their dependency load paths updated - and those made the
application either crash or at least not display its own icon correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out that we need aliases for all the languages. And more fiddling
when creating the dmg. And a specialized MacPorts build with the install
path as prefix. What this basically means is that our app will be
correctly localized iff run as /Applications/Subsurface.app
Otherwise the gtk default texts (on buttons for example) may or may not be
translated.
One remaining issue is that apparently Gtk's Mac integration triggers on
the untranslated name Help the Menu tree in order to work. Yet we can't
easily tell the app not to translate that word as the translations are
done internally in gtk - we'd basicall have to build special subsurface.mo
files for Mac that don't contain a translation of the word "Help" for this
to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The update-po-files target creates backup files. Let's add them
to the "clean" target.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit of a hack to make my life easier.
make update-po-files
will extract the translation strings and merge them with the existing
translations - for all existing translations.
For good measure this commit includes the latest update of the po files
(but no new translations should be needed).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linux didn't have a locale install target, and Windows didn't install
aliased locale files.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[the macos/macosx typo was also found and a patch submitted by
Henrik Brautaset Aronsen <subsurface@henrik.synth.no>]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the right tools in place you can now create a bundle from the
Makefile by calling "make create-macos-bundle"
In the process of this I also moved the locale directory where we stage
our .mo files to share/locale (which is much more logical).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
gtk-mac-bundler uses Contents/Resources/share/locale, and
the install-macosx target should do the same.
Also quiet down the make process a bit
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some languages have identifiers that gettext can't determine
automatically in all OS'es. An example is Norwegian (no_NO, deprecated)
with its Bokmål (nb_NO) and Nynorsk (nn_NO) form.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit adds an install-cross-windows target to the Makefile that
creates a staging directory for us under packaging/windows that contains
the required .mo files. This currently fails for the Norwegian translation
because of the no_NO.UTF-8 vs nb issue - right now we just use the first
component of our own localization filename to find the matching Windows
localization and that fails.
The subsurface.nsi file is updated accordingly and this now appears to
create working installers with sane paths for the localization files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The MacOSX applications bundle needs to be told where to bind the
text domain from.
Also copy the gettext .mo files in the install-macosx target.
[Dirk Hohndel: minor change in main(): move the path declaration to
the beginning of the function]
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
My previous take at adding gettext to the Makefile wasn't very good,
since it always relinked the subsurface executable.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Added basic support for building gettext locales in the Makefile.
The po file name should match the target locale.
[Dirk Hohndel: Used git mv to rename the German .po file]
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Without "-headerpad_max_install_names", gtk-mac-bundler would complain
with "changing install names or rpaths can't be redone for:
/Applications/.subsurface.app/Contents/MacOS/subsurface-bin (for
architecture x86_64) because larger updated load commands do not fit"
Also, libdivecomputer needs to be configured with --with-prefix=/opt/local
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This includes one major hack that uses a private data structure from
libdivecomputer to allow us to show the Uemis Zurich as one computer the
user can import from.
Once the user has chosen the Uemis we don't use libdivecomputer but our
own downloader. Just like in the libdicecomputer case this runs in its own
thread and updates the import dialog with progress information.
The code also keeps track of the last dive that has been downloaded from a
Uemis computer so we only import new dives on subsequent downloads. And
since the Uemis Zurich gives us its device id, we make this a "per
divecomputer" property for people who dive with multiple Uemis Zurich
computers.
This uses the debugfile infrastructure to allow easily collecting
debugging output - especially on Windows where by default console output
is lost.
Known limitations: when the Uemis runs out of space (it uses its
filesystem for communication with the host computer) we have no graceful
way to reset things. This is why the code doesn't try to download ALL
dives on the computer but instead download them in increments of ten
dives. This clearly needs to be addressed once I understand how to reset
the device.
The Cancel button of the import dialog isn't correctly hooked up, yet.
I still need to figure out how to gracefully shut down a download without
potentially hanging the device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the time type unambiguous, and we can use G_TYPE_INT64 for it
in the divelist too.
It also implements a portable (and thread-safe) "utc_mkdate()" function
that acts kind of like gmtime_r(), but using the 64-bit timestamp_t. It
matches our original "utc_mktime()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Reported-by: Grischa Toedt <toedt@embl.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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).
Then, you can just do
subsurface my-dives.SDE
to read the data directly from the SDE file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We're going to eventually import non-xml files too, so let's begin
splitting the logic up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
