On Mon, Jun 29, 2015 at 05:09:23PM +0800, Miika Turkia wrote: > >> 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). > > > > So once you have GPS data we will show the tags that you have chosen > > (Country, State, whatever) in the UI. I'm not 100% clear how we should do > > this when "autocompleting" but given the workflow that you and Linus > > describe my guess is that we'd update those tags as well as we see and > > find a awy to make sure that dive sites with identical names but different > > GPS locations are handled in a somewhat sane manner... I can kind of > > envision how this would look... Tomaz will love me for this... > > I have actually never seen these tags to be added. Now I see that I > need to enable it in the prefs...
This part isn't implemented, yet. So enabling doesn't do anything. I was discussing how I think this will work once the implementation is complete. > > So let's say you have three different GPS coordinates for Blue Hole. One > > in Belize, two in Palau that are different anchoring spots. As you type > > "Blue H" your autocompletion shows three lines of Blue Hole. As you use > > cursor up and down to scroll through them the tags above the location > > field change to "Belize" and "Palau", respectively, and the map jumps (not > > flies, that's to slow) to the correct marker - this way you can even tell > > the different anchor points appart even though you just entered the name. > > > > Which other possible workflow am I still missing with this? > > > >> Seems that I get an empty location field on first name edit, and > >> second edit sticks. > > > > Can you explain the steps that got you to the empty location field? > > I tried a few scenarios and can't reproduce that. > > This time I was not able to edit the Location without restarting > subsurface. Following steps: > - Download from DC > - Download from second DC > - Sync GPS > - Try to edit locations So I tried this with two random DCs (both simulated in my case but that shouldn't make a difference for Subsurface) and this works for me. I hate it if I cannot reproduce what goes wrong for people. It makes debugging so much harder. > I guess I will have to try to remember your workflow, so things will > be easier for me :D Well yes, that would of course be the smart thing to do :-) > >> (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 > > > > Hmm. this=0x0 - that would explain the crash when accessing a member of > > this object. But how the heck did you get there? > > > >> #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 > > > > No clue. Obviously this worked for me (and I tried jumping around between > > dive sites, etc). > > Happens to me quite frequently. Once I have working Internet, I'll try > to do full build.sh and see if that helps. If I take this stack trace at face value it really doesn't make much sense. It shouldn't be crashing where it claims to be crashing. It "this" in StackedTile::pixel really was NULL it should crash in the caller when trying to dereference the member function. Thiago, any brilliant insights? /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
