This adds a History view of your nbpresent content (e.g. slides and themes, not your notebook), constituting an initial stab at #74.
Here's a shot from the tests:
History goes back to your initial load from the server, the following activities are snapshotted/undoable:
Move/Resize Region
Nudge Region
Load from Server
Slide Layout
New Region
Set ${d.attr.key}
Set ${d.attr.key}
Set ${d.attr.key}
Reordered Slides
${d.title()} Import
Set Slide Theme
Link Cell Part
Unlink Cell Part
Delete region
Add Slide
Remove Slide
There are some situations where a user could create an "unusable" history: the first time a cell's content is used, it is given an UUID. Going back in time will not unset that UUID or otherwise, but this seems like a pretty reasonable thing.
No history is ever culled (until you reload the browser) which might become an issue, as you can create some interesting timelines (which are always sorted by creation time). Often, behavior will be to remove "dead" branches, but in my local testing, I kind of liked being able to store multiple prior heads for looking at different approaches. Not to mention memory-leaky... worst-case scenario would be big images used as backgrounds, etc.
If you end up having to reload your page, then, you'll also lose history... but this seems not unreasonable.
I have also not added any keyboard shortcuts or additional buttons for undo/redo, as ctrl+z seems like a bad thing to take over.
@jbednar: is this starting to answer the mail on some of your concerns?
Coverage remained the same at 85.714% when pulling d88231787add9ffc2ac386db7ea0b7684f56eac7 on history into 6bf2f50b7abd27273dc9e7d469bf1866bafbf5bb on master.
This adds a History view of your nbpresent content (e.g. slides and themes, not your notebook), constituting an initial stab at #74.
Here's a shot from the tests:
History goes back to your initial load from the server, the following activities are snapshotted/undoable:
There are some situations where a user could create an "unusable" history: the first time a cell's content is used, it is given an UUID. Going back in time will not unset that UUID or otherwise, but this seems like a pretty reasonable thing.
No history is ever culled (until you reload the browser) which might become an issue, as you can create some interesting timelines (which are always sorted by creation time). Often, behavior will be to remove "dead" branches, but in my local testing, I kind of liked being able to store multiple prior heads for looking at different approaches. Not to mention memory-leaky... worst-case scenario would be big images used as backgrounds, etc.
If you end up having to reload your page, then, you'll also lose history... but this seems not unreasonable.
I have also not added any keyboard shortcuts or additional buttons for undo/redo, as ctrl+z seems like a bad thing to take over.
@jbednar: is this starting to answer the mail on some of your concerns?