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>
Add a new method in info.c called info_widget_destroy(), which
clears all GtkListStore instances. The method is exposed via
display-gtk.h and called from gtk-gui.c:on_destroy().
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We can't use gps_changed() in the gps_map_callback function, because that
will actually change the GPS data in the dive being edited, which in turn
will then cause us to later (when we *really* want to change it) not match
the master dive data any more, and think we shouldn't edit the dive at
all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The whole "+ 0.5" to round to integers only works for positive values,
and GPS coordinates are signed.
So use the proper "round to int" function (rint()), which does this correctly.
Also, remove the redundant check against the master gps values: we
already checked that if we do have a master dive, the gps values must
match the currently edited dive, so comparing against the master is
entirely redundant.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds watertemp and airtemp to the dive, populates them in fixup and
uses them elsewhere in the code.
WARNING: as a sideeffect we now edit the airtemp in the dive, but we never
display this in the DIve Info notebook (as that always displays the data
from the specific selected divecomputer). This is likely to cause
confusion. It's consistent behavior, but... odd. This brings back the
desire to have a view of "best data available" for a dive, in addition to
the "per divecomputer" view. This would also allow us to consolidate the
different pressure graphs we may be getting from different divecomputers
(consider the case where you dive with multiple air integrated computers
that are connected to different tanks - now we could have one profile with
all the correct tank pressure plots overlayed - and the best available (or
edited) data in the corresponding Dive Info notebook.
This commit also fixes a few remaining accesses to the first divecomputer
that fell through the cracks earlier and does a couple of other related
cleanups.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When starting on this quest to stop using the first divecomputer instead
of data for the whole dive in commit eb73b5a528c8 ("Duration of a dive is
the maximum duration from all divecomputers") I introduced an accessor
function that calculates the dive duration on the fly as the maximum of
the durations in the divecomputers.
Since then Linus and I have added quite a few of the variables back to the
dive data structure and it makes perfect sense to do the same thing for
the duration as well and simply do the calculation once during fixup.
This commit also replaces accesses to the first divecomputer in
likely_same_dive to use the maxdepth and meandepth of the dive (those two
slipped through the cracks in the previous commits, it seems).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Float values have insufficient precision compared to the udeg we usually
store - so we create a special callback function to use from osm-gps-map
and everywhere else use integers.
This patch also increases the decimal places displayed in the GPS text
entry box - this way we can cut and paste the text without loss of
precision.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The fixup_dives() code used to only look at the first divecomputer,
which meant that minimun temperatures etc for the dive would only ever
come from the primary divecomputer.
This splits up the code that walks over the divecomputer into a function
of its own, and iterates over all computers in fixup_dive() calling into
it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
