More Location Fixes.

[Dirk Hohndel]

On Mon, Jul 13, 2015 at 04:09:09PM -0700, Dirk Hohndel wrote:
> On Mon, Jul 13, 2015 at 02:13:20PM -0700, Linus Torvalds wrote:
> > 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.
> 
> One thing we should do is figure out what the behavior is that we want.
> Very, very crisply.
> 
> Henrik, Davide, I'm looking at you here.
> 
> Tomaz has redone this code three times now. Because the definition of what
> we should be doing is all a bit too much "intuitively you do this" and a
> bit too little of "if (a) then b".
> 
> Having Tomaz work on this is an amazing resource for us. We shouldn't
> waste this by sending him running in circles.
> 
> Linus, I really appreciate that you are thinking this through and are
> explaining in detail what your thoughts are. That's really helpful.
> 
> There are so many scenarios... we should really try to break them down and
> turn this into a decision tree...

OK, putting my money where my mouth is.

1. empty location field
1.1. no GPS data (so that means we had no dive site, I guess)
1.1.1, user types in name, picks one of the completions
1.1.2. user types in name, doesn't pick one of the completions
1.2. GPS data (e.g. from Subsurface web service - dive site with no name)
1.2.1. user types in name, picks one of the completions
1.2.2. user types in name, doesn't pick one of the completions

2. existing text in the location field
2.1. no GPS data
2.1.1, user types in name, picks one of the completions
2.1.2. user types in name, doesn't pick one of the completions
2.2. GPS data
2.2.1. user types in name, picks one of the completions
2.2.2. user types in name, doesn't pick one of the completions

I'm sure I'm missing cases... what other scenarios do we need to consider?

Right, for each of the cases above
a) user clicks accept
b) user clicks cancel

So that's 16 scenarios so far... who can think of more?

/D