febcbd6325e: Add the ability to edit the date/time of a dive

Lubomir I. Ivanov neolit123 at gmail.com
Fri Dec 14 14:28:33 PST 2012


+ some questions about auto-grouping.

since now it is possible edit the timestamp of a dive, there might be
certain conditions that trigger undefined behaviour.
this is mainly because trips in the GTK list are retrieved by
timestamp, but also that trips normally receive the earliest timestamp
when dives are added.
perhaps a second look is needed here to clear all possible corner cases.

i'm far for understanding exactly how everything about merging and
auto-grouping works..
...also i never understood why are there two places where
auto-grouping can be enabled - one in the preferences and one in the
menu.
i wonder which one has priority and isn't that confusing to the user?

1) is it normal to edit the timestamp of a dive to a very early date
e.g. year 2003, press OK and then the dive remains in the same trip
which has a trip date of 2011?
shouldn't the trip timestamp update as well, always pointing to the
earliest dive?

2) shouldn't one of the auto-group options be removed?

3) here is a patch the commit message of which is:

[PATCH] Change the assert when merging trips to a branch

divelistc:merge_trips_cb():
The present assertion can fail, if the user has two dives that were
previously edited to have the same timestamp (febcbd6325e42),
but then each dive is added to his own trip that also receives
the same timestamp.

Instead of terminating the program, perhaps it's sufficient
to simply check and only move dives from one trip to another
if the trips are indeed different.

If the trips are the same fill_dive_list() seems to merge the two
trips regardless.

---
not sure if what i'm talking about makes total sense.


lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Change-the-assert-when-merging-trips-to-a-branch.patch
Type: application/octet-stream
Size: 1434 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20121215/bd81084e/attachment.obj>


More information about the subsurface mailing list