This page provides post-release updates on the four main application programs available on this page. While each program comes with a README.txt file that describes known issues and workarounds at publication, new items are bound to arise over time in any nontrivial software. This page documents issues uncovered after the latest major revisions of the apps were released on June 15, 2017, and not mentioned in READMEs. Watch this page for new updates and minor release announcements to appear over time.
The Mac app packages of the Frigcal and PyMailGUI programs were rereleased on August 14, 2017, to address a rare output error that likely stems from an issue in the Mac's app-launcher system. Users of prior releases of the Mac app versions of Frigcal and PyMailGUI are encouraged to fetch and install the new versions; see your program's main README file for upgrade pointers. The source-code packages of these two programs were also rereleased with the fix's code, but just as examples for developers; the error occurs only when these two programs are run as Mac apps—not when they are run as source code on Macs, and never on other platforms. No other program packages were updated.
The complete description of the fix applied to Frigcal and PyMailGUI apps is off-page here, because it is mostly of interest to developers. In short, the main GUI in these two programs runs as a child process spawned by a launcher GUI. Likely due to a misfeature or bug in the Mac's app-launching system, it was not impossible that printed console output generated by these apps' main GUIs could eventually trigger a broken-pipe exception after the launcher GUI exited. Though rare, generally harmless, and an issue in Mac apps only, these failures would manifest as GUI popup error messages naming "Broken Pipe" as cause. The only observed consequence to date was the need to rerun a calendar save operation once in Frigcal.
On some Mac OS X systems, and on Windows 7, 8, and 10, you may get a warning when first trying to use this site's applications, because of defaults regarding unverified sources. You can safely ignore these, but may have to approve a program the first time you use it; see the warning popup for more details. On Macs, for example, Open in the 2-finger-press or control-click menu approves a program quickly and permanently (and may be faster than the security-preferences screen).
This inconvenience is regrettable, but this site's proprietor is an independent developer who does not work for Apple or Microsoft, and has no interest in the supplication inherent in program registration. Windows 10 S, unfortunately, is right out.
On Windows, you should generally avoid saving unzipped exe folders in "C:\Program Files" because neither you nor programs may have permission to save files there. The current program READMEs suggest this location as one possibility, but this can lead to issues. For instance, using that folder can complicate config-file edits (you may need to run editors as administrator), and can even prevent the Frigcal launcher from closing (it won't find a sentinel file because one cannot be written in its install folder). To avoid such issues, save your unzipped exe folders to your Desktop or elsewhere instead.
On Mac OS X, the apps have not been tested or built with Homebrew Python3 and Tk 8.6 (a leading alternative version) because the Homebrew install is currently broken—Python and Tk build correctly, but crash immediately with an "Abort trap: 6." This is a widespread issue that impacts both app builds and source-code use, and makes it difficult to explore possible fixes for Tk 8.5 Mac issues (e.g., Dock zombies and scroll speed). Given the requirements of a manual build, this effectively puts further research on hold.
You can read others' reports about this issue here and here. The latter includes a curt refusal to fix from the project, delegating the job to impacted users. No, really. It's not clear where this bug lies, but projects that publish a product clearly have some responsibility for that product. That is: broken + rude = punt! Hopefully, python.org's Mac Python3 will support Tk 8.6 soon.
Update: as of August 7, it appears that this critical Homebrew Tk 8.6 bug may have been fixed, per later posts on the Github thread. Apparently, an early release of the next version of Tk was required. This is good news if true (and the Mac apps here may be revisited soon), but the outright crash on startup doesn't exactly instill confidence in Homebrew and/or its Tk on Macs going forward. To be fair, though, the Mac's rich user interface is stateful enough to pose challenges to any GUI toolkit.
A technical note for PyEdit users only: as documented in PyEdit's UserGuide.html and textConfig.py, its auto-save feature always writes text with unsaved changes to files using the general UTF-8 Unicode encoding scheme. This is necessary, because there may be no known encoding (e.g., the text may not yet have been saved to a file), and a known encoding may fail (e.g., Unicode symbols may be inserted into the text of a file originally opened as ASCII, precluding ASCII encoding on saves).
This UTF-8 policy may cause issues, however, for HTML files that declare a different encoding explicitly using <meta> tags. If you must recover such a file from the auto-saves folder, you can either change its <meta> tag to declare UTF-8, or convert its text back to the original encoding. For the latter, you can easily restore the original encoding by:
Naturally, this assumes your text is still compatible with the encoding you enter (else, PyEdit will generally fall back on UTF-8 again), and be sure to use "Save As" ("Save" silently uses the encoding provided on "Open" if the text came from a file). This issue is both rare and subtle, but unavoidable in files with explicit and usage-specific encoding declarations that may diverge from actual content. For more encoding-conversion options, see "savesUseKnownEncoding" in textConfig.py, and the command-line conversion utility script unicodemod.
As mentioned in the main README files of all 4 main apps, the current releases of the Mac apps can leave zombie entries for closed windows in their Dock menus due to a bug in the underlying Tk 8.5 GUI library used. This remains a to-be-fixed item, pending adoption of a new Tk version (see above).
Fortunately, it turns out that there is a standard and easy way to see the apps' truly-active windows anyhow: simply use a 3-finger downswipe on the trackpad (or its control+downarrow keyboard equivalent) to activate the "App Exposé" view of active app windows. This gesture can be performed on any of the app's windows, or on its Dock icon. When run on the Dock icon, this is no more difficult than opening the Dock menu with a 2-finger click, and yields an arguably-better and full-screen display that does not include any zombie entries.
This is a standard Mac feature, but may be unknown to some users, and is mentioned only in passing in the apps' READMEs. You may need to enable it once in System Preferences by clicking the App Exposé checkmark. Once enabled, though, this provides a simple way to view an app's open windows, and is immune to Tk 8.5 zombies.
Similar to the Windows exes note above: one user has reported that the Frigcal Mac app can fail if copied to and run from Desktop on Mac OS X Sierra, because the app does not have permission to write files (Frigcal needs to create an initial calendar file on first run, and a sentinel file on each run). This couldn't be recreated on an El Capitan machine, may be user-specific, and is outside the apps' scope. If your apps have similar problems on your Desktop, though, copy them to your /Applications folder instead; this has the added advantage of adding the app to Launchpad for quick access.