Added a comment about libusb dependency in Makefile.
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.
It got removed by some of my overly aggressive cleanup in commit fefcbf125e89 ("Remove dive info frame") because the dive info frame
initialization also initialized the main window title..
And I *really* would want to make the dive list be a ComboBox or
something like that, rather than a ListView. I need to really
understand those things, though.
Turn the rest of the duplicate string fields to use render functions
So instead of having a depth field (in mm) for sorting, and the text
field that contains the same thing in text, we now have all the fields
we use in "native" format, and we just render them as text dynamically.
Typo turned EAN (Enriched Air Nitrox) to EAD. Which does mean something
too, just to confuse people - but while it's still nitrox-related, it's
entirely the wrong thing (Equivalent Air Depth). I don't think anybody
would ever care to see *that*. With computers, why would you care?
Anyway, Dirk noticed it, and suggested I just use O2% instead. It's not
like EAN is all that readable either.
Hey, now you can sort your dives by how good your SAC is. Which sounds
more useful than it probably actually is. But maybe you can see
patterns in what makes your SAC suck..
Sure, it's visible elsewhere, but this way you can search and sort for
it, and see several entries at once. So again, having it visible in the
dive list is a good thing.
Make the pane split be vertical rather than horizontal
Ok, this makes that dive list look empty and ugly, but as mentioned, we
really should start filling it with all the useful information that we
can sort by, like temperature and air use.
And even stuff that might not make sense to sort by (would you want to
sort by cylinder size or name? Or by nitrox percentage) could still be
*shown* in the list fairly naturally.
It has always been problematic, and I've been moving things in and out
of it.
And it just isn't a very powerful widget. You can't *do* anything with
it. The information it shows you may be useful, but the core stuff
already shows up in the dive list.
And the dive list is actually a much superior widget over that static
dive info frame. The information that shows up in the dive list can be
sorted by column, for example.
So when we show temperatures or SAC numbers in the dive info frame,
that's actually a very bad place to show them: we would be much better
off showing it in the dive list, and then we could sort by SAC or by
temperature.
In other words: just remove the thing. Instead, plan to extend the dive
list to contain all the information. That will probably mean that we
need to change the current pane widget to be a vertical pane, rather
than a horizontal one, but what's wrong with that?
Currently we use random hard-coded integers, and it's not always clear
what is going on. Make it much more explicit with an enumeration of the
different divelist columns.
And change the column order to make it more logical, and make sure we
actually catch all uses while at it.
If the velocity is slower than FAST then we look back up to 30 seconds and
calculate the velocity for the past 30 seconds instead.
For the first version I'm not doing the average of the changes but simply
the change from beginning to end.
The alternative would be to do another triangle smoothing or something
like that - but as we don't know how many samples we have in the 30 second
window, it's a little harder here.
So far Linus has hated all of my attempts to visualize vertical velocity
through color. This time I'm trying something dramatically new: there is
no PURPLE involved. Maybe that will convince him of the value.
We simply calculate the vertical velocity for the current plot segment
(last sample point to this sample point - in this version even without
divisions by zero) and assign a label based on the rate of change. These
labels are translated through a predefined table into colors:
Dark green is +/- 5ft/min (stable)
Light green is descents up to 30ft/min and ascents up to 15ft/min
Yellow is descents up to 60ft/min and ascents up to 30ft/min
Orange is descents up to 100ft/min and ascents up to 60ft/min
Red is outside of those ranges - you are most likely in danger
Show tank / nitrox / air consumption information in the info_frame
Even though we go down to an 8pt font the info_frame changes size when the
air info is added. I don't like this but want to see how Linus would like
this resolved before going overboard.
Minor tweaks to the formating (we don't need two decimals when printing
the liters of air consumed).
This patch does NOT remove the plot of the air information in the profile
graph. I think we want to remove that once we like the text where it is,
but I wanted to do one thing at a time.
It's now in the window title - no point in having it twice.
Also added a little "Dive #xx - " template. The old "##. " was a bit too
minimalistic for my liking.
Put the dive number and location in the window title bar
I suspect the "info" area is better used for actual values, so move the
dive location into the window title instead (using date if no location
info), and title the info frame with date and time.
This just means that the date/time gets removed from inside the frame:
we may want to put air consumption info in there instead?
Change the duration max rounding as noted by Dirk, and move the air
consumption down further towards the bottom right corner. In
particular, I make the text positions not scale with the window size,
purely by the size of the text.
Minor corrections to printing of the last temperature
- the time stamp where we printed the last temp was wrong
- we really shouldn't check mK for being identical - especially on dive
computers that store a lot of samples
Use plot_info for final remaining temperature and pressure data plots too
Ok, this is pretty much it now. Instead of having various random checks
for "is the time of the sample past the end of the dive" hacks, we not
plot all graphs from the cleaned-up plot_info structure instead of the
raw samples.
Plot pressure data based on 'struct plot_info' rather than raw dive data
Further movement to using the sanitized and cleaned-up plot info rather
than the raw data.
The raw dive data contains samples from the end of the dive that we
don't want to drop, but that we also don't want to actually use for
plotting the dive. So the eventual end goal here is to not ever use the
raw dive samples directly for plotting, but use the diveplot data that
we have analyzed for min/max (properly ignoring final entries) etc.
There's still some data that we take from the samples when plotting, but
it's getting rarer.
Do min/max pressure and temperature based on the non-surface data
Do the min/max calculations only *after* we have removed the extra
surface events at the end.
The Uemis data in particular has a lot of surface events after the dive,
and we don't really want to take them into account since we won't be
plotting them anyway.
.. I'll want to move pressure limit calculations into the 'plot_info',
so that we can do several passes of analysis and change dive limits etc
without having to actually modify the dive data itself (or add new
fields to 'struct dive' just for plotting).
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.
Sadly, no way to show them yet. But it would be nice to let people
enter them (and it would be doubly nice to have a dive computer that
does it at the surface), and then perhaps just do the "point browser at
google maps" thing.
Saving/parsing tested by hand-feeding the location of Enenui (Molokini
Crater) from google maps by hand into my divelog.
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.
Currently we print the temperature every five minutes. Especially with
dive computers that keep rather frequent temperature samples that means
that we have one more interesting data point that we don't label: the
surface temperature at the end of the dive.
This patch adds some logic to try to print the last temperature sample
that was recorded before the dive ended - unless that same value has
already been printed (to avoid silly duplications on dive computers with
less frequent sampling)
Don't draw temperature plot past the end of the dive
Just like we end depth and tank pressure plots once we are on the surface
(this is relevant for dive computers like the uemis Zurich that keep
recording samples after the end of the dive)
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.
Flush any pending changes at notebook 'switch-page' time
Dirk points out that equipment changes (cylinder size etc) do not cause
a proper repaint of the dive profile with new SAC information. The
reason? We haven't flushed the changes when the notebook changes from
the equipment page to the dive profile page.
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.
Separate the notion of creating the cylinder widgets from showing them
Now we always create the MAX_CYLINDER sets of cylinder widgets. But we
don't actually pack them into the frame - that's a separate phase.
Right now we still do the stupid "always just pack two cylinders" thing,
but the idea is that we can pack just as many as the dive needs on a
per-dive basis.
This just always shows two cylinders, which is obviously bogus, but it's
a good test-case for the multi-cylinder case.
I need to figure out how to dynamically show the right number of
cylinders, but that also involves the notion of adding a cylinder in
order to fill out information that didn't use to exist.
That's lower priority - now the infrastructure seems to be there.
More work on abstracting the gtk cylinder widget thing
Ok, now we have an array of them, and most of the time we pass the right
pointer back and forth.
There's still a couple of places that hardcode "gtk_cylinder[0]" as the
data, but by now they are mostly things that should iterate over all the
cylinders.
Let's try to be consistent about this. Make the parent of each widget
be a box. Maybe the frames come with boxes, but since I have no clue
about gtk, I'm going to just always create them by hand.
It doesn't really make much of a difference, but it can be visible
especially with lots of tight samples. Miter joins really look horrible
for acute angles.
Or not. The temperature graph is usually ugly as hell, but Dirk has the
cool dive computer with lots and lots of temperature readings. Which
makes the graph a pretty graph, rather than a butt-ugly staircase like
mine.
Next time: get a dive computer with an OLED screen, and that can draw
pretty temperature graphs.
Libdivecomputer: start actually importing the dive data
So this actually reports the dive data that libdivecomputer generates.
It doesn't import special events etc, but neither do we for the xml
importer.
It is also slow as heck, since it doesn't try to do the "hey, I already
have this dive" logic and always imports everything, but the basics are
definitely there.
Instead of writing out the progress events, use them to update a real
progress bar.
Also, we need to handle gtk events while busy with the dive computer
reading. That should *probably* be done with a threading model, because
libdivecomputer does seem to have some timing sensitivity - I'm getting
"failure to read memory block" if I make that loop do the standard
while (gtk_events_pending())
gtk_main_iteration();
thing. Besides, even if we did do that loop, it would still cause
problems when the libdivecomputer code is stuck reading a serial line
that doesn't respond or whatever.
But for now this ugly hack is "good enough" to get further.
This actually gets me far enough that it prints out all the dives on my
dive computer. It doesn't actually turn them into real dives yet,
though - only a series of ugly 'printf's so far.
And it hangs after printing the last dive. So I'm doing something wrong.
.. this now registers the dive parsing callback, and starts to parse the
data. So I can see the last divetime on my Suunto Vyper Air now.
Still a lot more boilerplate stuff to go, though. The libdivecomputer
interfaces really are pretty insane: why should the caller set up the
dive parsing for each computer type, when libdivecomputer knows what
types it has? IOW, much of that boilerplate should be hidden inside of
libdivecomputer, rather than exposed to the user.
But whatever. I'm taking pieces from "examples/universal.c" as I go
along (it's under LGPL 2.1). I want to do it in small chunks just to
feel that I understand what's going on, rather than just blindly copying
it all.
Flesh out the libdivecomputer interfaces some more
.. start some error reporting, and register some early (empty)
callbacks.
This still doesn't actually do anything. But commit early, commit
often: when I start seriously breaking things, I want to have a "hey,
this still at least compiled" state.
Avoid using type 'gasmix_t': use 'struct gasmix' instead
libdivecomputer already uses 'gasmix_t' for its own gasmix thing. I
don't like th eway we step on each others name spaces, but hey, might as
well just use 'struct gasmix' and avoid the typedef.
Start some very initial libdivecomputer integration
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.
The Diving Log temperature reading is in Fahrenheit for the samples (for
the per-dive water/air temperature it's in Celsius). But it seems to
have a bug where a lack of a sample has been turned into 32 Fahrenheit
(which is 0 celsius). This is despite the dive itself having a water
temperature of 8 degF.
Just throw away those bogus freezing temperatures. Sure, they can
happen, and ice divers are crazy - but in this case I know it's just an
error in the log, and it looks very much like a Diving Log bug.
The LP85+ name is not something we'd normally want to recognize. The LP
cylinder names all tend to be by the "+" pressure anyway, and that's
what we do in the equipment handling naming.
When we change units, we need to flush any currently active dive
information in the old units, and then carefully reload it in the new
units.
Otherwise crazy stuff happens - like having current cylinder working
pressure values that are in PSI because that *used* to be the output
unit, but then interpreting those values as BAR, because we changed the
units.
Also, since we now properly import working pressure from Diving Log,
stop importing the (useless) cylinder description. The Diving Log
cylinder descriptions are things like "Alu" or "Steel". We're better
off just making up our own.
Finally, since Diving Log has cylinder size in metric, make sure that we
do the "match standard cylinder sizes" *after* we've done all the
cylinder size conversions to proper units.
Oh Gods. Why are all other scuba programs so f*&% messed up?
The Diving Log cylinder working pressure is in bar - which is all good.
But their pressure *samples* are in PSI. Why the h*ll do people mix up
units in the same damn file like that? I despair at the pure
incompetence sometimes.
I suspect the pressure samples aren't "really" in PSI: they are probably
in some user-specified units.
Add more static cylinder types - and pick them up from the dive log
This adds a few more predefined cylinder types to the static list, but
perhaps more importantly, if we try to show a cylinder description that
we haven't seen before, we automatically add that description to the
list as well.
This way, if people have their own cylinder types, our cylinder
management will automatically figure them out and make it easy to enter
them.
NOTE! It might be best to add the new cylinder description at dive log
load time, rather than at 'show' time.
Add new cylinder models to the cylinder model store
We also need to actually fill the model store with the cylinder models
we have in our dive lists to begin with.
This makes it all *trivial* to add a new cylinder model: just use a new
description, fill in the size and working pressure, and you're done.
The type automatically gets filled in, unless that description already
existed (in which case we leave it alone).
If the output units are set to cuft and psi, then we should show the
cylinder size and pressure properly.
NOTE! In the absense of pressure data, we *always* show the cylinder
volume in liter. There's no way to convert it to imperial units, since
the imperial units are not in physical size, but in air volume
normalized to surface pressure..
Now that we don't mess up import, we can save the cylinder working pressure
We used to have the heuristic that if we saw a cylinder working
pressure, then the cylinder size would be in cuft. Which meant that we
couldn't export our working pressures, because it would mess things up
on import.
But working pressure is actually nice to know, if you ever work with
cylinders in imperial units. So now that the import is fixed, add the
working pressure to the export.
First (broken) try at actually tracking cylinder types
This doesn't actually change the cylinder type info in the dive, because
it's too broken for that. Instead it prints out what it would change
things to.
The gtk2 notion of text input focus is *really* odd. Why is the
cylinder type sometimes selected, and sometimes not?
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.
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.
projects / ext / subsurface.git / log