Dev Blog #11: Deletion
One thing Project Davenport makes very complicated (for me anyway) is deletion.
Normally when you delete part of a document it's pretty straightforward. Maybe you have to update the table of contents. Maybe you have to remove a few links.
Because of the way Davenport allows you to organise your work however you like, and notes can live in multiple locations, deleting things gets a little trickier.
For a start, deleting a view of a note in one place doesn't necessarily delete it completely. This is very important for achieving Davenport's minimalist interface: you will often be creating and destroying temporary views of your notes in and around where you're working.
For another, drawers can be nested however you like - even recursively (where A contains B and B contains A) I don't have a specific use-case for that in mind, but I didn't want to be throwing up error messages if someone wanted to do it.
Having a graph of links rather than a tree makes things a lot trickier. You can end up with orphaned cycles of drawers (where A contains B and B contains A but neither of them are in the main document, so they're lost forever!)
Mostly, though, it's just awkward and complicated working through the deletion process, since at any point the last link to a note could disappear and trigger another round of deletions.
Anyway, I think it's working okay now, so I'm going to move on to loading and saving of the document. Saving will be disabled in alpha and beta releases, but it's handy for me to keep testing features and it'll allow me to ship some example documents with the public builds for people to play with.
Normally when you delete part of a document it's pretty straightforward. Maybe you have to update the table of contents. Maybe you have to remove a few links.
Because of the way Davenport allows you to organise your work however you like, and notes can live in multiple locations, deleting things gets a little trickier.
For a start, deleting a view of a note in one place doesn't necessarily delete it completely. This is very important for achieving Davenport's minimalist interface: you will often be creating and destroying temporary views of your notes in and around where you're working.
For another, drawers can be nested however you like - even recursively (where A contains B and B contains A) I don't have a specific use-case for that in mind, but I didn't want to be throwing up error messages if someone wanted to do it.
Having a graph of links rather than a tree makes things a lot trickier. You can end up with orphaned cycles of drawers (where A contains B and B contains A but neither of them are in the main document, so they're lost forever!)
Mostly, though, it's just awkward and complicated working through the deletion process, since at any point the last link to a note could disappear and trigger another round of deletions.
Anyway, I think it's working okay now, so I'm going to move on to loading and saving of the document. Saving will be disabled in alpha and beta releases, but it's handy for me to keep testing features and it'll allow me to ship some example documents with the public builds for people to play with.
Comments
Post a Comment