Save your current tracks list for later edit

[tobycm]

So I don't have to add all the old ones every time I need to update the pack

[bradytheinventor]

Duplicate of #30

[bradytheinventor]

I saw you made a pull request related to this issue, so here are some of my thoughts about adding a save/load feature (in case you find them informative). Please don't feel like I'm expecting anything of you one way or another, I just wanted to explain why I haven't added this as a feature yet and give you some tips if you do decide to implement it!

Adding a new feature is always a delicate balance, because once it's in the app there's an expectation that it will not be removed. Essentially, by adding a feature, the development team is committing to support it for the foreseeable future or even the lifespan of the app. That means the feature has to be easy to maintain as the app grows and changes.

For example: Linux support. Whether or not people use the Linux app, I've committed to making it Linux-compatible and will continue releasing a Linux binary for the foreseeable future. To that end, I've carefully structured the build scripts and written the key steps in Python so I have one cross-platform script to maintain instead of several.

Some features are easy to maintain, like generating packs as a zip file. Others can be more difficult. You've picked saving/loading, which is an especially ambitious (but certainly not impossible!) feature to maintain because of the requirements: a new UI element which must be integrated with the existing (and future) GUI elements, a save file format that can grow and change with the app, and the save/load system itself (which must be backwards-compatible with older save files, and also able to grow and change with the app). None of that is impossible, but it will take some thought and planning to be done well; thought and planning that I haven't had time for yet.

All that said, here are some questions I hope will get you thinking along the same lines as me (or maybe you've already considered these points, in which case what are you listening to me for!):

• Who will maintain the save/load feature if it needs to change? Are you planning to support it, or would it fall to me to maintain the feature? If I'm going to be supporting the feature, will it be written in a way that's easy for me to understand and build upon? (plz add comments thx)

• Is the code easy to maintain and is it future proof? For example, what if the save file format changes and you need to accommodate older save file formatting in addition to the "current" format? Using lots of if-else blocks will quickly become unwieldy, where inheritance or a Factory pattern might be better suited. The rest of the app struggles with poor data abstraction - be the solution, not part of the problem!

• That leads me to: is the save file format future proof? It's not unlikely that new options and settings will be added to the app in future versions. (For example, editing the loot table drop probabilities of individual discs has been requested.) Is the save file format designed with this in mind (such as with a "save file format version number" embedded in the json)? It would be Very Bad™ if a user were not able to load their save file because the format had changed and the app could not detect/load older save files.

Software design takes some thought to get it right the first time; I'm sure there's lots more to consider than these few points. Hopefully you have an understanding of why I haven't implemented a save/load feature myself yet. If you decide to go for it, good luck, keep software design practices and maintainability in mind and you'll do fine.

[tobycm]

Thank you, that was very informative to me. I honestly haven't think about any of these points 😅

I will try my best work on this feature and maintain it and also making the code easy to maintain for future maintainers

Again, thanks man