.. and then allocate just the plot-info entry array dynamically.
We want to have a longer lifetime for the basic plot_info data
structure, because we want to do computer selection and maximum
time/depth/temperature computations *before* we start plotting anything,
and before we allocate the plot entry array.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This extends on our current tooltip logic (which shows events when you
mouse over them) to show tooltips for the whole profile area.
If you mouse over an event, that is still shown in the tooltip, but
even in the absense of events, the tooltip will be active, and mousing
over the profile area will show the time, depth and pressure.
This can certainly be improved upon further, but even in this form it is
useful.
Fixes#9
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Simply add a dive option on bigger surface, whith bigger fonts.
The size isn't A4 nor A5, but the size used by some popular paper
divelogs.
The modification performs better if we transpose the profile and
the text of the dive, because, if the notes are very brief,we get
an excess of white space at the bottom of the print.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Tests have shown that the most multi-platform way to do printing with GTK is
to use GTK_UNIT_INCH (or GTK_UNIT_MM) with GtkPrintOperation. Tested on
Linux, OSX, Windows.
However this requires the appropriate scaling for Pango and Cairo to be done,
with separate plotting logic for printing and drawing on the screen. To achieve
that, profile.c:plot() now accepts a scaling parameter from type
"scale_mode_t" defined in "display.h".
Also due to new scale, small decimal numbers (such as 6.12345) cannot be well
stored in "cairo_rectangle_int_t" therefore it is replaced with
"cairo_rectangle_t", which uses doubles to provide Cairo with a drawing
area.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Minor whitespace cleanup.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now we just implicitly decide "print only selected dives" when
there is more than one dive selected (and then print all dives if only
one dive is selected).
We probably should have an checkbutton in the dive details page for the
choice. But I wanted to avoid the pain that is gtk as far as possible
for the initial implementation. The code is ready to be changed to just
use a checkbutton instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Until now we had the choice between:
- pretty-print
- with dive profiles
- without dive profiles
- table-print
This commit remove the pretty-print without dive profiles, leaving the choice to
either pretty-print or table-print.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
With this change, instead of asking to print the dive profile,
you ask to not print them. So the checkbox in the print options
changes from 'Show profiles' to 'No dive profiles'.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
Merge freediving tweaks (zoom in on short dives etc) from Maximilian
Güntner.
Trivial conflicts in display.h due to unrelated printing stuff just
happening to be added nearby.
* 'freediving-tweaks' of git://github.com/mguentner/subsurface:
moved zoomed_plot to display.h
plot the time with a fixed padding (leading zero)
updated/corrected comment
added "Zoom" button and improved scaling
fixed indentation
use increments that make sense for 600 seconds
Plot shorter (apnea) dives with a reasonable scale
With this commit, the user can choose between two printing modes:
- pretty print (with or without the dive profile)
- table print (which is nothing less than a table formating containing the
information)
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
The profile colors were defined all over the place, so I put them all in one spot. I'm unsure if this is the best solution to that problem, but I guess it's a step in the right direction.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
We draw a little red triangle (of hardcoded size - not sure if this SHOULD
scale with the size of the plot... I like it better if it doesn't) to the
left of an event.
We then maintain an array of rectangles that each circumscribe one of
those event triangles and if the mouse pointer enters one of these
rectangles then we display (after a short delay) a tooltip with the event
text.
Manually creating these rectangles, maintaining the coordinate offset,
checking if we are inside one of these rectangles and then showing a
tooltip... this all seems like there should be gtk functions to do this by
default... but if there are then I failed to find them. So instead I
manually implemented the necessary logic.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Previously we passed in width and height and the routine itself decided to
keep 5% margin around each edge - oddly doing this with double precision,
even though this is all integer coordinates.
Instead we are now passing in a drawing_area. We are kind of abusing the
cairo_rectangle_int_t data type here - but it seemed silly to redefine a
new data type for this.
Width and height give the size of the TOTAL drawing area (as before).
x and y give the offset from the edges - so the EFFECTIVE drawing area is
width-2x and height-2y
This is in preparation for adding tooltips - those need to know the
coordinate offsets from the edges - so having this hard coded inside the
plot function didn't make sense anymore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.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>
Instead of the hardcoding to "Sans 8", allow people to set it in the
preferences.
Also, make the unit choice be a frame in the preferences dialog instead.
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>
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>
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>
This tweaks:
- packing to be what you'd kind of expect
- makes the "summary info" always visible
- the "extended info" is now on a notebook page of its own
- dive profile the first notebook page, since the summary
information is visible regardless.
which all just seems a lot more logical.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm going to add a menu to import (and eventually export) dives, and so
we'd like to be able to start out with no dives at all. Right now we
croak if that happens - it's not like the code has been written with
actual end users in mind.
So start cleaning things up. First make the 'current_dive' macro work
right even for invalid dives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's still the ugliest application ever, but now it at least gives you
some basic dive info.
I'd love to add a way to edit the dives to add new data (name, buddies,
location etc), but that would also require the ability to save the end
result. Maybe some day.
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>
.. and repaint the profile when the selection changes.
Now, if it just wasn't so ugly, it might even be useful. Except it
obviously needs to also show all the other dive information. And allow
the user to fill in details. And save the end results.
So no, it's not useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
