Improve long-term maintainability by coordinating with Anki devs

Below, except for the first one, it's a bit tricky to figure out which repository to put each of these into. I'm wondering whether maybe we should just use one repo, and keep separate products in separate folders. This would make it easy to handle No. 2 below with a shared code library/module.

1) FlashGrab XML syncing, and especially its LIFT-specific wizard, is clearly a separate project. Not likely that the whole thing will get rolled into Anki. It needs to ship with the LIFT_Words and LIFT_Sentences note types.

1B) Any samples or templates we provide as .lift, .fwbackup, and/or .apkg files would best be stored in the same repo as FlashGrab, The APKG's would use the latest version of LIFT_Words and LIFT_Sentences.

2) FlashGrid is clearly distinct, but I'd love to see it rolled into Anki. We would like to have it ship with the latest version of FlashGrab's note types, but including that is a manual task, since the official .APKG file and self-install code for that is over in the FlashGrab repository.

3) We can and have monkey-patched bugs in Anki (so far just for FlashGrid), but I really hope Anki will pick those up.

There are additional features that could potentially be separate addons as well. Or better, new features built into Anki. For example...

4) The LL dept (and I) would like to provide a mostly-empty deck that can be copied and filled in for various languages. Should we include the following features as part of FlashGrid, or as something separate? (Maybe named FlashFork?) (a) Ability to copy a deck, giving the user the option to also duplicate that deck's note types. (By default, both decks would continue to be tied to a single set, so tweaking the fields or card templates would affect both decks. (b) To do (a), we first need to add the ability to copy a card, which we might as well expose to the user as a feature too. (This is kind of like copying an entry in FLEx, but simpler.) (c) For safety, we'd want File / Import to detect situations in which we should offer deck forking/copying to the user. Specifically, if they are importing that 'empty' deck in order to really study a minority language, they want a new deck; they do not simply want to merge into their old deck from their LL class.

5) It would be nice to streamline certain Anki actions, such as

doing a custom practice session focused on a single card type. (A poor man's version is already built into FlashGrid.)
streamlining a round-trip export/import via .TXT, which only stores note data without IDs and would thus be one cheapo way of implementing most of No. 4 above. (This would work because only import from .APKG does the auto-merging, just like FLEx import--for the same reasons--only attempts to auto-merges from LIFT and not from SFM.)

6) Grabbing and inserting an image/video directly from the device's camera, much like Anki's record button already does for audio, recording directly from the mic.

7) For audio/image/video files being directly recorded, offer to save two files: a small file for Anki, and a full-quality one outside of Anki. For existing media files being copied into Anki, offer to shrink them.

Probable folder structure in the repo if we did a single repo and just three 'products':

flashgrab/  [first product; also includes various XML-processing libraries]
flashgrid/  [second product]
flashdata/
  template/  [third product--a shared deck; contains an 'empty' APKG of a mostly-empty deck with pictures]
  flashmodel/ *  [contain same APKG basically (except minus pictures), plus self-installing code]
bugfixes/ *  [monkey patches that will hopefully go away once Anki incorporates them]
flashfork/ *
mediatools/ *
macrotools/ *

To be included in both flashgrab and flashgrid. Each actually-installed addon would have its own copy of these. I think/hope that that wouldn't create Python namespace conflicts.

sillsdev / flashgrid

Improve long-term maintainability by coordinating with Anki devs #9