Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 11:39:27AM -0400, John Van Ostrand wrote:
> 
> Mentioning Undo got me thinking.
> 
> I've been mucking about trying to have globe.cpp both update the editted
> dive *and* show the currently edit's placemark planted on the globe and the
> code is uglier than I like. The idea of "undo" has me thinking of ways to
> streamline that code and remove some oddities in the UI.

He.

> How about this.
> 
> When editing dives we update the dive on each field change, storing the old
> dive in an undo stack. We can accumulate similar consecutive edits to
> reduce the number of undos.

OK. That seems simple. Except when editing multiple dives. Then it gets...
interesting. But I'll go with the idea.

> This could include gas changes, events and even changes to the profile.

Yep, I can see that.

> Manually added dives can be done like this too.

You lost me.

> This would have a few benefits
> 
> 1. We eliminate the "This dive is being edited" indicator and all the code
> referencing "isEditing()".

So this is easy to write in text, but once you deal with the widgets it
gets a little tricky.

Example. You edit something (let's say a tag), your cursor is still in
that field, and then click on a different dive in the dive list. What
happens? You have a drop down open (date, cylinder type) and you change to
a different dive...

What I'm trying to say is that the definition of "I'm editing something"
is very intuitive, until you try to implement the finer details.

> 2. We don't have anything funny to do with placemarks on the map.
> 3. Oops, like accidental double clicks can be backed out.
> 4. Eliminate non-intuitive location/placemark functionality.
> 5. Any for_each_dive will automatically include the dive being edited so UI
> updates like placemarks don't need special cases.

That last one doesn't make sense to me. Can you elaborate.

> There would be a few challenges:
> 
> 1. Single dive edits would be easy but multi-dive edits would more
> complicated. They should be associated as one undo.

OK

> 2. Trips would be another undo case.

What does that mean? You mean trip changes to the divelist?
Uhhh, I want to see the data structure in which you do that :-)

> 3. We'd still have the issue of accidental edits, like an accidental
> double-click on the globe.
> 4. Other cases: Deletes, renumber, photo add/delete, imports, copy and
> paste, undos (i.e. redo)

Several of those would be crazy complicated to keep undo information
about. Renumbers for example. We need to draw the line somewhere.

> 5. Future changes will create more cases.
> 6. Edited dives may appear incomplete in the dive list.

What do you mean here?

> To implement:
> 
> 1. Create a structure for an undo that supports the known cases. Each
> struct is an atomic undo, an array of them is the undo stack. Maybe a
> complementary redo stack can be done too.

OK. See above. I'd like to see the data structures that you have in mind
here.

> 2. Determine what actions should accumulate into an atomic undo. (e.g.
> per-field undo or entire dive undo.)

I'd go with a dive undo. But once again - what does that mean in the
context of multi dive edits?

> 2. Create an undo function for each case.
> 3. Alter edits to directly change dive_list.

Please explain more.

> I've never done something like this before so I'm not sure if there are
> some really sneaky details lurking out of sight.

I promise, there are a MOUNTAIN of snarky details... But I like the basic
idea. Let's start drilling down on some details and see where we get.

All this is post 4.3, though.

/D