Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
Both releases are incremental updates, with slightly better performance and minor bug fixes.
Perhaps the most interesting aspect of these releases is that the source code for each is now posted online, at http://fossil.codebykevin.com, under the MIT license. While these are still commercial programs, the source code may be of use to users who would like to modify the applications for their own systems, or deploy them on a system that is not currently supported. While working with the source code is not something I will support directly, this may still prove of use to some folks, and I'm glad to offer it.Mon, 02 May 2016
I've released version 2.7 of FileMorph, my file modification tool for Mac and Windows.
This release fixes a serious crash on some Windows systems, and also incorporates some minor UI enhancements. If you are in the market for a cost-effective tool for changing file attributes such as their name, modfication date, and more, give this a try. As always, lifetime upgrades are free to registered users.Thu, 07 Apr 2016
In releasing the Python-based QuickWho 6.0 today, for the Windows version I followed the model I used for my Perl-based FileMorph app--I coded a stub executable in C that linked to the Python interpreter and made no effort to wrap everything up in a single "app" executable.
Python has more options for "freezing" or deploying standalone apps than Perl does, but the present state is a bit rough: none of the major libraries for Windows work to my satisfaction. Either they do not support Python 3.5, which has some significant changes over previous versions of Python on Windows, or they lack polish in certain respects in terms of customizing the icon or the version info bundled with the executable. This approach results in a larger distribution than the other approaches, but that's a trade-off I'm willing to make.
The other nice thing about using a C-based executable is that it can be ported to other languages with only minor changes, since all the languages that I use for desktop applications are themselves developed in C, and have a C API. The core of my exe stub does not change; it calls into Windows functions to set the working directory of the program, and requires only minor changes to hook into whatever language I am developing in at that time. This will make future projects on Windows simpler. (For an example, see http://fossil.codebykevin.com/fossil.cgi/quickwho/artifact/f3f87b14df46973c.)
The other thing I am doing with my Windows applications is using a simple installer and uninstaller setup that that includes only minor variations with each application. I use iexpress, a system tool that Microsoft includes with Windows to streamline the installation of software components and libraries. It essentially creates self-extracting archives, that only require a single click before each component is installed where I want. My installer package includes an installer script, an uninstaller script, a zip file of the application package, and a small unzip tool to decompress the archive. There are more complex software installer programs out there, both commercial and open-source, but iexpress is very simple and appeals to my Unix-based background. Developing the installer and uninstaller scripts was a great experience because I learned a great deal about Windows internals, its basic scripting language (batch), and so on.
I've released version 6.0 of QuickWho, my whois client for OS X and, now, Windows. This version features a major under-the-hood rewrite for increased accuracy, and various UI enhancements. If you would like a richer alternative to the command-line whois tool, it's a great product.
I've been away from work here since late last fall, working on other projects, especially my mobile apps. . I anticipate spending more time on desktop projects in the coming months.Fri, 13 Nov 2015
I've released version 2.6 of FileMorph, my file modification app for Mac and Windows. This version focuses mainly on Windows, with a substantially re-worked deployment structure that ensures smooth launching.
Apps written in Perl, FileMorph's main development language, are not easy to deploy on Windows. I prefer to use open-source tools rather than commercial toolkits like PerlApp from ActiveState, so I had deployed the last version using Par/PP, which creates standalone Perl application with all libraries bundled in a single executable file. Based on my research and testing, PAR/pp works fine for simple Perl/Windows applications that don't require a lot of polish.
However, for larger, more complex applications with multiple dependencies and professional-level polish--such as a custom icon, and standard application data such as version information contained in the executable--PAR/pp is seriously broken on Windows. Adding a custom icon and standard application text data is a non-trivial process, requires tools to actually hack the executable, and runs the serious risk of corrupting the executable to the point where it will not run. In my case, I got the executable to run, but at the cost of an extremely long startup time (over a minute) with a blank console popping up while everything loaded. After the application started, it still had issues: the default PAR icon still leaked out in places such as the Windows taskbar. While the app was entirely functional, it seemed rough, unpolished, and unprofessional.
This was unacceptable. I had held off on doing much marketing and promotion of FileMorph on Windows because it offered such a poor user experience out of the box. Something had to change.
After doing some additional research, I found a different approach that offered great promise: a simple stub executable that linked into Perl via its embedding API and did nothing but start the application. (The approach is outlined here: http://perl-node-interface.blogspot.com/2011/03/deploy-perl-application-on-windows.html.) I took interest in this approach because I've used something like it in my experimental ruby2app deployment tool for Ruby apps on OS X. I took the basic sample code for the Perl project, modified it to fit my application structure, and after some trial and error, got things working well. FileMorph now starts right up and, while the Windows download installer is much larger than before (60 megabytes vs. 20 megabytes), that's an acceptable trade-off for an application that runs well out of the box.
I commend this approach to any developer who is working with Perl on Windows; I am very pleased with it. While FileMorph is a commercial application, its source code is available under an open-source license at http://fossil.codebykevin.com/fossil.cgi/filemorph/timeline, so feel free to take a look. (As an aside, I also use a terrific module for deploying the application on the Mac: Mac::QuickBundle.)
And, of course, if you are an end user looking for a handy file modification tool for Windows, FileMorph may just do the trick--feel free to download and play with it. A one-time cost for a license includes free upgrades for life. It's worth your attention.Sun, 11 Oct 2015
After nearly four months since my last blog entry I'm pleased to announce the release of FileMorph 2.4.0. In terms of new features, this version is a minor update except for one thing--it now runs on Windows.
This isn't my first foray into Windows. When I tried it before, I went with an application that doesn't sell much, and I also spent longer porting it to Windows than I did trying to market and sell it--in short, I gave up pretty quickly. In this second go-round, I am planning on sticking with Windows for the long haul, because I need a second large market apart from the Mac outside the Mac App Store.
Of course, developing for Windows is not a simple process, and I had to re-learn several things about the platform; most of the last four months has been spent learning the particulars of Windows, and of re-working my development stack to support Windows. This means adding a lot of Windows details not just to a single app but to the entire suite of libraries I use to provide functionality to my applications: installation, user data, platform integration, and more. That work, at least, will be reduced with the next app I target for Windows.
I won't bore you with the technical differences between Windows and Mac--they are considerable, but not insurmountable. It is an interesting challenge to develop for a different platform, and I hope to learn more about marketing for that platform as well.Sun, 16 Aug 2015
These releases are the result of a two-month change toward looser enforcement of user registration, i.e. paying for a license to keep using the application after a thirty-day demo. I decided to make the releases nagware (they would pop up an alert if no serial number were found) but not otherwise limit their functionality, even after the 30-day demo period ended. The result was striking: without the requirement to pay, no one paid. I've had no sales over the past couple of months even with the usual number of downloads. Reviewing the rather large drop in sales revenue, I recalled this change I made to my registration code and concluded that was likely the cause. As a result, I've re-enabled the stricter registration code, and demos will once again expire after 30 days. Users who have been using the apps for the past couple of months without registering will eventually have to pay for a license if they want to keep using the apps. (You only pay once, by the way! Upgrades are provided free for life.)
Registration code is one of the duller parts of an application--a lot of housekeeping code, and surprisingly complicated, even with a fairly basic registration scheme such as the one I use. In the past my code has been prone to unexpected bugs that caused the code to freeze my application. There are a lot of scenarios a developer has to test for--the existence of a license or not, measuring how long a demo has run, and so on. It's not fun. To be honest, I eliminated the demo period because I wanted to remove the headaches of keeping the code tested and consistent. However, that code provides an essential function--ensuring that customers who continue to use my application actually pay for the work I've done. In fact, it's the most important function my code provides, from a financial perspective, especially now that I'm moving my applications out of the Mac App Store.
It's a bit disappointing that I have to use a stricter registration scheme to ensure that my work provides a bit of revenue, but I guess it's human nature to avoid paying for something if you don't have to. My code doesn't take elaborate measures to enforce registration, but it's strict enough to keep honest users honest, and that allows my apps to provide a bit of financial support for my business and family.Wed, 22 Jul 2015
The major feature powering new releases of my commercial apps today is a new open-source Tcl project I'm introducing: aem 1.0, which provides a lightweight mechanism for Tcl applications to respond to arbitrary Apple Events sent via the AppleScript programming language, Apple's system scripting language.
aem (short for "Apple Event Manager") is not the first Tcl package to provide an interface to the Apple Event mechanism. Jon Guyer's TclAE package provides a comprehensive interface to the AEM framework; it is powerful and stable. However, it is essentially a thin, low-level wrapper over a complex framework, and inherits that complexity; as a result it is difficult to use, especially if being called from another language with Tcl/Tk bindings. Additionally, it is not actively maintained these days. As a result, I wanted to move in another direction with AppleScript support in Tcl.
The aem package achieves this goal. It implements only a small subset of TclAE's functionality, the ability to respond to arbitrary Apple Events. This allows a Tcl/Tk application to be fully scriptable with AppleScript, in a manner similar to Cocoa applications written in Objective-C. (Other aspects of TclAE's functionality, such as the ability to build individual Apple Events and send them to other applications, can be achieved in a simpler fashion by using the TclApplescript package, which allows in-line execution of AppleScript code, or by executing AppleScript code using the "osascript" command-line tool.)
In addition to being a simpler implementation, the aem package also offers a cleaner, more straightforward design: it directly maps an AppleScript command with a parameter to a Tcl command with a parameter, for execution by the Tcl interpreter. The TclAE package inherits the cumbersome structure of the C-level Apple Event Manager API, which requires it to set up Tcl commands with "event" and "reply" parameters that have no relation to the Tcl code actually being executed, and which also require it to use C function calls to actually retrieve and dispose the relevant parameter from the AppleScript command. The aem package, being higher-level, delegates all that machinery to the underlying C code and does not expose it to the script level. In addition to making Tcl support for AppleScript easier to implement at the script level, this approach also makes it much easier to call aem from other scripting languages with Tcl/Tk bindings. (FileMorph, written in Perl, handles Apple Event support just fine with aem, but could not interface correctly with TclAE because of the parameter machinery.)
I've been hacking away at AppleScript support in my apps for a long time, and have been trying to find a workable solution for supporting Apple Events across the various scripting languages I use. In addition to the difficulties presented by TclAE, Perl's support has been broken for some years (see Mac::Carbon), and the appscript library for Python, Ruby and Objective-C is now actively unmaintained by its author (he discourages its use). With aem, I feel I finally have a library that will support the entire range of my applications, and I'm very proud of it.
I've released version 7.2 of PortAuthority, my GUI for the MacPorts Unix software installation system. The major feature of this release is streamlined under-the-hood support for AppleScript and some minor bug fixes. As always, this release is a free upgrade for registered users, and I encourage you to give it a try if you are a MacPorts user--PortAuthority is the only stable, actively-developed GUI client for the project.
I've released version 2.2 of FileMorph, my file modification tool for Mac OS X. The major feature of this release is a significant upgrade in AppleScript support, moving from a bare-bones implementation to a full-fledged AppleScript API, with genuine AppleScript commands that can be called from scripts and other applications. If you are looking for a scriptable application that can do batch modification and renaming of files and directories, with an intuitive UI, FileMorph may well fit the bill.