This is dedicated to Lubomir ;)
Should work (tm). Not sure though if you want target
'gen_version_file' as a pre-requisite to $(NAME) or some other target.
[Dirk Hohndel: minor adjustments to make it work with gtk-gui.c]
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since their XML file gives us no information as to the measurement system
used we need to ask the user to explicitly set it to metric before they
create the XML file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On Tue, Feb 26, 2013 at 6:19 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
> Miika Turkia <miika.turkia@gmail.com> writes:
>
>> On Tue, Feb 26, 2013 at 5:54 PM, Dirk Hohndel <dirk@hohndel.org> wrote:
>>> Miika Turkia <miika.turkia@gmail.com> writes:
>>>
>>>> On Tue, Feb 26, 2013 at 6:45 AM, Dirk Hohndel <dirk@hohndel.org> wrote:
>>>>> I added a few test dives exported from other software (Dm3, DiveLog 5.08,
>>>>> JDiveLog 10.2 from Mac - last one doesn't parse because of encoding... Also
>>>>> a composed XML zip file from DiveLog isn't supported, yet)
>>>>> Find them under dives
>>>>
>>>> Now this gets interesting. Is there ANY logic in the units in the
>>>> dives/TestDiveDiveLog5.08.xml? It seems that some of the temperatures
>>>> are in C (Airtemp and Watertemp) and some in F (samples). Otherwise I
>>>> would guess we are talking metric here, but I do not see any specs
>>>> (another log I have seen from DivingLog had all the units in metric,
>>>> as far as I could guess). BTW is the Weight in kg or lb?
>>>
>>> I have purchased DivingLog and should be able to create any combination
>>> of data for the test file that we could possibly want. I'll do a set in
>>> a moment that describe what SHOULD be there in their notes, maybe that
>>> will clear things up.
>>>
>>> That said, I really want to release 3.0.1 in the next couple of hours,
>>> so this may have to wait for 3.0.2 (if we end up needing that) or 3.1.
>>>
>>>> The divelogs.de UDCF format looks like it shouldn't take long to write
>>>> support for. I'll look into it this evening.
>>>
>>> It is evening for you, right? No pressure, just making sure I understand
>>> what may be coming in in patches in the next hour or two
>>
>> I currently have one version of the DivingLog XSLT. So a bit of
>> verification and that could possibly be used as is. However, this
>> could use a bit more testing than a new support to make sure things
>> are not going to be any worse than they currently are.
>>
>> I have not started with the UDCF yet, but that could be reasonably
>> fast to implement. However, no guarantees. (And yes, it is evening for
>> me)
>
> I can hold off 3.0.1 a couple hours longer if that is a realistic thing
> to do. I don't see the UDCF as that important since we have a different
> format from them that we support. So I think the best possible DivingLog
> support would be my preference.
>
> I'll add a few more exported dives from DivingLog next (and fix the
> naming of the existing ones).
In that case, here is the DivingLog XSLT if anyone can give it a test.
miika
From 4a62058f4f6fd4780f04bce6e1fe45e20abcf33f Mon Sep 17 00:00:00 2001
From: Miika Turkia <miika.turkia@gmail.com>
Date: Tue, 26 Feb 2013 17:46:53 +0200
Subject: [PATCH] XSLT for DivingLog
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Two XML files, one all imperial, one all metric
Quick inspection shows that there is no indication whatsoever on metric vs
imperial in the file. That is of course completely moronic and makes
automated import more or less impossible.
I also added a different zip file from DivingLog - quick analysis shows
that this is simply the corresponding xml file, wrapped in a zip
container. So this should be trivial to add.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Suuntu DM3
DiveLog 5.08 XML
DiveLog 5.08 UDDF
DiveLog 5.08 UDCF
DiveLog 5.08 compressed zip (we don't support that)
JDiveLig 10.2 from Mac (fails because of ecoding)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Yes, we could try and bundle the user manual with the executables and open
a local copy of it - but this seemed much easier and safer to do. It does,
of course, add another string...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This creates a helper function called "gas_volume()" that takes the
cylinder and a particular pressure, and returns the estimated volume of
the gas at surface pressure, including proper approximation of the
incompressibility of gas.
It very much is an approximation, but it's closer to reality than
assuming a pure ideal gas. See for example compressibility at
http://en.wikipedia.org/wiki/Compressibility_factor
Suggested-by: Jukka Lind <jukka.lind@iki.fi>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- missing strings from parse-xml.c
- translation for "No Events"
- small uppercase fix
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This time for the new string in the Events Filter dialog adden in commit
66cb5ae00b68 ("Show a "No Events" label when there are no events in the
filter dialog")
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Uses profile.c:evn_foreach() to retrieve the number of events, which
if zero, no table is added in the dialog and the label is added instead.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In download_dialog_release_xml() we check if state->xmldata is non-NULL
and free it. But we don't set it to NULL anywhere, so if the user hits
cancel the variable is undefined.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- Added a help button that links to the online API page and should provide
a sufficient start to the new user.
- Use download_dialog_response_cb as a callback for most dialog reponses
instead of waiting for gtk_dialog_run() and using goto e.g. in the case
of GTK_RESPONSE_HELP.
- Fixed some integer signedness warnings in download_dialog_traverse_xml()
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There is a bug in GTK 2.2x where the links in the about dialog
(and URI's in general) do not work on Windows. To solve that
we add the OS specific method subsurface_launch_for_uri().
But to dispatch URI requests from the about dialog we need to
set a hook either with gtk_about_dialog_set_url_hook() (which is
deprecated from 2.24) or using signals like "activate-link".
One problem with the "activate-link" signal thought is that
we need to have a reference of an about dialog to pass to
g_signal_connect(). So instead of using gtk_show_about_dialog()
let's manage a dialog ourself with gtk_about_dialog_new(),
gtk_dialog_run(), gtk_widget_destroy().
Other changes:
- for GTK _bellow_ (but not including) 2.24 use
gtk_about_dialog_set_url_hook()
- use g_object_set() which is a convenient replacement for
the varargs list in gtk_show_about_dialog() (also makes the diff smaller).
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The about dialog URI calls are broken on Windows, therefore we needed
a way to override the default URI method. On versions bellow or equal to
GTK 2.24 this is possible with gtk_about_dialog_set_url_hook(),
which on the other hand is deprecated for newer GTK versions.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Ticket #63 - divinglog 5.08 import issues
This patch will include the GPS coordinates from divinglog.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit 0f31b71c3588 ("User documentation - describe the dive profile")
the description of the depth profile coloring was incorrect.
I also fixed some language issue and tried to better describe the zoom
options.
Finally I increased the revision number of the user manual.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 90d3c5614a ("Centralising and redefining values as integers")
broke SAC-rate calculations. In particular, it changed "to_ATM()": to
use the centralized SURFACE_PRESSURE helper define, but in the process
it changed a floating point calculation to an integer calculation, and
it threw away all the fractional details. Any user of "to_ATM()"
basically dropped to an accuracy of a single atmosphere.
The good news is that we didn't use to_ATM() for things like depth
calculations, but only for cylinder pressures. As a result, the error
ends up being relatively small, since the pressures involved are big,
and thus the error of rounding to whole atmospheres is usually in the
1% range. The cylinder sizing tends to be off by more than that
anyway. But it was wrong, and not intentional.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code was written to get the SAC rate correct, but we probably do
want to have the duration and mean depth of the dive always be shown for
the non-surface-time.
So move the code from the sac-rate calculation to the generic dive fixup
part. This makes the dive list and statistics all show the duration as
the under-water duration, which is not necessarily the same as
"difference between beginning and end of dive".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We computed a made-up average depth based on the maximum depth, and used
that. That's questionable even if we didn't have any explicit average
depth to begin with, but it's particularly wrong if we did have an
explicit average depth to use.
Now, admittedly we have no way to actually create fake dives like this
with a particular average depth, so this really doesn't make any
difference in real life. But we should do this right.
Also, make the XML be in the format that subsurface actually saves
things in (mainly things like cylinder sizes having an extra decimal
place, but also ordering of XML elements).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This assumes that you are not breathing your cylinders while at the
surface, which may or may not be correct, but is usually the right
thing. Regardless, we're better off giving a conservative (higher) SAC
rate estimate for a diver that breathes his cylinder at the surface too
than giving an artificially low one because the diver ended up using his
snorkel and we didn't take that into account.
NOTE! This basically calculates a better duration and average depth than
the ones we end up showing in the dive list. Maybe we should actually
show this "no-surface-time" duration and average depth instead of the
ones we do show?
That's a separate question, though.
Added a test-case for the surface case to the sac-test.xml dives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We even documented that we did SAC in bar*l/min, but the "S" in SAC
stands for "Surface". So we should normalize SAC rate to surface
pressure, not one bar.
It's a tiny 1% difference, and doesn't actually matter in practice, but
it's noticeable when you want to explicitly test for SAC-rate by
creating a test-dive that averages exactly 10m. Suddenly you don't get
the round numbers you expect.
[ Side note: 10m is not _exactly_ one extra atmosphere according to our
calculations, but it's darn close in sea water: the standard salinity
of 1.03 kg/l together with the standard acceleration of 9.81m/s^2
gives an additional pressure of 1.01 bar, which is within a fraction
of a percent of one ATM.
Of course, divers have likely chosen that value exactly for the math
to come out that way, since the true average salinity of seawater is
actually slightly lower ]
So here's a few test-dives, along with the SAC rate fixup to make them
look right.
(There's also a one-liner to dive.c that makes the duration come out
right if the last sample has a non-zero depth, and the previous sample
did not: one of my original test-dives did the "average 10m depth" by
starting at 0 and ending at 20m, and dive.c got a tiny bit confused
about that ;)
[ The rationale for me testing our SAC rate calculations in the first
place was that on snorkkeli.net user "Poltsi" reported that our SAC rate
calculations differ from the ones that Suunto DM4 reports. So I wanted
to verify that we did things right.
Note that Poltsi reported differences larger than the difference of
BAR/ATM, so this is not the cause. I'll continue to look at this. ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This XSLT imports the UDDF logs that I have received samples of. This
includes kenzooid and Heinrichs Weikamp's DR5.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For the "Edit dive date/time" dialog, (time->tm_min / 5)*5)
with integers can lose precision due to truncation, showing for example
a value of 55, where 59 is the actual previsouly stored value.
Reported-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The quotes are not needed either (nothing to expand there).
Signed-off-by: Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn@axis.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Someone who is better at shell script writing needs to review this.
Here's what it's supposed to do. Create version strings with three or four
values for darwin or win, respectively, that we can use as the versions of
the bundle or installer. The version that Subsurface reports isn't
affected by this. So in a way this is automating something that's mostly
cosmetic.
If we have a 2 digit version number (like 3.0), do the same the old script
did - add just zeroes if we are on a tag, otherwise add the number of
commits since the tag (and a last 0 if on win).
If we have a 3 digit version numner (like 3.0.1), leave it alone on mac
and add either the number of commits since the tag or a zero if we are on
the tag on win.
Now this can create the same version number for two different versions on
darwin: the first commit after 3.0 and the version tagged as 3.0.1 will
both get the same number. That's kinda silly but remember - the non-tagged
versions aren't supposed to be widely distributed (and the third digit in
them should be much larger than anything we'd ever release; we are
already on commit 16 since the last tag and hopefully will never release a
3.0.16 as tagged release). And of course the full version as displayed in
the About box is always able to tell things apart because of the SHA added
at the end if it's a non-tagged version.
So why all this magic? The reason we do this is so that during development
we are able to create Mac and Windows installers and they get reasonable
version numbers, based on the versioning that these vendors suppose. And
without manual intervention.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
