Solipsism Gradient

I posted the bug-fixed XRay today as 1.0.9. Bumping the version number was the best way to alert people that something had changed, and sites like VersionTracker (XRay@VT) and MacUpdate (XRay@MU) are geared to changing version numbers too.

Here’s the usual routine which I follow for publishing XRay, in case someone’s interested.

1- Check and rewrite the internal log I keep of all changes. Also check and rewrite all the help files, including the many screen shots.

2- In Xcode, “Clean all Targets” (which will delete the application and subsidiary things like the XRay Contextual Menu and the Developer Plugin).

3- Remove the old copies of XRay, preferences and whatnot, to simulate XRay being installed on a pristine machine.

4- Build in “Development” mode and run under the debugger. Should anything untoward happen the debugger should show me where.

5- Quit and run again. Everything should be OK.

6- Quit, remove preferences and so forth, mount the disk image of the previous version and run XRay once from there to generate old preferences. Quit. Unmount the old image.

7- Run the new version under the debugger to simulate XRay being upgraded on a user’s machine. Quit again.

8- Copy XRay into /Applications, switch to a non-admin user account, and repeat most of the steps above again.

9- If some bug appeared at any step, rinse and repeat; if not, “Clean all Targets” again and build in “Deployment” mode. This mode builds a smaller, faster program without debugging symbols and other encumbrances.

9a- Currently, a bug in Xcode also builds a program without several essential components, which have to be copied in by hand. Curse and repeat until OK.

10- Copy the built program into /Applications, run just to make sure.

11- Run again from a non-user admin, just to make sure.

12- Fire up the trusty ol’ iMac DV/400, with its Mac OS X 10.2.8, and check if everything works there too, JTMS.

13- On the iMac, copy & paste texts from the help files into the text files that I put on the finished disk image. This has to be done under Jaguar because if I do it under Panther the resulting texts will contain URLs that won’t be readable by Jaguar users.

14- Build a disk image with all the requisite items on it. I use a mixture of tools to do that and I’m still not quite satisfied with the process.

15- Upload the disk image to my site via FTP.

16- Download it again, mount it and try to run from there, JTMS.

17- Edit all HTML files on my site that mention XRay, change the version number and the link to the new disk image, copy the release notes and other text that has changed with the requisite format changes.

18- Upload the HTML files to my site with FTP and check all in the browser, JTMS.

19- Go to the XRay support forum, close out the topic on the old version and open a topic for the new one. Check that all links point at the correct disk image etc., JTMS.

20- Go to the VersionTracker site, post an interim message that the new version is being published, remove obsolete messages referring to the old version.

21- Log in at the VersionTracker site (yes, a different login) and post the changes that will appear in the header and main text. (This time I was extremely surprised that someone at VT already had seen the update on my site and done most of my work for me! Thanks!)

22- Do same steps on the MacUpdate site.

23- Remove the old disk image from my site, at this point downloaders will already get the new image.

24- Loop over the VT and MU sites until the changes are published, then remove the interim messages.

25- Write and send out the press release concerning the new version.

26- Sit back and watch the dough roll in. I wish.

Well, all of this usually takes several hours and is extremely tiring. Unfortunately it’s very easy to forget and skip some of the steps, and of course Murphy is always ready to slip in a bug at that point. The last few releases I always either skipped a step, or inserted one I shouldn’t have: make a last-second change to some source code line or another. Thankfully, if that happens, some kind user always writes in and I get a chance to fix it fast, before too many people download the buggy version…

I also try to experiment with release dates, unless it’s one of those gotta-get-this-out-fast-before-they-notice releases like this last one. It seems that Friday noon (local time) is the best time to release new software; it still makes the news on Mac sites, but very little new software comes out afterwards, so XRay will stay on the front pages over the whole weekend. This also smooths out the first download spike, when most of the registered or regular users get wind of the update and download it; today (a weekday) there were something like 2000 downloads in the first four hours!

Now to get some sleep…

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…

Rainer Brockerhoff wrote:

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

Apple just posted the news on their main page, October 24th is the official release day. There’s a neat counter showing how many days, hours, minutes and seconds are left; it imitates one of those mechanical clocks. Interesting how people feel this compulsion to imitate mechanical gadgets electronically…

Rainer Brockerhoff wrote:

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…

I noticed that this morning I was done with my news/RSS feed reading in less than an hour, and that I followed up much less links than usual. Apparently my usual news sites and weblogs are concentrating on stuff like California elections, Washington shenanigans, the baseball season and other regional/ethnic issues – it’s all even more opaque than usual. So… do I suddenly live in uninteresting times?

(Um resumo, em português, deste post está na minha página principal)

It’s that time of the year again when the Brazilian government decides, by decree, when and where Daylight Savings Time begins. Last year Mac OS X users in Brazil had serious problems with that, as Mac OS X 10.2 (Jaguar) had the wrong dates inside the Unix tables that most of the system uses, and another (different!) wrong date inside a legacy table embedded into one of the frameworks, which was used by the Finder and some other applications.

