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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Create a "struct cylinder_widget" so that when we handle multiple
cylinders, we can match them up with the actual cylinder data;
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We really do want to "pack" them, rather than use up the whole size. I
think.
I may end up playing around more with this.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It seems to be sufficiently useful to be worth updating the dive
information now.
This still doesn't handle multiple cylinders in any way. I need to
think about the interface for that.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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?
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>
