TextSweep 4.0

I've released version 4.0 of TextSweep, my search-and-replace tool for macOS and Windows.

The big feature in this release is a new scripting interface, for both Mac and Windows. The scripting interface makes it possible to drive TextSweep from other programs. While the specific nature of TextSweep does not require it to return data to other programs, it can still be called as a helper tool from other applications that need search and replace functionality.

As with my other apps, Mac scripting support is offered for AppleScript through my aem library. For Windows, after looking at several different API's for inter-application communication, I chose Dynamic Data Exchange (DDE).

The selection of DDE is not a common one these days, so I wanted to offer a bit of explanation. Like Apple Events on macOS (the underlying mechanism for AppleScript) and the Component Object Model (COM) on Windows, DDE provides a mechanism for communicating data and executing code across applications. DDE is a very old technology on Windows, dating back to Windows 2.0, and is relatively simple compared to the much more powerful COM. In this case, however, simplicity is a virtue--DDE is easy to implement, is supported natively on Windows by Tcl, and can be exposed without issue from other programming languages that incorporate a Tcl/Tk GUI. An excellent extension library, TWAPI, supports COM and greatly simplifies the process of setting up a COM interface--but it is still overkill for my needs.

As always, TextSweep is a free upgrade for registered users.

[/software] permanent link

Tk-Cocoa 2.5

Nearly three years ago I announced a significant overhaul of Tk on the Mac that amounted to a redesign of major portions of the GUI library. The changes were intended to address flaws that had emerged in the initial, whole-cloth migration of Tk from the Carbon to the Cocoa API by Daniel Steffen. At the time I envisioned that this overhaul would put Tk on sound, stable footing going forward, and would require only routine maintenance and the occasional feature enhancement.

Ah, the best-laid plans of developers. Tk on the Mac in fact was NOT in a complete place, and later that summer, Marc Culler, who contributed many of the critical patches for Tk-Cocoa 2.0, and I did some additional major refinements. At that point Marc's contributions were so substantial that he essentially became the co-maintainer of Tk on the Mac, and I added his name to the author list.

Over the past six months, we have gone through an additional heavy round of development on Tk, to the point where I consider this yet another major iteration of the toolkit and not just an incremental set of updates. Should this round be called, informally at least, Tk-Cocoa 2.5? I think so.

This round of development was led by Christian Gollwitzer, who implemented some long-broken functionality in file dialogs; Marc Culler, who fixed some major crashing bugs on macOS 10.13 and implemented several major, low-level improvements to drawing and image code; and Francois Vogel, who worked closely with Marc on the drawing code specifically with the text widget and who has undertaken an ongoing cleanup of the Tk test suite on macOS.

Here's a quick overview:

While I did most of the early heavy lifting on updating Tk-Cocoa and was later joined by Marc, in this round I contributed far less code. Marc has done most of the substantial work, with Christian making a major contribution with the file dialogs, and Francois has provided ongoing consulting on integrating these changes into other aspects of Tk. It's great to have more developers working on Tk on the Mac these days; it has allowed us to make infinitely faster progress on fixing bugs. It also adds far more expertise to specific problems; Marc and Francois have expertise in certain areas that I've never been able to master, and Christian's work would have taken me some time to equal. I'm grateful for their efforts.

Right now this work can be downloaded from the core-8-6-branch of Tk at its core development site, and it will soon make its way into the next stable point release. Keep an eye out for it, and give it a try.

[/software] permanent link

PortAuthority 7.8, Manpower 6.6

I've released updates of PortAuthority and Manpower. Both apps feature under-the-hood enhancements that result in a smoother, more refined UI. They are free updates for registered users.

[/software] permanent link

PortAuthority 7.7

I've released verison 7.7 of PortAuthority, my GUI for the MacPorts software management system for macOS. This release is primarily for stability and refinement on 10.13/High Sierra, which is now the minimum supported OS version. User reports and developer observation of crashes in PortAuthority led to a great deal of bug fixing work in the underlying Tcl/Tk libraries, which is now complete.

As always, this release is free to registered users, and I encourage all users of MacPorts to give it a try. PortAuthority is the oldest, longest-developed GUI for MacPorts. If you want to look at the source code, it is available from https://fossil.codebykevin.com/fossil.cgi/portauthority/timeline under the MIT license.

[/software] permanent link

Stringscan 1.1

I've released version 1.1 of Stringscan, my text search tool for Mac and Windows. This release includes a number of UI enhancements to make using it more intuitive and simple. As always, updates are free to registered users.

[/software] permanent link

Stringscan 1.0

I'm pleased to announce the release of Stringscan 1.0, a text search tool for Mac and Windows. Stringscan offers functionality similar to the Unix "grep" command: it recursively searches files in a directory for a string of text. I wrote it because I wanted a GUI tool that could do more than just retrieve a list of files; Stringscan currently lists files and displays their content in the main window, and eventually I plan to enhance its functionality further.

