]> git.tdb.fi Git - ext/subsurface.git/blobdiff - README
Catch changes to the info of the current dive when quitting
[ext/subsurface.git] / README
diff --git a/README b/README
index 0ff77c375e82c7957b9c8c935498a9934698c065..204b9a3bf8290a8e454f65a464e4e5df1d02fa60 100644 (file)
--- a/README
+++ b/README
@@ -4,20 +4,57 @@ I'm tired of java programs that don't work etc.
 
 License: GPLv2
 
-You need libxml2-devel and gtk2-devel to build this.
+You need libxml2-devel, gtk2-devel and GConf2-devel to build this.
+
+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
 
 Usage:
 
        make
-       ./divelog dives/*.xml
+       ./subsurface dives/*.xml
 
 to see my dives (with no notes or commentary).
 
-There's a lot of duplicates in there, and divelog will de-duplicate the
-ones that are exactly the same (just because they were imported multiple
-times).  But at least two of the dives have duplicates that were edited
-by Dirk in the Suunto Dive Manager, so they don't trigger the "exact
-duplicates" match.
+Or, if you have a dive computer supported by libdivecomputer (and
+connected to /dev/ttyUSB0), you can just do
+
+       make
+       ./subsurface
+
+and select "Import" from the File menu, tell it what dive computer you
+have, and hit "OK".
+
+There's a lot of duplicates in the XML files that come as an example,
+and subsurface will de-duplicate the ones that are exactly the same
+(just because they were imported multiple times).  But at least two of
+the dives have duplicates that were edited by Dirk in the Suunto Dive
+Manager, so they don't trigger the "exact duplicates" match.
+
+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
@@ -38,3 +75,35 @@ 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 paragrahps, 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.