More Location Fixes.

[Linus Torvalds]

On Mon, Jul 13, 2015 at 1:17 PM, Tomaz Canabrava <tcanabrava at kde.org> wrote:
> This is the code that does (1)
> please check if I got it right.

I'm not convinced that's right either.

I suspect that if the dive site name matches an old dive site, and we
don't have GPS location, we do want to take the GPS location from the
old one.

And maybe the same is true of things like dive site notes etc.

HOWEVER. It's complicated by things like "maybe we match an old dive
site temporarily", ie we might be in the situation where we have two
old (different) dive sites called "Blue Hole" and "Blue Hole, Belize"
and as we type the dive site in, we first match "Blue Hole", and then
later match "Blue Hole, Belize".

Why does that matter? Because the first match might give us the gps
location for "Blue Hole", and then the second match sees that we now
have GPS location information, and _not_ update this.

We used to have exactly that issue with the old auto-complete of the
dive site name. We ended up having a special flag saying whether the
GPS information was manually edited or automatic. So selecting a dive
site would overwrite the GPS data if it was automatic (ie from a
previous dive site name match), but *not* overwrite it if it was
manually/explicitly added.

And I'm not sure that's the right solution either, but that worked
very well in practice in our old model. You could switch between old
dives sites (and that would switch between their GPS locations too),
but if you *explicitly* set the GPS data, it ended up being sticky.

Maybe the right thing to do is to never take GPS location and notes
from a name match (like your patch seems to do), and simply make that
part of the "dive site management" that doesn't exist yet. That at
least wouldn't overwrite data by mistake, but it does sound like an
extra (and inconvenient) step, so I don't really think that's a good
model either.

                Linus