Par2deep and Tkinter adventures
This week I’ve worked on a rewrite of my beloved par2deep tool: a wrapper for the venerable par2 command, but tuned for use on large sets of files which may not stay fixed. By which I mean it’s not only suited for static backups, but also a, say, music collection that is continuously in flux. You add files, remove them, move them, then tweak their tags, remove a type, etc. With par2deep you can keep such a collection protected, in that it will create parity files per file (so you can easily move them with the file if you want to, you don’t have to move whole directories), verify, repair, and so on.
Now, even though the CLI version was pretty usable, one main problem was that when you have large changesets (say, you renamed a thousand files) it was not that easy to in fact check which files that was. I’ve improved the CLI version by printing 500 filenames at a time, if you chose to display them, but what I wanted was a tree-like way of descending into the category that I was interested in (maybe you intentionally changed a few thousand files, but the 1001st file suffers from flipped bits). So, I made a GUI version, as you can see on the github page above. I’d say it’s pretty noob proof, so I hope that my father will be able to use it too now, backup obsessed as he is.
Since this is my first GUI app, I’d like to go on the record saying that Python’s tk and ttk are not at all complementary. The main reason to use both it that ttk has more modern looking widgets. However, the widgets and their options are not identical, even though I couldn’t find any description of that on the Python or ttk docs. ttk’s Scale for instance doesn’t at all show the number which the scale is at, and neither did I get StringVar to work. So, although in the end I made it through, this was centainly not the level of finesse that I’m used to in Python standard libs. Moreover, I want to package the gui as a standalone exe, but that hasn’t worked out so far. Python’s builtin bdist_wininst displays a bug that was reportedly fixed, but not in that very Python 3.5.2 64bit version that I’m using. py2exe and pyinstaller both suffer from shitloads of errors, ranging from DLLs not found to pip only having a version for Python 3.4 while I use 3.5. None of the solutions for these problems worked for me, and for some I havn’t found solutions yet. Concluding: packaging Python is, as most probably already know, still shit in 2016.