Solipsism Gradient

So here I was, practically all known bugs in XRay 1.0.7 fixed… just coasting a little before diving into the boring part of reviewing the online help files and updating the screen snapshots prior to publication… writing the part of the release notes explaining why (once again) no new plug-ins would be released with 1.0.8… writing e-mail to a user explaining (also once again) why 1.1 wouldn’t have a batch mode… piece of cake, really. Reviews were positive, but sales not really. How should I generate more user enthusiasm?

…when suddenly the proverbial light bulb flashed on and I thought, hey, if I do a simpler batch mode with a batch plug-in, keyed to work on all the contents of the folder being XRayed… hmm… I’ll work around all the arguments saying that I don’t have a proper user interface for doing arbitrary file lists.

So, off I go making a batch plug-in for XRay. First of all, of course, one must design the T-Shirt!

Hehe, just joking. First of all, a real Mac programmer spends at least one day – maybe two – designing the product icon:

…meanwhile, ye olde subconsciouse is chugging along, working out what the user interface might look like. Then, off we go into Interface Builder and try to build an actual user interface out of those musings…

Got it? The left column of checkboxes enables the items to the right. First, there’s a section with assorted items… looks rather jumbled-together and empty on the right side, hmm. Then, there’s a copy of the UI elements from the Type/Creator/Extension panel… then it would be nice to tell the user how many contained items there are in that folder… then we’ll need the recalculate/stop button from the main info panel… then it would be nice to affect files, folders, or both, and only on the first level… then we need a “Reset All” button to clear everything…

Oh my. This doesn’t look all that good, but writing some code usually will clear everything up. So I get to work, inserting outlets and actions and making sure all the little connections go to the right items. Then I see that my standard plug-in example code is outdated and I spend a day or so cleaning that up, and getting used to all the new fancy Xcode options for plug-ins. Cleaning up the .plist, compiling an empty plug-in to make sure it loads and all the options are right, and finding out why the Finder doesn’t show the new icon. OK, ready for some real action.

After a couple of days of trying to reuse some existing code and not getting anywhere – and moving stuff around in the window and making it even worse – and puzzling out the logic of the actual batch operation (which options apply to folders? Which to files? What if such-and-such?) – I concluded that it all was a big mistake. Would some user really wish to mark all the contents of a folder, to all levels, as “Purple”? 🙂 (Well, probably someone somewhere is just waiting for an utility to color his entire “/System/Library” folder and its contents purple, but should I really help this person further his/her/its wicked ways?)

After a sleepless night, I concluded that what users really need (as opposed to want) is just changing type and creator of a bunch of files inside a folder. So there. So let’s just imitate the way that the Permissions panel lets the user specify which permissions should be changed for contained items, but in this case with the type/creator fields and popups. Simple and direct.

So, that’s what I’ve been working on, instead of updating this weblog. I was going to post a screenshot of the current panel, except that – while capturing the image – I saw a way to simplify it even further! So, expect XRay 1.0.8 out in a few days, with (tadah!) limited batch mode. Isn’t it fun? Now excuse me, I need to oil my “delete” key…

The GIGA USA quotes site contains over 50,000 quotes indexed by date, author, and whatnot. And it’s searchable! And it links to a hundred other quote sites!

Following some links I chanced upon one of my favorite Steven Wright quotes:

I bought my brother some gift-wrap for Christmas. I took it to the Gift Wrap department and told them to wrap it, but in a different print so he would know when to stop unwrapping.

😆

This is very apropos of a bug I’m fixing in XRay. I’m using aliases to track open files, in case they’re moved; if the open file is a symbolic link, it’s very hard to keep the system from following the link – I keep getting the file the link points at instead of the link itself. I need to find some system call that stops unwrapping the aliases/links at the appropriate place…

Either Panther has an unusual number of hidden gotchas, or Murphy is singling me out for special treatment this time… perhaps both. XRay 1.0.7 is getting good reviews but users are also stumbling over several bugs – due, I’m sorry to say, to somewhat hurried testing. Details at the 1.0.7 discussion forum.

I was figuring on spending this week and the next on reviewing the not-too-good plugin architecture; writing a few plugins which do new things is usually the best way to find out architectural limitations. Hopefully I’ll be able to close the last bug over the weekend and then start on that, but I’ll try to publish 1.0.8 as soon as I get at least two new plugins working.

In other words, expect light blogging for the next weeks, as they say. In the meantime, if you’re an aspiring Mac OS Xshareware programmer, here’s excellent advice from Brent Simmons (of NetNewsWire fame) about making money with shareware. I seem to have lucked out, doing instinctively most of what he recommended…

Well, the old drawing board is getting an unusual amount of wear lately… and I’m glad! Exactly a week after XRay 1.0.6, I’m now announcing XRay 1.0.7. This has several bug fixes and new features, runs on both Jaguar and Panther, and can be invoked from the Finder by selecting an item and typing Command-Shift-X. More details in the release notes. Please post comments and suggestions to the XRay support forum.

About 4000 people have downloaded 1.0.6 so far. Since only a fraction of users (perhaps 1 in 5?) check compulsively for a new version every week, I estimate that there are about 20000 regular or occasional users around… I don’t have exact numbers for 10.0.5 downloads, but I think about 40000 copies were downloaded from my site and a few mirrors, and dozens of shareware CDs are around with 1.0.5 on them. So I’d estimate, again, that perhaps 1 in 5 users that try XRay will keep on using it regularly, and 1 in 10 of those have registered. From what I know, that’s way above the industry average. Thanks to all of you!

