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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
