grep for Target doesn't work on non english platforms
-dumpmachine is (hopefully) supposed to always return
the target machine tuple
Signed-off-by: Martin Gysel <me@bearsh.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This should make the Makefile much more robust when cross compiling.
The windows.c code is now compile tested but not functionally tested.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds tested code for Linux and Mac OS, implementing the api that
Linus suggested.
The Windows code was moved into its own file, but hasn't even been compile
tested, yet.
In order to have just one interface to set or get a preference value we
encode TRUE as (void *) 1 and FALSE as NULL. This works consistently on
all platforms and regardless of whether we have 32 or 64 bit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I was getting the following error:
dive.h:8:25: fatal error: libxml/tree.h: No such file or directory
compilation terminated.
So I updated the Makefile to fix that error and follow the standard in
the file.
Signed-off-by: Terrance Stanfield <t@hollowcranium.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Open JDiveLog files by translating them to subsurface format using XSLT.
These files are identified by the name of the first element (JDiveLog)
and transform is applied to only these.
The XSLT feature is compiled in only if libxslt is installed. The
transformation files are installed globally in Linux under
/usr/share/subsurface/xslt. Windows and OSX still need appropriate Makefile
changes and testing.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This provides the relevant information for the currently selected dive
plus a bunch of statistics over all dives in the dive_table.
The visual design has lots of room for improvement
- right now the different fields change size
- it might be nice to have a more modern look for the entries
- the O2/He field is odd - for most divers the He value will
always be 0, so maybe we should only show He if there's at least one
dive that uses He? Also, we simply do a comma separated list of gases
for all the tanks used
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* 'macosx-app-bundle-1' of git://github.com/henrik242/subsurface:
Use the new packaging directory for MacOSX specific files, and provide shell script workaround to make the svg icon reachable.
Ignore process serial number argument when run as native MacOSX app
Add basic MacOSX app bundle install target
We don't want to run gtk-update-icon-cache during a package build, when
we're installing into a staging directory just to create a tree that will
be packaged up and really installed later. The standard heuristic seems
to be to skip gtk-update-icon-cache if DESTDIR is set (ie we're installing
to a different location than we're configured to run from).
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- Make use of the new packaging directory.
- Set a current directory for subsurface to find the svg icon. There might be a pretter solution to this.
- Somehow subsurface doesn't behave properly in the Dock. Running it in the background without Dock integration until we figure out why.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Native MacOSX app bundles are installed in /Applications. We want a separate
install target for this, since some would probably prefer the regular unixy
way.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Thanks to Michael Wiedmann I now know the magic incantation to get MinGW
to create a Windows executable that doesn't open two windows, a text
console and the actual gtk window.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With this we are able to include both a separate .ico file that the
program can load at runtime and a .res file (that is created from the .rc
file, both in the packaging/windows directory) that is linked into the
executable and makes the Windows Explorer show the correct icon for
subsurface.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
You can build subsurface with MinGW. It requires installing lots of random
packages, plus some things still don't work. One is that xml2-config
appears to be missing. So this annotates the Makefile to tell a person
building under Windows how to work around this. But we can't make this
platform conditional as this workaround is hardcoding the install path.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The stupid lib vs lib64 problem. I'm sure there's a more portable way to
handle this, but this at least seems to work.
Also fix the install target. Seriously, you create a directory with mode
644 and claim that this ever worked?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We've added a fair amount of features since 1.0 (like multi-tank) and
we've made things a lot prettier and supports editing much more
information. So let's make a new release.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This allows us the specifiy libdivecomputer's cflags (and also the
library, static or dynamic) outside of the Makefile
Signed-off-by: Martin Gysel <me@bearsh.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
make DESRDIR a prefix of everything according my understanding
of the GNU standards. This is also useful(/needed) for installing
in Gentoo. Declare BINDIR for bin/program directory.
Signed-off-by: Martin Gysel <me@bearsh.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit bd8948386d ("Since we don't want configure, use gnumake to find
libdivecomputer") was totally broken. Sure, using GNU make features is
fine. But then hiding in that commit is the fact that it also changed
it to use "-ldivecomputer" instead of just linking with the static
libdivecomputer archive.
And that's just a really bad idea. Dynamic linking is useful for things
like libc, where it allows sharing of the code pages across all the
programs using it. For something like libdivecomputer it's just a *bad*
idea, and doesn't even work. The libdivecomputer interfaces aren't
stable enough to make it a good idea even if it *did* work, and the
libdivecomputer "make install" phase doesn't do the proper ldconfig etc
setup anyway.
Static linking is just simpler and better. It also means that the
binary will work even if you move it around to another machine - since
libdivecomputer isn't exactly a "standard library"..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm trying to get subsurface to get closer to becoming a "regular desktop
application"; so far this is based on the recommendations and guidelines
on OpenSUSE and Fedora.
The icon is now named subsurface.svg and make install installs it in the
correct location. At runtime subsurface first checks if an icon is
installed and if it is it uses that - otherwise it falls back to the old
code that tries to read the svg file from the current directory.
We also install a subsurface.desktop file
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not quite the same format as for the kernel, but I want to do the normal
"edit the makefile before making a release" model that I'm used to.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It just puts the subsurface binary in $(HOME)/bin.
.. and then the binary won't find the icon file, so this is really not
enough of an install to get it really working, but whatever.
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>
Due to libdivecomputer's dependency, can be necessary to add libusb to pkg-config in order to compile,
so I exported the pkg-config line in the subsurface target to LIBS variable, and added a comment about libusb.
Signed-off-by: Riccardo Albertini <ssirowain@gmail.com>
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>
Ok, this is the ugliest f*&$ing printout I have ever seen in my life,
but think of it as a "the concept of printing works" commit, and you'll
be able to hold your lunch down and not gouge out your eyeballs with a
spoon. Maybe.
I'm just doing the cairo display as-is for the printout, which is a
seriously bad idea. I need to not try to do colors etc, and instead of
having white lines on a black background I just need to make thelines be
black on white paper.
But that would involve actually changing the current "plot()" routine,
which is against the point of the exercise right now. This really is
just a demonstration of how to add printing capabilities.
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>
Make it about general equipment management, and start hooking up
functions to show new equipment information when changing dives (and to
flush changes to equipment information for the previously active dive).
Nothing is hooked up yet, and it's now showing just one (really big)
cylinder choice, so this is all broken. But it should make it possible
to at least get somewhere some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ok, so it's not connected to anything yet, and the tank choices (that
don't do anything) are some random hardcoded collection, but maybe it
will do something some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
That seems to be the gtk2 way. Whatever. diveclog ends up defaulting
to metric units, because we all know that's the right thing to do.
However, I learnt to dive in the US, so I'm used to seeing psi and feet.
So despite the sane defaults, I want diveclog to use the broken imperial
units for me.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now the dive profile plot *really* needs some units. The pressure is
just a random line otherwise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This just generates another xml file. Don't get me wrong: I still don't
like xml, but this way we can save in the same format we load things
from. Except the save-format is a *lot* cleaner than the abortion that
is Suunto or libdivecomputer xml.
Don't bother with some crazy xml library crap for saving. Just do it!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The executable is now called 'divelog'. If this gets useful enough to
actually *use*, I guess I'll have to come up with a real name some day.
Add a silly README, rename 'parse' to 'parse-xml'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It should have depth, time, place etc information, but right now it only
has a fake depth that doesn't even get updated. Just to show the idea
of the table usage.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