In 2002 I published a patch to fix the Unix tables but couldn’t change the framework table. In addition, some – though not all – users reported a problem with their system snapping back to normal time on New Year’s eve. So this year, I’m waiting until someone else publishes the correction…

At this time, I haven’t got a system running Jaguar in order to test what will happen this year. The legacy table was finally removed in Mac OS 10.3 (Panther), so at least it will act consistently for all system calls and applications. However, it seems that Panther is considering DST as starting on Oct. 12 instead of the decreed date of Oct. 19.

Mac OS 9 users will have no problems, as there is a convenient double checkbox in the Date & Time Control Panel to allow the user to set DST manually. I’ve filed an enhancement request with Apple to put a similar checkbox into Mac OS X, but there’s little or no hope of this being done anytime soon (if ever).

The problem in Brazil is even more complicated, as DST is observed only by certain states in a manner not consistent with the timezones used when DST is not in effect. Additionally, the government may decide to extend or abbreviate the DST period at any time. So a manual checkbox would certainly be the easiest way around the problem.

…or perhaps a GUI viewer/editor for the timezone files… if only I had the time…

I wrote:

I’m leaving for São Paulo to pick up my new laptop, put up the old iBook for sale…

Well, I’m pleased to report that I’m back, and have the PowerBook up and running, after some initial hitches.

As usual with most of Apple’s products, it’s difficult to estimate size and beauty from photographs. I saw the recently introduced iSight camera, and it was much smaller than it appears on the photos. In contrast, the 17″ PowerBook is even larger than I thought. It’s thinner than my old iBook, though, and the weight increase isn’t apparent. The screen is larger and better, the loudspeakers sound much better, and of course the speed and storage increases are noticeable.

I had some difficulty in getting the built-in Airport Extreme (802.11g) card to interoperate with my SMC Barricade 7004AWBR wireless router. I tried several things – setting the MTU to 1492, changing from fixed IP to DHCP, downgrading the Airport software from 3.1 to 3.04, and trying out different WEP encryption options. I’ve had no time to regress some of these things to see which specific one was the culprit, but it’s working now. And I also now recommend xwepgen, a program that calculates the various hexadecimal WEP keys from a password – invaluable for using Airport with non-Apple base stations.

The built-in trackpad somehow doesn’t feel as good as the iBook’s; the surface is rougher and my fingertip keeps sticking. As I normally use a mouse, this isn’t an issue. The first days I kept hitting the wrong keys, since I had apparently been using the laptop’s edges for gauging key locations. Other than that I’ve no complaints…

I’m leaving for São Paulo to pick up my new laptop, put up the old iBook for sale, and make some business contacts. The new machine will have space and speed to handle the new Panther (Mac OS X 10.3) and I’ve been wanting a G4 for doing some AltiVec stuff, anyway.

By a coincidence, yesterday I found a new owner for my DayStar Genesis MP528, a PowerMac 9500 clone which I bought about 8 years ago. Originally it had 4 PowerPC604 processors running at 132 MHz, with a 40 MHz bus; after two processors burned out, I bought one of the first G3 boards (300MHz) for it, and upgraded it over the years. I stopped using it after Mac OS X came out.

Regarding our previous discussion here (and a few posts before that), Erik J. Barzesky writes that he prefers .dmg files for archival purposes:

The time for DropStuff/Deluxe has passed. I find myself using .tgz on the command line for files I know to be safe (i.e. those without resource forks). StuffIt Expander will continue to be useful for at least a little while, but for now, .dmg is the way I intend to go.

I still use DropStuff (part of Stuffit Lite) for temporarily archiving installed applications or data files, but I agree with Erik that .dmg is the best way for archiving things.

Regarding software distribution, my experience is that most users also want to archive the original .dmg, so that’s what I use for my own products.

Hi Buzz, thanks for dropping by…

Buzz Andersen wrote:

There are definitely some problems with disk images, but you’re probably right that people who don’t “get” them are in the minority (and they’re probably the type of people who, honestly, would have problems regardless of how the software was distributed ). I know I’ve encountered more than two users who have run into this problem myself (probably more on the order of 6 or 7), but that’s still not *that* many.

Right, there’s a point of diminishing returns for idiot-proofing, otherwise “normal” users will start to complain that the application or the installation process is too patronizing; just look at the average Windows “wizard”…

Buzz Andersen wrote:

Now I’m starting to think the solution to my problem might simply be to put a very prominent graphic with the words “Drag this to the Applications folder” and an arrow pointing toward the application into the background of the disk image.

Exactly my point. I’ve thought of adding “…and eject this disk image”, but that may already be too condescending.

I’ve also read a suggestion (can’t recall where right now, sorry) of providing a symbolic link to the Application folder on the disk image, and saying “Please drop the application here”. Supposedly some BeOS installers worked that way – it sounds interesting.