Setting location coordinates while editing a dive

John Van Ostrand john at vanostrand.com
Fri Oct 31 08:39:27 PDT 2014


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

> On Fri, Oct 31, 2014 at 02:51:39PM +0100, Davide DB wrote:
> > On Thu, Oct 30, 2014 at 9:22 PM, John Van Ostrand <john at vanostrand.com>
> > wrote:
> >
> > > 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?
> >
> > Good question.
> > Actually I always found the editing/saving process very inconsistent.
> > Why I get "dive is being edited" alert just on the "dive notes" tab but I
> > can change tanks, I can add events on the profile without any alert?
>
> Just to be precise, you cannot modify equipment without triggering the
> "edit mode". But you can add a gas change.
>
> Yes, our handling of edits is extremely inconsistent. It has bugged me for
> a long time.
>
> I absolutely want a way to say "never mind" when editing things. I usually
> need that in the context of edits to the info page, so that's where it got
> implemented. But then there are several other ways to edit things where we
> don't have that.
>
> People have suggested an undo/redo feature but that would be an even more
> complex layer to add.
>
> Today you can make changes in these places (I hope I didn't forget any)
>
> 1) Dive notes tab (date, time, location, divemaster, buddy, tags, notes)
>   (and once you entered edit mode, on a manually added dive, you can
>   change the profile in the profile, but you can only start this process
>   if you actually change some other field first - that's completely
>   broken)
>   Equipment tab (tanks and weights).
>
> The moment you edit things in Dive notes or Equipment tab, this triggers
> "edit mode" and the "save / discard" functionality.
>
> 2) Right click on the profile (changing/adding/removing events, gas
>   changes, order of dive computers, delete dive computer
>
> All of these take immediate effect
>
> 3) Double click on the globe window
>
> Also takes immediate effect
>
> 4) Dive list (mostly changes to trip status, but also delete dives or shift
>   their times)
>
> All of these take immediate effect
>
>
> I think it would be fairly simple to switch to edit mode when making
> changes in the second and third case above. Not sure this can be
> reasonably done in the last one. Or we could do what other software does
> and not have this edit mode. So basically the moment you tab away from a
> field that edit is permanent. Only if you use ESC is an edit reverted.
>
> I'll admit that I'd hate that, so I'd be more inclined to got with adding
> edit mode to 2) and 3) above.
>
> Comments? Preferences


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.

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.
This could include gas changes, events and even changes to the profile.
Manually added dives can be done like this too.

This would have a few benefits

1. We eliminate the "This dive is being edited" indicator and all the code
referencing "isEditing()".
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.

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.
2. Trips would be another undo case.
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)
5. Future changes will create more cases.
6. Edited dives may appear incomplete in the dive list.


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.
2. Determine what actions should accumulate into an atomic undo. (e.g.
per-field undo or entire dive undo.)
2. Create an undo function for each case.
3. Alter edits to directly change dive_list.


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

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


More information about the subsurface mailing list