On Sun, Jun 28, 2015 at 2:27 PM, Dirk Hohndel <d...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface