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
I've brought TextSweep, my search-and-replace app for the Mac, out of storage and back into active development. A couple of months ago I had announced its discontinuation because it seemed horribly broken: freezing up whenever the user selected a file to display. I blamed insoluble bugs in its underlying GUI framework, Tk, for the problem.
As it turns out, the bug was in my own code, so embarrassingly simple to fix that I still can't believe it. Essentially, if no search term in the application were defined (i.e. if the search field was blank) then the app would lock up; if a search term was defined, it would run as normal. Fixing this is literally one line of code. Unfortunately, finding the source of the bug turned out to be fiendishly hard (I ran across the actual error essentially by accident), and kept the app from being usable for months.
Ah, well. Now that I've found the source of the error, I have released version 2.1 of TextSweep and submitted the same version to the Mac App Store for review and inclusion. I'm still not 100% satisfied with the app and want to refine its features further, but now, at least, it runs. That has to come before anything else.
Sun, 04 May 2014
Wed, 16 Apr 2014
I've decided to discontinue my TextSweep search-and-replace app. I've had a large number of problems getting it to run in a stable fashion on Mavericks, it hasn't sold anything this year (owing to its lack of functionality, I suspect), and it has never worked as well as I'd like even if it does launch correctly. Rather than invest time in rewriting it from scratch, I've decided to scrap it. I have released updates to several other apps this month, so I will continue to work on those.
Comments are closed for this story.Sun, 13 Apr 2014
I've released updates to both PortAuthority and PacketStream. These updates include the improved update mechanism based on Sparkle that I'm adding to each of my apps, and also a workaround for a serious system-level bug in Mavericks.
The bug in Mavericks--which affected these apps but which was not my doing--revolved around running AppleScripts with elevated user privileges, which is a requirement for some of the operations that PortAuthority and PacketStream perform (installing software, listening to network data). I had turned to AppleScript to provide a better, more native implementation of this process than older versions of my apps supported. Unfortunately, the AppleScript bug in the most recent update of Mavericks, 10.9.2, caused the AppleScript to hang; thus, my apps making use of this functionality never completed their operations and never displayed data. In short, they stopped working. Developers call this type of bug a "showstopper," and it's as serious as you can get.
Given that this was Apple's bug rather than something in my own code, my options for dealing with it were limited. I filed a bug report with Apple in hopes that a new update of OS X might resolve the issue, but no action has been taken to address the issue as of yet. I was reluctant to move away from using AppleScript because it provided a much better user experience than my older methods: native dialog, behavior more consistent with other apps, better performance. However, none of that matters if the app doesn't work.
As a result, I've reluctantly re-introduced my older approach to running privileged operations. Instead of running an AppleScript command with administrator privileges, I now presenting a password dialog to the user, then pipe that password to the command line "sudo" tool under the hood. "Sudo" does the same thing as my AppleScript method did, just without the fancy native dialog. Some developers suggest this method is a little less secure than the native method that AppleScript implements. However, even if that's true, it has the virtue of actually working. The new versions of these apps work as expected.
I took the opportunity to simplify the password code a bit, and I've retained the improved method of reading data into the apps that I implemented with the AppleScript approach; thus, the apps haven't lost anything in terms of their performance and responsiveness. (Another reason I went the AppleScript route was that my old password code was sluggish and could cause the apps to lock up at unpredictable times. I don't think that will happen here.)
In any event, I don't plan to go back to using AppleScript. It's highly unlikely that "sudo"--which is a long-stable, core Unix command--will ever run into the same kind of system-level bugs that AppleScript has.
If you've recently downloaded these apps, and wondered why they didn't work, please give the new versions a try.
Comments are closed for this story.Thu, 10 Apr 2014
I've released a couple of updates to NameFind in the last week. The first update, 7.1, fixed some UI glitches on Mavericks: icon images were diplaying in the UI in a jagged manner. The images also slowed down scrolling in the data view. I ultimately decided to get rid of icons altogether in the table view and instead display them in a separate info window, if the user calls that up.
The second update, 7.2, released today, completely overhauls the app's update mechanism. For several years I had used my own system, but last year I decided to add Sparkle support, the popular framework for app updates that is still used by hundreds of apps that are downloaded from outside the Mac App Store. My own homegrown updating system has had some hard-to-track bugs in recent versions of my apps, and I just decided to abandon it in favor of Sparkle.
Unfortunately, Sparkle itself has proven to be somewhat unstable on Mavericks; it often fails to fully update an app, crashing and requiring a manual relaunch of the updated app before the new version is visible. Just as badly, Sparkle's source code page at Github states that Sparkle is now unmaintained by its developer--which means he is no longer working on it. (I believe he is now an Apple employee, whch precludes work on outside projects, even popular ones.) Unfortunately, because Sparkle is now unmaintained, there is little chance that bugs in it will be addressed going forward.
Given that both my old and new update mechanisms are problematic, how have I decided to proceed? By implementing a hybrid of the old and new.
I like Sparkle's "appcast" approach for broadcasting updates; it requires the developer to upload an XML file to a website, similar to an RSS feed, which other sites can download. (Some Mac software listing sites, such as MacUpdate, use this mechanism to track app releases.) This is better than my old approach, which could not be parsed by other systems. So I opted to keep Sparkle's server-side mechanism, and replace its app-level code with my own. This required me to do two things: fix the bug in my old code that kept updates from installing correctly (it was a stupid, stupid error in the way I archived the app update file for download), and rewrite some of the code to present a user interface similar to Sparkle's, which I also liked.
Thus, this approach is the best of the old and new: it uses an industry-standard mechanism (appcast) to announce app updates, but better integrates with my own apps by implementing a Sparkle-like interface and workflow in my own code.
If you use the Sparkle update in the current release of NameFind, you will see the same old bugs, but going forward, you'll see the new Sparkle-like update approach, which should work a lot better.
I don't regret working with Sparkle; spending time with its internals, even if I couldn't fix them, allowed me to understand it well enough to implement something very similar, and Sparkle's server-side "appcast" mechanism remains intact in my toolbox. The new hybrid approach provides a smooth upgrade experience; I have been remiss in not paying attention as I should have to this part of the user experience of my non-Mac App Store apps. I will continue to focus on this going foward.
Comments are closed for this story.Mon, 10 Mar 2014
I've released version 5.2 of Manpower, my man page viewer for Mac OS X. This version cleans up some of the user documentation and fixes a couple of recurring UI glitches that I thought I had licked in the last release. Please feel free to give it a try.
Comments are closed for this story.Tue, 25 Feb 2014
I've released version 5.1 of Manpower, my man page viewer for OS X. This release includes a few bug fixes for UI glitches and rendering on Retina displays.
I've gotten some reports from users that OS X on Mavericks reports that the app is damaged, and advises trashing it. OS X's Gatekeeper library, which sets certain restrictions on apps, apparently thinks Manpower has been tampered with or otherwise corrupted. The app is signed with a valid developer certificate, which should pass through Gatekeeper's restrictions; I'm not certain why it's being flagged.
I have found a workaround. I was able to fix this by changing my Gatekeeper settings to allow apps downloaded from anywhere, and installing in /Applications. After launching Manpower, I then re-enabled more restricted settings in Gatekeeper and Manpower ran fine. So, if you download Manpower and run into this issue, give this workaround a try.
(Note that this workaround will not apply to the Mac App Store version of Manpower, which shouldn't display the issue at all. I've submitted version 5.1 to the MAS and hopefully it will be released soon.)
Comments are closed for this story.Wed, 15 Jan 2014
Comments are closed for this story.Mon, 30 Dec 2013
TextSweep is no longer in the Mac App Store.
I've tried four times to get the new version, 2.0, approved, and after an initial rejection that reflected some silly oversights on my part, I've hit a more difficult obstacle: the App Store version freezes when files are dragged to the main window, while the non-App-Store version does not.
The difference between the two--the app sandbox, which is required for the MAS version--seems to be the obvious place to look for issues. I've disabled the sandbox for the version downloaded from my website because I want to support the Sparkle app updating tool for that version, and Sparkle is incompatible with the sandbox.
After doing some further digging, I've narrowed it down to one of two issues, both intractable. The likeliest cause is that the sandbox does not play well with groups of dragged files, as Apple discusses here: "Although you can support dragging file paths, in general, you should avoid doing so unless you are certain that the destination app will never be run in an app sandbox." Removing drag-and-drop support from TextSweep would make using it so cumbersome it hardly seems worth the effort.
Another, less likely candidate is a long-standing bug in Tk that leads to hangups and freezes at random moments; this is a result of the complex and fragile integration between Tk and Cocoa, which works somewhat differently at processing user events than Tk does. (Carbon integrated far better with Tk in this fashion.) When I force-quit TextSweep because it hangs, this is what I'm actually seeing (though I suspect it was triggered by the sandbox not handling groups of dragged files gracefully). This bug has proven impossible to fix, so if I can't work around it, I'm basically stuck.
Either way, the non-sandboxed version works just fine, and so it's just a simple matter of supporting that version: done. I've removed the existing MAS version of TextSweep, and will not be submitting any more MAS updates.
If you are a user of the MAS version of TextSweep and would like to update to version 2.0 at no cost, please contact me and I will be glad to assist you. My apologies for the difficulty.
Comments are closed for this story.Sat, 28 Dec 2013
Now, TextSweep is the last app still under review. I'm hoping it will be approved in the coming week.
Comments are closed for this story.