On 1 March 2016 15:35:16 GMT+00:00, Dirk Hohndel <[email protected]> wrote: >Apparently I forgot to post about this yesterday. How odd. > >Anyway, I implemented Thomas' idea of a timed undo dialog for the >delete >action. Please give it some testing. I tried all the scenarios I could >think of (including deleting the last dive in a trip and then undoing >that >delete). The undo stack has depth ONE, so only the last delete can be >undone and only within 3 seconds of doing so - basically if you do >nothing, the app does what you told it to do; it deletes the dive. And >the >UI isn't blocked by the option to undo, you can just keep going. > >I like this user interaction (great work, Thomas), but I want to make >sure >I didn't miss anything in the way I implemented it. > >/D >_______________________________________________ >subsurface mailing list >[email protected] >http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
I just tried this, and must say that it works well. I couldn't create any scenarios that caused any issues with the delete/undo. I did find a couple of oddities that may have been there for a while though: 1. Open the bottom dive in the dive list, then go to manually add a dive. The new entry dialog appears pefectly normal, but on saving, it produces an /interesting/ effect (for the wary, with large log files, try selecting a dive a few entries in at the start, rather than the bottom of the list!) As a simple fix for this, the app should return to the dive list before going into the edit dialog, or not allow adding a dive when a dive is displayed. 2. When editting a dive, if the time is changed, but not the depth, the profile isn't updated. -- David Tillotson _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
