So far we always used the duration of the first divecomputer. The same fix
needs to be done for some of the other calculations that always use the
first divecomputer.
This commit also removes some obsolete code from the webservice merging.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The previous attempt in commit f305c5c83fe1 ("Correctly parse translated
cardinal directions") suffered from a bit of false advertising in that it
wasn't, actually, "correct". It made silly assumptions about the length of
the translated strings being 1 and also forgot the middle part of the
algorithm where we use the appearance of 'E' or 'W' (and their translated
brethren) as indication that there are no minutes for the the latitude.
Hopefully this version does better.
Reported-by: Sergey Starosek <sergey.starosek@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The air temperature editing was broken when you edited multiple dives at
once: even if you didn't actually change the air temperature, all dives
would be reset to that particular temperature.
The logic for editing dives is that we have a 'master' dive (which is
the dive that all the entries get filled in from), and only if the
entries have changed from what the master dive information was (ie the
user actually edited it) do we change that particular piece of
information.
And we only change it for dives that match the master dive for that
entry.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When editing a new dive, and using a dive site name that we have
already seen previously, and have GPS information for, pick up that
GPS information from the previous dive by default.
NOTE! When editing dive site locations for dives that already have GPS
information, or when we've modified the GPS information explicitly
some way while editing the dive (either through map input or by
editing the text field directly) we do *not* use this automatic logic.
So if you messed up the GPS information some way and want to
re-populate it with the automatic mode, you need to explicitly clear
the GPS text-field, at which point we go back to "ok, let's try to
pick up automatic GPS data from previous dives with the same name"
mode.
Also note that we do the automatic location lookup only when actually
editing the location field. So if you already wrote the dive site
name, then cleared the GPS field, you now need to go back to the dive
site name and edit it again to get the automatic GPS filling.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We now compare to both the standard English characters ('N', 'E', etc) as
well as to the translated strings (_("N"), _("E")) when parsing GPS
strings.
Reported-by: Sergey Starosek <sergey.starosek@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the changes to the selection logic the selected_dive variable didn't
get updated at the end of planning a dive. With an empty dive list that
could cause selected_dive to be -1 which would subsequently cause a
SIGSEGV when trying to edit the newly created dive.
With this commit we use the shared go_to_iter() function and also make
sure that selected_dive is set correctly.
Reported-by: Sergey Starosek <sergey.starosek@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This no longer abuses the dive merging code (which would leave stray
"dives" behind if a gps fix couldn't be merged with any of the dives) and
instead parses the gps fixes into a second table and then walks that table
and tries to find matching dives.
The code tries to be reasonably smart about this. If we have
auto-generated GPS fixes at regular intervals, we look for a fix that is
during a dive (that's likely when the boat where the phone is staying dry
is more or less above the diver having fun). And if we have named entries
(so the user typed in a location name) we try to match them in order to
the dives that happened "that day" (where "that day" is about 6h before
and after the timestamp of the gps fix).
This commit also renames dive_has_location() to dive_has_gps_location() as
the difference between if(!dive->location) and if(dives_has_location) is a
bit too subtle...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Mostly coding style and whitespace changes plus making lots of functions
static that have no need to be extern. This also helped find a bit of code
that is actually no longer used.
This should have absolutely no functional impact - all changes should be
purely cosmetic. But it removes a bunch of lines of code and makes the
rest easier to read.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On 28 January 2013 23:26, Dirk Hohndel <dirk@hohndel.org> wrote:
>
> Just pushed out Linus' Gtk3 readiness changes plus my change that allows
> the user to not only type in GPS coordinates but also use a map widget
> to pick the dive site.
>
> There were a few very odd Gtk things going on - when I opened the map
> widget from the dive info dialog (by clicking the button), the widget
> would be completely unresponsive. No panning, no zooming, no
> right-click, nothing.
>
> Opening an equipent widget and immideately closing it again suddenly
> made the map widget responsive. WTF?
>
> I worked around this by doing an explicit grab in the map widget, but
> that seems like a hack and just to work around the underlying issue.
>
> If anyone can figure this out, patches welcome.
>
> The other shortcomings (besides the uglyness of the UI) are that it may
> be non-obvious to the user that it takes a right click to get a menu
> item that allows you to "mark location here" - I'm sure there's a more
> intuitive way to do this, but since left click is used for panning, this
> was the best idea I could come up with...
>
> Please test - I wouldn't be surprised if there are a few bugs still
> hidden in this code.
>
here an fix to make this work on win32 and also solve a potential issue of type:
(subsurface.bin:19441): Gtk-CRITICAL **: IA__gtk_entry_set_text:
assertion `GTK_IS_ENTRY (entry)' failed
my commit message is explicit on the reasons:
------------------------
When called from the "dive edit" dialog the, map windows seems
inactive on Windows. It cannot accept focus and is also behind all
other application windows.
There are a couple of important new calls in gps.c:show_map():
gtk_window_set_transient_for(GTK_WINDOW(*window), GTK_WINDOW(main_window));
(^ docs say gtk "may" call this one for us, on what condition - not specified)
gtk_window_set_modal(GTK_WINDOW(*window), TRUE);
(^ broken on ubuntu 12.04, but needed on Win32))
Making the window transient for the main window and also modal for
the entire application's window stack (or at least try).
Older versions of gtk+2 and also in the most recently tested
libgtk2.0-0 2.24.10-0ubuntu6, seem not to recognize the significance
of gtk_window_set_modal() and the call does not work as expected.
This forces us to check if the dialog from which the call originated
exists, since its possible to close it _while_ the map widget is active.
More specifically, we check in info.c if the location_update.entry pointer
was set to NULL before performing actions with in the update_gps_entry()
callback.
------------------------
also removed the gtk_window_present() call as it seemed redundant post
these changes (?).
-------
on a side note:
looks like i'm above 100 commits...
cheers everyone <has a sip of some late beer> :0 ~ c|_|
lubomir
--
From fe9967c7ad2ec3b93ad336c2c6bed492a5ad0d8b Mon Sep 17 00:00:00 2001
From: "Lubomir I. Ivanov" <neolit123@gmail.com>
Date: Tue, 29 Jan 2013 00:24:21 +0200
Subject: [PATCH] Fix a "stacking" issue with the map-window on Windows
When called from the "dive edit" dialog the, map windows seems
inactive on Windows. It cannot accept focus and is also behind all
other application windows.
There are a couple of important new calls in gps.c:show_map():
gtk_window_set_transient_for(GTK_WINDOW(*window), GTK_WINDOW(main_window));
(^ docs say gtk "may" call this one for us, on what condition - not specified)
gtk_window_set_modal(GTK_WINDOW(*window), TRUE);
(^ broken on ubuntu 12.04, but needed on Win32))
Making the window transient for the main window and also modal for
the entire application's window stack (or at least try).
Older versions of gtk+2 and also in the most recently tested
libgtk2.0-0 2.24.10-0ubuntu6, seem not to recognize the significance
of gtk_window_set_modal() and the call does not work as expected.
This forces us to check if the dialog from which the call originated
exists, since its possible to close it _while_ the map widget is active.
More specifically, we check in info.c if the location_update.entry pointer
was set to NULL before performing actions with in the update_gps_entry()
callback.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The location map picker introduced in commit 801a61e7e0f2 ("Pick GPS
coordinates of dive location via map widget") failed to add the necessary
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This cleans up our handling of combo boxes and all the duplicated
completion logic, and simplifies the code.
In particular, we get rid of the deprecated GtkComboBoxEntry. While it
made some things easier, it made other things harder. Just using
GtkComboBox and setting that up correctly ends up being simpler, and
also makes the logic work with gtk-3.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I have some concerns about the way this is implemented - especially the
use of gtk_grab_add to make the map widget work has me worried. But it
seems to work and survived some test cases that I threw at it.
The GtkButton with the Pixmap looks a little off on my screen, but this
way it was easy to implement. Feel free to come up with a better design.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm sure there are better ways to do this, but this appears to grok most
rational formats I was able to find. NSEW or positive/negative numbers.
Decimal degrees (WGS84) or degrees and decimal minutes (that's what most
GPSs seem to provide). I'm sure there are still corner cases that confuse
it, but it seemed reasonably robust in testing.
I don't really love the ';' as separator but that solves the obvious
problem with locales that use a decimal comma.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That's much more intuitive to remove GPS data from a dive than having to
type in 0,0 as coordinates.
With this change we also skip leading whitespace for WGS84 coordinates.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This implementation gives the user the ability to add GPS coordinates to
the dive location. It works as expected in multi-dive edit scenarios. It
has two major flaws:
- it only support WGS84 style coordinates - it should instead be
intelligent enough to parse the common formats, at least using NSEW
instead of sign and understanding minutes and seconds instead of decimal
degrees
- but in reality, it really needs to support a map picker
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This moves the fields 'duration', 'surfacetime', 'maxdepth',
'meandepth', 'airtemp', 'watertemp', 'salinity' and 'surface_pressure'
to the per-divecomputer data structure. They are filled in by the dive
computer, and normally not edited.
NOTE! All actual *use* of this data was then changed from dive->field to
dive->dc.field programmatically with a shell-script and sed, and the
result then edited for details. So while the XML save and restore code
has been updated, all the displaying etc will currently always just show
the first dive computer entry.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and rename the badly named 'output_units/input_units' variables.
We used to have this confusing thing where we had two different units
(input vs output) that *look* like they are mirror images, but in fact
"output_units" was the user units, and "input_units" are the XML parsing
units.
So this renames them to be clearer. "output_units" is now just "units"
(it's the units a user would ever see), and "input_units" is now
"xml_parsing_units" and set by the XML file parsers to reflect the units
of the parsed file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Stupid Gtk. Seriously. So in order to get a notification if the user
selects the drop down for the gas with the mouse I need to connect to the
"changed" signal for the combobox. But that also fires whenever the user
types something into the GtkEntry. Which means we once again get called
for all kinds of silly partial names.
Instead we want to handle the manual entry in the "focus-out" callback
(the user has hit tab or something else to move away from the GtkEntry -
let's assume that this is the text he wants us to use) and only respond to
the changed signal on the combobox if the user selected something from the
dropdown.
The easiest way to do that (I think) is to check the text with the strings
stored in the model. If this indeed matches a string stored in the model
then most likely this is something the user selected from the dropdown.
But more importantly if it isn't in the model, then we KNOW that this is
just a partial string that was typed in. And we can ignore that one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Once again Gtk does everything it can to make our lives miserable. It
requires major hackery to be able to add new gases to the drop down lists
"on the fly". Right now this only works if you edit the gas and then use
Tab to move to the next field.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This can cause some fun unintended side effects - especially when the dive
is part of a trip and the new date/time moves this into a different trip.
Instead, trips get split and the overall result is consistent, but a bit
unexpected.
But since this is designed to help people right after a dive import in
case the clock on the dive computer was wrong, my guess is this won't ever
be a problem for actual users.
Fixes ticket 18
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now we can simply remember the state of all the preferences at the
beginning of preferences_dialog() and restore them if the user presses
'Cancel'.
Fixes#21
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Lubomir's commit aec904b612 broke the Add
Dive menu item: The Edit Dive dialogue didn't show up after the initial
dialogue.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Turns out we had a data field for visibility as a length unit - but never
used it. I can never guess how much visibility we actually had on a dive -
but I think most everyone can assign a rating between abysmal (zero stars,
"I couldn't read my dive computer even right in front of my mask" - trust
me, I had some of those dives) to amazing ("five stars, I could see farther
than I though possible" - and I had one or two of those, too). So I
changed this to an integer and am re-using the star infrastructure we have
for the overall dive rating.
When displaying this I was dismayed that we are running out of space in
the "Dive Notes" notbook. So I moved this to the "Dive Info" notebook.
This is not consistent and not logical. I think we need to revisit the
notebooks and think about what we want to display where.
While adding the infrastructure to manually enter the visibility I went
ahead and added the ability to manually enter the air temperature as well
(that was one of the things missing in the previous commit).
Fixes#7
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
info.c
- Removed the additional pop-up menu entry "Delete"
- Removed the delete_dive_info() function, which created
the yes/no dialog.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
1) info.c: always check for "amount_selected > 0" before calling
edit_multi_dive_info().
2) populate_popup_cb() should only add the "Edit" and "Delete"
items if there are dives are selected
3) in info_menu_delete_cb() we clear the selection, therefore
we need to set "amount_selected" to 0.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
info.c: extended_dive_info_widget() was still using the
precompiler macros instead of the 'star_strings' buffer,
which may end up being modified if the unicode stars are
not supported on a certain OS (UTF8_FONT_WITH_STARS).
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The buttons didn't actually do anything when clicked, but this still
was inconsistent behavior.
Reported-by: Pierre-Yves Chibon <pingou@pingoured.fr>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
info.c:show_dive_info() uses buffers of 80 char, which might not be enough
for all unicode strings to fit. The function snprintf() can be used to
truncate a string to the maximum buffer length, however this should
not be used with unicode strings, since it can split the bytes of a
wide char, causing some corruption.
Instead of a fixed buffer we now allocate/free memory for the title text and
attempt to more safely truncate user entered text by using g_utf8_strlen()
and g_utf8_strncpy(). Long unicode filenames still remain a responsibility
of the user, but they should be now safe as well. On the other hand the string
formed by the function divename() and the variable maxlen should be
monitored by developers to accommodate all translations.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Example:
For some strings such as the "Trip title" the buffer of 60 bytes was not
enought for certain languages.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like a massive commit mainly because of the line number changes
in the .po files. That sadly hides what really happened here:
- the places where we manually build dates have now been localized
- the one place where we did the English "calculated plural" has been
modified so that it now can be correctly translated (in English this
just adds an 's' to the noun if the number is != 1 - in other languages
this tends to be much more complicated)
I then updated the two German translations to take advantage of the new
constructs. And while I was at it, I changed the translation Trip->Gruppe
to Trip->Reise as that seemed much more appropriate.
I also fixed another error in the German translation where I translated
"dive time" as "Startzeit" - but in the context it was "Dauer".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing code passed a localized copy of a text buffer initialized by
a static string to a function that ended up wanting to modify the buffer.
Unsurprisingly, that doesn't work. This commit restructures the code so
that we initialize the buffer at run time with a localized version of the
default string and then just pass the buffer around.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the first step - convert the string literals, try to catch
all the places where this isn't possible and the program needs to convert
string constants at runtime (those are the N_ macros).
Add a very rough first German localization so I can at least test what I
have done. Seriously, I have never used a localized OS, so I am certain
that I have many of the 'standard' translations wrong. Someone please take
over :-)
Major issues with this:
- right now it hardcodes the search path for the message catalog to be
./locale - that's of course bogus, but it works well while doing initial
testing. Once the tooling support is there we just should use the OS
default.
- even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets
can't seem to agree) I went with UTF-8 as that is what Gtk appears to
want to use internally. ISO-8859-15 encoded .mo files create funny
looking artefacts instead of Umlaute.
- no support at all in the Makefile - I was hoping someone with more
experience in how to best set this up would contribute a good set of
Makefile rules - likely this will help fix the first issue in that it
will also install the .mo file(s) in the correct place(s)
For now simply run
msgfmt -c -o subsurface.mo deutsch.po
to create the subsurface.mo file and then move it to
./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo
If you make changes to the sources and need to add new strings to be
translated, this is what seems to work (again, should be tooled through
the Makefile):
xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c
msgmerge -s -U po/deutsch.po subsurface-new.pot
If you do this PLEASE do one commit that just has the new msgid as
changes in line numbers create a TON of diff-noise. Do changes to
translations in a SEPARATE commit.
- no testing at all on Windows or Mac
It builds on Windows :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Looks like a GtkEntryCompletion object created with
gtk_entry_completion_new() should be unreferenced after usage
(e.g. post gtk_entry_set_completion())
In info.c:get_combo_box_entry_text(), moved the free(..) line outside,
so that we can free regardless.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Debian and Ubuntu's distributed Gtk decide to make the window
tiny (completely hiding the Notes section). To prevent that we "put"
a default size of 400x300px to the window, which is proportionally OK
compared to the main window's default size.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "cylinders_equal()/copy_cylinders()" functions were buggered, and
only checked (and copied) the cylinder type. That was on purpose, since
you do want to be able to change the type of a cylinder without changing
the gasmix of the cylinder.
HOWEVER, the reverse is also true: you may want to change the gasmix of
a cylinder without changing the type.
So it's not that the type of the cylinder is special - it's that the
type and the gasmix should be considered separately.
Do that properly for the equipment editing case.
Reported-by: Ďoďo <dodo.sk@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge the dive trip rewrite by Dirk Hohndel.
This just merges the dive trip changes with the timestamp handling
changes. There were multiple small data conflicts, along with some
newly added 'time_t' cases in the dive trip handling that needed to be
converted to 'timestamp_t' along the way.
* 'divetrip-rewrite' of git://github.com/torvalds/subsurface:
Convert FIND_TRIP into function
Partial rewrite of the dive trip code
Check if trip is NULL before calling DIVE_TRIP
I did a global search-and-replace to make all "time_t" users use the
internal subsurface 64-bit "timestamp_t" type instead, but we have one
case that still uses the system time functions: the use of "localtime()"
in the dive_time_widget().
Everywhere else we always just use UTC for all our time handling, and we
don't really ever care about the local timezone etc. However, for the
dive time widget, we initialize the calendar widget to the current time,
which obviously does want to take the local timezone into account, so
there we end up using the whole system time handling code.
So that one should continue to use time_t, even if it might have the
year-2038 problem. We also don't care about the fact that it's not
thread-safe, since this is just initializing the widget which definitely
doesn't happen threaded.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This introduces a new data structure for dive trips - reuseing the struct
dive just got way too messy.
The dive_trip_t datastructure now allows the code to remember if the trip
was auto generated or if its time stamp changed when dives where added to
the trip during auto generation.
The algorithm also distinguishes between dives that were intentionally
added to a trip (either in an XML file or by adding them to trip in the
UI) and dives that were added to trips via autogen. Saving dives that were
added to trips via autogen makes that assignment "intentional".
With this partial rewrite several of the oddities of the old code should
be resolved - especially turning autogen on and off again should get the
divelist back to the previous stage.
Also, when dives are merged during file open or import we now try to pick
the correct tripflag (instead of just ignoring the tripflag completely and
resetting it to TF_NONE by mistake).
Finally, the dive trip debugging code got more verbose and is trying
harder to detect issues at the earliest time possible.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the time type unambiguous, and we can use G_TYPE_INT64 for it
in the divelist too.
It also implements a portable (and thread-safe) "utc_mkdate()" function
that acts kind of like gmtime_r(), but using the 64-bit timestamp_t. It
matches our original "utc_mktime()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Related to subsurface_default_filename() and g_path_get_basename().
Against 3835faa8fb.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
By now the default file code seems quite matured, so in preparation for
2.0 we'll bring it back into master.
I made a few small clean-ups during the merge, but the merge itself is
very much straight forward.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems to make sense since we have a pretty strong concept of the "active
file" that we are working on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Calling edit from the context menu creates a combined editing widget that
contains both dive info and equipment. When editing cylinders or
weightsystems from that widget and confirming those edits with OK those
changes were already committed to the current_dive - regardless on which
dive the user clicked. Worse, even when the user clicked Cancel in the
edit widget, any changes to the equipment stayed in effect.
This had especially confusing consequences when editing multiple dives.
As a workaround this commit adds a global edit_dive variable. This fake
dive is edited by the secondary editing widgets and if the user accepts
changes with OK then they are copied over to the current dive (or all
selected dives in multi dive editing mode).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
