Solipsism Gradient

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…