Just because we want to update the latest information on the Notes tab
doesn't mean we are done editing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After an edit when the dive is redisplayed we are not copying the data
from current dive back over displayed dive (as the reasonable assumption
is that we just edited the displayed dive and copied the information into
the current dive)- so make sure that after the dive site handling the
displayed dive does in fact have the correct dive site information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While we are editing a dive the displayed dive site may revert back to the
special uuid of 0. This means the user modified the existing site so the
displayed dive site is now different from the dive site referenced in the
current dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we download GPS data from the webservice we can end up with dive
sites that are simply a place holder for the the GPS fix. If we replace
the name of one of those sites we should just delete the site (assuming it
isn't used in another dive, which is unlikely but theoretically possible).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- do not create dive sites unless the user has accepted the changes
- all modification are tracked in the displayed_dive_site
- when the user accepts the changes, the real dive site list (and the
selected dives) are updated according to what is in the
displayed_dive_site
This adds quite verbose debugging messages and disables a section of code
that has a special case for data created by the Subsurface web service.
This code needs some re-thinking and should eventually go away.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When retrying a clean build several libraries failed to build and I
finally tracked this down to the cross build tools not finding their
sysroot.
Also, on my main build server I have an older cmake version and one of the
tools claims to require cmake 3 but I see no actual incompatibility, so
I'm patching out that check.
Hackish? Yes. But it seems to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The way a QCompleter works is that it grabs whatever
data it has in the completerRole and sets it back on
the line edit.
I Bypassed the QCompleter delegate to show something
other than the completerRole (so, for instance, if you
write 'B', you could get 'Blue Hole' as the returned text,
but in fact the QCompleter has the 'B' as internal string
(because of the weird - and wrong way in which we are
dealing with completion - trying to complete for something
that's not inside the model yet).
So I hooked up a signal that will listen to the complete's
index, and if it's the first row() it's surely the special
case - then we bypass QCompleter return string and use
our own.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The user has picked their preferences of which taxonomy data they want to
see. Show them what they asked for.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If both the displayed dive and the dive site which is shown as a potential
completion have a GPS fix, indicate the distance.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Do not overwrite a dive site if the name is the same
as any other dive site, create a new one and duplicate
the information.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we are working on the location management, we want to get a new
dive_site if the dive_site name changed unless there's no dive_site by
that name, then we create it.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Hooked up an eventFilter on the QListView that displays our dive sites so
it would filter the keys enter and space, storing the current dive_site
uuid when that happens.
Also it stores the uuid on clicks.
Now we need to get that information when processing acceptedChanges() and
check if the uuid stored there == displayed_dive_site.uuid and also if
text != displayed_dive_site.name, because if the user didn't click on
anything but only wrote stuff on the LineEdit no dive site would be
selected and so uuid == displayed_dive_site.uuid (wich would mean 'no
changes')
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Don't throw away data unless new data has been received. And don't store
multiple copies of the same category. And most importantly, never write
past the end of the array.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Block the Save button on Android platforms until the scanning
for remote Bluetooth devices is finished.
The reason we do that is because there is a bug on the
Android platform or on the QtBluetooth library which stops the
downloading process and blocks the devices on the Download mode.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On Android, a Bluetooth connection to a service cannot be
established using a port. Therefore we use the uuid of the
Serial Port Profile service to connect to the remote BT
device.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Have just found a .dive file in H&W forum which is not correctly parsed
by libdivecomputer due (I think) to a bug in OSTC3 FW 1.77 (corrected).
If libdc fails to parse a file (whatever is the reason) and the header
hasn't been parsed, strcmp(ptr->key, "Serial") will segfault, so avoid
comparison if there is no ostcdive->dc.extra_data but set the serial
data as we know it from ostctools.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shows the ceiling as stored by Divinglog. (I am not sure if it is
DC reported ceiling, or just a calculated one.)
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Note, that this patch is not tested with real data as I do not have log
that would include heartbeat available.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On some platforms like Android the installed root certificates are rather
inconsistent. Same goes for older Windows machines. Instead of trying to
figure out how to get the user to install the right root certificates
(just kidding) we explicitly recognize our own server certificate and
allow that to override the validity assessment by the OS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It makes sense to hide git URLs from the end user in release builds, but
while developing and testing it's better to get more detailed information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The way we freed things and cleared out the variables potentially left
dangling data behind and could end up calling free on garbage data,
leading to random crashes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just a quick first stab to do this, but it at least allows us to
share some information with the user.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
H&W introduced some changes in dc's data structures with FROG and OSTC3
families (types 0x22 and 0x23 in H&W's terms) that I didn't take into
account as we lacked of .dive files to test.
BTW I previously set the model to "0" as it was not stored in the file
but wasn't relevant for the data parsing in MK2, OSTC and OSTC2N/2C
models.
Thanks to Anton's advice we have got some OSTC3 dives to test, so this
patch takes into account the different data structures for different
families, and try to stablish a model number based on device's serial
number, as libdc does.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- Introduce an exit point to cowardly run away from the file if
something goes wrong (undefined dc family, inconsistent family/model
pair, etc), without crashing subsurface.
- Simplifies (user point of view) and makes translatables the error
messages shown in the status bar.
- Modifies ostc_prepare_data() to emit a return code to manage posible
failures.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Cylinder 0 is stored on the Logbook table along with other dive metadata
(not in Tank table).
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since mapping cylinders requires use of dive ID, we might as well use
the ID to map the profile also.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
