Library .vha structure and format

[cal2195]

The current .vha file structure is a json of the following:

export interface FinalObject {
  hubName: string;      // the name of the hub -- for recently-opened
  ssSize: number;       // screen shot size -- so when you reimport it remembers your preference
  numOfFolders: number; // number of folders
  inputDir: string;     // later may support array of many input directories
  addTags?: string[];    // tags to add
  removeTags?: string[]; // tags to remove
  images: ImageElement[]; // see below
}

export type ImageElement = [string, string, string, string, number, string, number, number];
/*                            0       1       2       3       4       5       6       7
-------------------------------------------------------------------------------------------------------
index   type      description                   more info
-----   ------    -------------------------------------------------------------------------------------
  0     string    partial path to file,    <--- for opening the file, just prepend the `inputDir`
  1     string    full original file name, <--- for opening the file
  2     string    file name cleaned
                  of dots, underscores,
                  and file extension       <--- for searching
  3     string    hash of the file         <--- used for detecting changed files and as a screenshot
                                                identifier
  4     number    duration                 <-- duration of film as number
  5     string    depicting size           <-- e.g. `720`, `1080`, `SD`, `HD`
  6     number    width of screenshot      <-- e.g 124 etc
  7     number    fileSize in megabytes    <-- rounded to nearest MB

*/

Why are ImageElements arrays, rather than objects, so we could do ImageElement.duration?

If it's to save space in the saved file, we could compress the file (which would work very well due to the duplicated values across files eg. object names, input folder, resolution, width) at the cost of slightly less easy manual editing of the file?

Alternatively, using constants like PATH_TO_FILE=0, FILENAME=1 so we can easily index the array would be nice!

Let me know if I'm misunderstanding something! 😄

[whyboris]

I started out the structure out of convenience; resisted making the elements into objects (rather than arrays) because of redundant information that would be stored in the .vha file. Compression would solve that of course. If we use compression, I'd prefer the simplest zip compression so users could unzip, edit, and re-zip if needed.

I like the constants idea - makes the code easier to read than foo[4], but I'm also happy to change the structure to an array of objects. I'm also fine with keeping things as is -- what do you see as the biggest benefit(s) of changing?

The main down side would be no backwards compatibility unless we write a conversion script.

[cal2195]

I agree about using .zip (similar to .jar files). It was this ability that allowed #6 to be solved with a workaround before changing the code! 👍

While it would remove backwards compatibility, we're already giving that up with v2.0.0! And it would have a massive upside - future compatibility! 🚀 As field are named, we can add new ones, and old files just won't have any values for them, which we can account for in the code!

I think this trade off is worth it! 👍

[whyboris]

I do like objects better than idiosyncratically rigidly ordered arrays 😅

I'm happy with a backwards-compatibility-breaking refactor.

[whyboris]

Closed with PR #49 - thank you @cal2195 🙇