great progress on dive site handling

[Miika Turkia]

On Sun, Jun 28, 2015 at 2:27 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Sun, Jun 28, 2015 at 06:35:25AM +0800, Miika Turkia wrote:
>>
>> I had the site on my log with only a name, no coordinates. Now I dove
>> there again with companion app. Synced the GPS data and then selected
>> the name of the dive site. This replaced all info from the old dive
>> site, overwriting the gps with empty value.
>>
>> I would prefer a merge where we take the values over empty fields, no
>> matter which one is newer.
>
> I hacked the logic to make this work. I think this is totally bogus and
> bad UI design and actually the wrong thing to do, but let's not get
> distracted by little details like this.
>
> With the commit I just pushed the following happens.
>
> IFF you have a dive site that was downloaded from the companion app and
> IFF you either type in a new name or you type in an existing dive site
> name that has no GPS data,
> THEN the GPS data from the downloaded fix will be used and added to the
> new dive site that is created (or the existing dive site that didn't have
> a GPS fix).

This sounds like sane logic to me. However, I do also see your concern
about this if one only records the site name on that field. I still
type the locations like "Indonesia - Lembeh Strait - Hairball" so I am
not going to change a Blue Hole in Belize into a Blue Hole in Egypt
(if there are no previous coordinates for the site).

> This behavior is of course ridiculously stupid and inconsistent with the
> behavior this field usually has. But it solves the problem for people who
> for some weird reason download their GPS information before assigning
> names to their dive sites.
>
> Please test and let me know if this works for you.

Seems that I get an empty location field on first name edit, and
second edit sticks.

>> >> - It would be great if the currently selected divesite was highlighted
>> >> somehow on the map, it is really hard to spot it now when the sites
>> >> are close to each other, maybe the dive map changed or something to
>> >> ensure the correct spot is recognized.
>> >
>> > That has been unchanged for a long time. I'll think about something.
>>
>> Yes, I have suffered from it for years :) Anyway, it is more prominenet
>> when using the companion app and trying to see where the last dive was..
>
> Changes that implement that have been pushed as well. The current dive now
> has a 25% bigger and quite significantly brighter flag.

Just got a crash when trying to test this out.

---8<---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff748dc700 (LWP 25410)]
Marble::StackedTile::pixel (this=0x0, x=36, y=30) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/StackedTile.cpp:85
85        if ( m_depth == 8 ) {
(gdb) bt
#0  Marble::StackedTile::pixel (this=0x0, x=36, y=30) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/StackedTile.cpp:85
#1  0x00007ffff654036c in
Marble::ScanlineTextureMapperContext::pixelValueApprox
(this=0x7fff748dbd50, lon=<optimized out>, lat=<optimized out>,
scanLine=0x240b660, n=<optimized out>)
    at /home/mturkia/source/static/test/marble-source/src/lib/marble/ScanlineTextureMapperContext.cpp:316
#2  0x00007ffff654196d in
Marble::SphericalScanlineTextureMapper::RenderJob::run
(this=<optimized out>) at
/home/mturkia/source/static/test/marble-source/src/lib/marble/SphericalScanlineTextureMapper.cpp:271
#3  0x00007ffff2c25af0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff2c28b0e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff69676aa in start_thread (arg=0x7fff748dc700) at
pthread_create.c:333
#6  0x00007ffff2094eed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
---8<---

miika