Stringscan also interesting because it is written in the Ruby programming language. Like my other applications, its UI is based on Tk, but Ruby is somewhat different than the other programming languages I've worked with; it combines the terseness and power of with a cleaner style that is closer to Python. Ruby was once considered a language of great promise for desktop application development, but seems to have lost momentum in that domain in favor of web development. Nonetheless, Ruby is quite useful on the desktop; its standard library and "gem" extension packages provided all the tools I needed to implement a file and text search function.

Regarding deployment, the Mac version of Stringscan was built using ruby2app, the tool I developed a couple of years ago to bundle a standalone Ruby-Tk application on macOS. The Windows version is deployed in a manner similar to my other Windows applications, with a C executable linked to the Ruby libraries.

Stringscan is priced at $29.99 and, as always, upgrades will be free to registered users for life. I encourage you to give it a try if you want a richer tool for searching for text in a directory.

[/software] permanent link

Additional app updates

I've posted updates to all my apps, fixing UI and security bugs on macOS and fixing a security issue on Windows. As always, upgrades are free to registered users.

[/software] permanent link

TextSweep 3.1

I've released version 3.1 of TextSweep, my search and replace tool for OS X and Windows. As with my other recent releases, this version increases security on app updates and includes minor UI refinements. As always, updates are free to registered users.

[/software] permanent link

QuickWho 6.1

I've released version 6.1 of QuickWho, my whois client for macOS and Windows. This release includes UI enhancements and a transition to a more secure update mechanism. As with my other apps, updates are free to registered users.

[/software] permanent link

PortAuthority 7.5, Manpower 6.4

I've released version 7.5 of PortAuthority, my GUI for MacPorts, and version 6.4 of Manpower, my man page viewer, both for OS X.

These releases focus on minor UI updates and the major upgrades to the application update mechanism, switching to a more secure download method.

Both releases are free to registered users, and $29,95 to new users.

[/software] permanent link

FileMorph 2.8

I've released version 2.8 of FileMorph, my file modification app for OS X and Windows. As prevously discussed, the main feature of this release is the new app update mechanism I am introducing.

As with all my apps, this version is a free update for registered users.

[/software] permanent link

Changes in app update mechanism

I'm working on a round of application updates that are focused on (yet another) re-work of their application update mechanism.

This change has been driven by three factors: the recent upgrade of my websites to support encryption via Let's Encrypt; changes in Apple's API's in macOS Sierra to require encryption in web connections, and in how app updates can be installed on the system through a mechanism called App Translocation; and a desire to simplify the code of my app updates mechanism.

Let me address each of these in turn.

Encryption: This one is pretty easy. It just requires the addition of a Tcl library, TLS, to support encrypted web traffic. In addition to including the library, it requires a few lines of Tcl code, and then everything Just Works.

Apple's API's. The encryption part is simple, as discussed above. The "app translocation" API has taken me a bit more time to figure out and test; the only file format that Apple will allow to avoid app translocation (in the name of system security) is a signed disk image, or DMG. Zip files, tar files, and other formats don't get that benefit. (In app translocation, an affect application is copied to a hidden read-only format and then launched, to avoid injection of malicious code in the process; it also means the app cannot be updated or otherwise modified while it is running, which makes updates that Mac users expect impossible.) Using signed disk images instead of zip or tar formats is simple enough, and I've gotten it working after some trial and error.

Dissatisfaction with my code. For years I've tried to emulate the popular Sparkle app update mechanism in my apps. First I tried a basic imitation; then I tried to actually integrate Sparkle into my work; then I tried to use many of Sparkle's mechanisms under the hood and layer my own implementation on top of it; and, now, I'm back to doing a basic imitation. The reason for this is that I've never been able to cleanly integrate Sparkle itself into my work; it integrates perfectly with applications written in Objective-C, but I've never been able to figure out how to call it directly from Tcl, even if there is a C layer between. Later I used Sparkle's XML "appcast" mechanism under the hood, but this added a lot of complexity; Tcl's XML-parsing libraries don't play well with other scripting languages, which meant that I had to write additional code to parse the appcast if the application was written in, say, Perl. Additionally, my Tk-based knockoff of Sparkle's UI was just plain ugly.

So I'm back to a basic Tcl implementation that more or less follows Sparkle's example, using the following steps:

1. Application pings my server to check an app version. In my case this is a simple Tcl file with one line of code: the new app version.
2. App compares the new app version with the installed app version. If it's the same, it presents a native dialog stating so. If there's a new version, it downloads a list of changes from the server stored in a separate Tcl file.
3. If the version is new, it asks the user if they want to install the new version. If the answer is no, the update exits. If the answer is yes, the app downloads the new version in a DMG file, mounts the DMG file, and informs the user the new version is ready for installation.
4. When the user begins installing the new version, the running app moves itself to the trash, copies the new version of the app to the install location, launches the new app, and exits.

This format works pretty identically to Sparkle, at least in its basic moves; it's much simpler to maintain; and it will be portable to another platform, specifically Windows, whereas Sparkle is Mac only. Some Windows-specific code will be necessary to accommodate the differences in Mac and Windows installers, but apart from that, it will be identical.

I'll begin rolling this new update mechanism out in my apps in the near future.

[/software] permanent link