Persist decks

[kernelkind]

on top of #452

[jb55]

can you rebase and squash this into relevant commits ? it's becoming too difficult to review

[kernelkind]

can you rebase and squash this into relevant commits ? it's becoming too difficult to review

yes

[jb55]

might need a rebase instead of merge. also looks like you merged the wrong master

[jb55]

this rebase might be tricky... may need to squash a bunch of stuff first on the original base branch since there are so many edit commits

[jb55]

yeah this is pretty brutal. I will try to fix

[jb55]

doesn't merge cleanly @kernelkind

[jb55]

squashed and rebased at:

persist-decks

but it seems to nuke my columns:

[kernelkind]

but it seems to nuke my columns

Nuke columns generated from master? Or from columns generated in persist_decks? persist_decks uses a different serialization/deserialization method than master

[jb55]

Nuke columns generated from master? Or from columns generated in persist_decks? persist_decks uses a different serialization/deserialization method than master

we have notedecks in the wild, we can't nuke people's desk setups

[jb55]

just waiting on the migration step so we can merge

[kernelkind]

Done:

• rebased on master
• separated into small commits
• added new serialization technique that decouples app structure from serialized structure

Left to do:

• columns.json -> decks_cache.json migration

[jb55]

pulled everything I could into master:

69e93b0ebfef introduce decks_cache
35613f2e7496 ConfigureDeck & EditDeck user interfaces
83fe173ba349 appearance fixes
40a96f1df220 decks structs

[kernelkind]

• added metadata: Vec<String> field to SerializableDeck in src/storage/decks.rs in case we need more metadata besides an icon and a name.
• added deserialization for columns.json which won't change when our data structures change
• added logic for migration from old columns serialization to new decks serialization

[jb55]

thanks!