XRay 1.0.6 is a bug-fix release for Panther. Please read the release notes for more details; I also commented on some XRay decisions in a previous post.

I had almost forgotten how much peripheral work is involved in releasing new versions of shareware. To ensure that I’d have time to kill some remaining bugs without interruptions, I accompanied my wife to a secluded Fazenda (farm), where she took an English immersion course while I hacked away at the code. No phones, no Internet connection, quiet, excellent food… almost ideal conditions. I took some nice pictures, too… more about that later.

(This post will be cross-posted to the XRay support forum)

It seems that I finally have achieved some sort of critical mass or energy to start working again on my software on a regular basis. There were some false starts in the past, but this time actual progress is being made. I’ve already made serious progress in adapting XRay to Mac OS X 10.3 (Panther); nearly half of my bug list is done already.

The rumor sites say that Panther is heading for release before the end of the month, that the Golden Master release is already being duplicated, and even that work has already begun on 10.3.1. As I’m under NDA I can’t comment on that, or on specific features beyond what’s already published on Apple’s site. All I can say it everything works beautifully now, and it’s so fast that I was seriously inconvenienced when I had to go back to 10.2.x (Jaguar) for a few days…

For developers, porting any complex application to Panther may imply some reprogramming. There are many new APIs and resources in Cocoa, but to use these one has to write a Panther-only application. I’m already seriously tempted to axe 10.1.x support – in fact, 10.1.x users should for the near future continue to run XRay 1.0.5, as I no longer have any machine available that is capable of running 10.1.x! To complicate matters, new facilities to build applications that run on several versions – conditionally disabling features if run on older systems – don’t exist in 10.1.x and are somewhat primitive in 10.2.x.

The new GCC 3.3 compiler also brings some changes. Granted that one can keep using 3.1 (or even 2.97), but with a few restrictions. The new compiler generates better code and is more strict about some constructs.

Regarding XRay, I’ve reread all user e-mails I received this year and I’ll try to incorporate most reasonable suggestions. If you have suggestions, now is the time. I expect to release XRay 1.0.6 a week or so after Panther comes out – just to make sure that nothing broke with some last-minute change.

1.0.6 will be strictly a bug-fix and mandatory Panther-support release. Why? XRay was my first Cocoa application and now, going back to the code after nearly a year, I find that some parts were not as well written as they should be. I was concerned with getting stuff working and published, and made several design decisions and implementations which I now know to have been, shall we say, less than optimal. In particular, running 1.0.5 under Panther reveals some serious bugs and crashes which are due to my misunderstanding and faulty workaround of certain Cocoa specifications and limitations.

Progress from Jaguar to Panther means that several bugs seem to have been fixed on Apple’s side, though I don’t have any specifics yet. On the other hand, some hacks that I used to get certain features in Jaguar no longer work, so a few features will be unavoidably lost.

To a certain extent, Panther’s Finder has new capabilities that make some of XRay’s permission changing features redundant. XRay was always intended to be more a viewing tool – as you can tell from the name itself – the changing facility works only for certain attributes anyway. I think that rather than working hard to duplicate stuff built into the Finder, my time will be more profitably spent in writing new plug-ins and viewer facilities.

I have had many requests to build batch processing capabilities into XRay 1.1, and have made a few false starts on that. One deterrent are the aforementioned design decisions. XRay is built around a one-document-window-per-file paradigm and all its consequences regarding saving changes and so forth. The “Change enclosed items” is a limited batch facility for file permissions only, and strained the paradigm somewhat. Building batch processing into XRay would mean a whole new user interface, as well as a new plug-in interface, both designed for efficient changing (rather than viewing) of attributes.

Therefore, I regret to say that batch processing is not viable for implementation into XRay as it exists today. After releasing 1.0.6 and updating some of my other software for Panther I plan to start work on XRay 1.1, which will be a complete rewrite – practically from the ground up. This will be Panther-only and incorporate whatever I learned about writing Cocoa applications in the past two years.

In parallel, however, I’m planning to write a completely new application for batch file processing. Registered XRay users will not be forgotten, I assure. Details will be published as soon as possible…

Joel on Software writes about the options for talking about future products:

When Apple releases a new product, they tend to surprise the heck out of people, even the devoted Apple-watchers who have spent the last few months riffling through garbage dumpsters at One Infinite Loop.

Microsoft, on the other hand, can’t stop talking about products that are mere glimmers in someone’s eye. Testers outside the company were using .NET for years before it finally shipped.

So, which is right? Should you talk endlessly about your products under development, in hopes of building buzz, or should you hold off until you’ve got something ready to go?

…I have a policy lifted from Marlon Brando, playing a mob boss in The Freshman: “Every word I say, by definition, is a promise.” The best way to avoid breaking promises is not to make any, and that’s as good a reason as I need not to talk about future versions of our products.

I find myself mostly agreeing with Joel here. While I see no harm in collecting user suggestions, and saying “this (or that) is on my list for the next product release” at reasonable places, it’s rarely good policy to preannounce major stuff. Unless (or perhaps even if) you’re Microsoft.

That said, how does this apply to XRay? While I have a quite reasonable list of features “for the next release”, some of the things on that list – like batch processing – entail a complete revision of fundamental components, such as the plug-in interfaces. I’m confident that it can be done, and it will be done in version 1.1, but I still may release another 1.0.x version before 1.1 comes out.

For several reasons, new XRay versions have been delayed. While I still spend about an hour a day with user support, time to do concentrated work on the next version hasn’t been available… until now. This weekend I’ll be restarting full-time work on XRay.

Sorry, can’t say yet when the next version will come out, or what number it’ll be…