Setting location coordinates while editing a dive
Dirk Hohndel
dirk at hohndel.org
Fri Oct 31 07:45:13 PDT 2014
On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote:
> I was getting very frustrated adding a dive location to an existing dive. I
> was expecting to be able to add a location then select the coordinates from
> the globe and have the coordinates updated and the location name and
> coordinates associated. Neither happens. The flag is planted without text
> and the flag disappears when I save.
That's not how it's supposed to work :-(
> I thought that commit 9ead871d6456f8f19f6f0fe2413513ef4449253d was the
> culprit except reverting it seemingly made no difference.
> (qt-ui/globe.cpp:135 is the effective area of that commit.)
>
> So I added a dive to see what functionality that commit was supposed to
> correct. By double clicking, the coordinates are associated with the
> location of the highlighted dive in the dive list. I can see why that's bad.
>
> Then restoring the commit gave me the same add-dive bug, odd but I'll
> forget about that right now.
You lost me.
> So I'm looking for ideas on proper behaviour. There are several
> circumstances I can think of:
>
> 1. User is adding a dive.. Associate the location with the edit location
> name of the dive.
> 2. User is editing an existing dive. Associate the location with the edit
> location name of the dive.
I don't know what you mean by "edit location name of the dive" in both of
these cases.
> 3. User is not editing a dive. Associate the location with the recorded
> location name of the dive.
Yep.
> The problem arises that if the user changes the location while editing, or
> cancels the edit that needs to change the location-coordinate mapping.
Sorry, your language is just too confusing for me. There are three things
that we need to treat separately:
- location name
- coordinates
- flag placement on the globe
Can you rephrase your three cases and your issue using these terms? Then
we can determine which scenario isn't working right and hopefully fix
it...
> So, do we track that in the edit session and update it on a name change or
> revert it on cancel?
>
> Or do we inform the user, on a double click, that they need to save first?
So this is the one part I did understand. And I responded to THAT in my
previous email.
/D
More information about the subsurface
mailing list