mirror of
https://github.com/subsurface/subsurface.git
synced 2024-11-28 21:20:19 +00:00
11db04b350
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. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
181 lines
5.2 KiB
Text
181 lines
5.2 KiB
Text
Half-arsed divelog software in C.
|
|
|
|
I'm tired of Java programs that don't work etc.
|
|
|
|
License: GPLv2
|
|
|
|
You need libxml2-devel, gtk2-devel, glib-2.0 and GConf2-devel to build
|
|
this (and libusb-1.0 if you have libdivecomputer built with it, but then
|
|
you obviously already have it installed)
|
|
|
|
You also need to have libdivecomputer installed, which goes something like this:
|
|
|
|
git clone git://libdivecomputer.git.sourceforge.net/gitroot/libdivecomputer/libdivecomputer
|
|
cd libdivecomputer
|
|
autoreconf --install
|
|
./configure
|
|
make
|
|
sudo make install
|
|
|
|
NOTE! You may need to tell the main Makefile where you installed
|
|
libdivecomputer if you didn't do it in the default /usr/local location.
|
|
I don't trust pkg-config for libdivecomputer, since pkg-config usually
|
|
doesn't work unless the project has been installed by the distro.
|
|
|
|
Just edit the makefile directly. autoconf and friends are the devil's
|
|
tools.
|
|
|
|
Usage:
|
|
|
|
make
|
|
./subsurface dives/*.xml
|
|
|
|
to see my dives (with no notes or commentary).
|
|
|
|
Or, if you have a dive computer supported by libdivecomputer, you can
|
|
just do
|
|
|
|
make
|
|
./subsurface
|
|
|
|
and select "Import" from the Log menu, tell it what dive computer you
|
|
have (and where it is connected if you need to), and hit "OK".
|
|
|
|
NOTE! There are often multiple models of dive computers that import
|
|
exactly the same way. If you have a Suunto Gekko, for example, the
|
|
import function works fine - even if you don't find the Gekko listed
|
|
explicitly. It has the same import engine as the older Suunto Vyper
|
|
(not "Vyper Air").
|
|
|
|
So check the (incomplete?) list of supported dive computers below, and
|
|
see which ones show up together. If you have the "Aeris Elite T3", for
|
|
example, you'd notice that it's in the same group with the "Oceanic Atom
|
|
2", and use that choice to import.
|
|
|
|
Suunto:
|
|
|
|
* Solution
|
|
|
|
* Eon, Solution Alpha and Solution Nitrox/Vario
|
|
|
|
* Vyper, Cobra, Vytec, Vytec DS, D3, Spyder, Gekko, Mosquito, Stinger and Zoop
|
|
|
|
* Vyper2, Cobra2, Cobra3, Vyper Air and HelO2
|
|
|
|
* D9, D6 and D4
|
|
|
|
Uwatec:
|
|
|
|
* Aladin
|
|
|
|
* Memomouse
|
|
|
|
* Smart and Galileo (infrared)
|
|
|
|
Reefnet:
|
|
|
|
* Sensus
|
|
|
|
* Sensus Pro
|
|
|
|
* Sensus Ultra
|
|
|
|
Oceanic, Aeris, Sherwood, Hollis, Genesis and Tusa (Pelagic):
|
|
|
|
* VT Pro, Versa Pro, Pro Plus 2, Wisdom, Atmos 2, Atmos AI, Atmos
|
|
Elite, ...
|
|
|
|
* Veo 250, Veo 180Nx, XR2, React Pro, DG02, Insight, ...
|
|
|
|
* Atom 2.0, VT3, Datamask, Geo, Geo 2.0, Veo 2.0, Veo 3.0, Pro Plus 2.1,
|
|
Compumask, Elite T3, Epic, Manta, IQ-900 (Zen), IQ-950 (Zen Air),
|
|
IQ-750 (Element II), ...
|
|
|
|
Mares:
|
|
|
|
* Nemo, Nemo Excel, Nemo Apneist, ...
|
|
|
|
* Puck, Puck Air, Nemo Air, Nemo Wide, ...
|
|
|
|
* Icon HD
|
|
|
|
Heinrichs Weikamp:
|
|
|
|
* OSTC, OSTC Mk.2 and OSTC 2N
|
|
|
|
Cressi, Zeagle and Mares (Seiko):
|
|
|
|
* Edy, Nemo Sport
|
|
|
|
* N2iTiON3
|
|
|
|
Atomic Aquatics:
|
|
|
|
* Cobalt
|
|
|
|
|
|
Implementation details:
|
|
|
|
main.c - program frame
|
|
dive.c - 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
|
|
|
|
A first UI has been implemented in gtk and an attempt has been made to
|
|
separate program logic from UI implementation.
|
|
|
|
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
|
|
|
|
WARNING! I wasn't kidding when I said that I've done this by reading
|
|
gtk2 tutorials as I've gone along. If somebody is more comfortable with
|
|
gtk, feel free to send me (signed-off) patches.
|
|
|
|
Just as an example of the extreme hackiness of the code, I don't even
|
|
bother connecting a signal for the "somebody edited the dive info"
|
|
cases. I just save/restore the dive info every single time you switch
|
|
dives. Christ! That's truly lame.
|
|
|
|
NOTE! Some of the dives are pretty pitiful. All the last dives are from
|
|
my divemaster course, so they are from following open water students
|
|
along (many of them the confined*water dives). There a lot of the
|
|
action is at the surface, so some of the "dives" are 4ft deep and 2min
|
|
long.
|
|
|
|
Contributing:
|
|
|
|
Please either send me signed-off patches or a pull request with
|
|
signed-off commits. If you don't sign off on them, I will not accept
|
|
them. This means adding a line that says "Signed-off-by: Name <email>"
|
|
at the end of each commit, indicating that you wrote the code and have
|
|
the right to pass it on as an open source patch.
|
|
|
|
See: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
|
|
|
|
Also, please write good git commit messages. A good commit message
|
|
looks like this:
|
|
|
|
Header line: explaining the commit in one line
|
|
|
|
Body of commit message is a few lines of text, explaining things
|
|
in more detail, possibly giving some background about the issue
|
|
being fixed, etc etc.
|
|
|
|
The body of the commit message can be several paragraphs, and
|
|
please do proper word-wrap and keep columns shorter than about
|
|
74 characters or so. That way "git log" will show things
|
|
nicely even when it's indented.
|
|
|
|
Reported-by: whoever-reported-it
|
|
Signed-off-by: Your Name <youremail@yourhost.com>
|
|
|
|
where that header line really should be meaningful, and really should be
|
|
just one line. That header line is what is shown by tools like gitk and
|
|
shortlog, and should summarize the change in one readable line of text,
|
|
independently of the longer explanation.
|