Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 10:45 AM, Dirk Hohndel <dirk at hohndel.org> wrote:

> 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 :-(
>

It's not supposed to work the way I expected or the way it does?


>
> > 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.
>

It looked as if that patch may have fixed a bug while adding a dive but
created one while editing a dive. I tested but the edit-dive problem was
elsewhere and I couldn't see a difference in how add-dive worked so I'm not
sure what bug it's supposed to have fixed. I don't think that's important
right now though.


>
> > 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.
>

I've looked at the code so I can write a little more concisely about it.

1 and 2. When adding or editing a dive dive double clicking on the globe
should add coordinates to the Coordinates field and place a marker on the
globe so the user can see that he selected appropriate coordinates *before
saving*. Neither happens, right now the action has no effect on the dive.

I've been able to make changes so the ui.coordinates field is updated but
placing flags on the globe is more challenging. Since the edited location
name and coordinates only exist in the ui.location and ui.coordinates
variables the globe::repopulateLabels() function can't place a flag on the
globe, repopulateLabels() uses the dive list for coordinates and labels.
Adding code so it also checks isEditing() and places a flag based on the
edited fields would add that functionality.

I had assumed a list associating location names and coordinates was kept
which is why I wrote "associate the location [i.e. coordinates] with the
location name."


> > 3. User is not editing a dive. Associate the location with the recorded
> > location name of the dive.
>

Circumstance 3 works as expected.


> 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
>



-- 
John Van Ostrand
At large on sabbatical
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141031/a105f3aa/attachment-0001.html>