Solipsism Gradient

So I spent a somewhat more relaxed day starting up my new application, <censored>, which will be the new killer app for doing <censored> to <censored>. (Sorry, can’t be more specific at this time – all I can say is that the name starts with an “Y” ).

As I said before, real Mac application development’s step one is to design the application icon (step zero is to design the T-Shirt, which I usually skip, as it makes no sense unless it’s a team effort). After making three mock-up icons I ended up with one which I liked, but some friends who saw it were less than enthusiastic. Perhaps I should make a design contest? Winner gets a free lifetime registration and About Box whuffie? Hmm…

Meanwhile, I found the story of my life in this comic reenactment. See how a fellow geek/marginal Asperger sufferer handles interpersonal relationships! This sort of thing happens to me all the time… (for the record, I did see “Maid in Manhattan”, on a plane, but thought it a little silly).

Ben Hammersley points at Umberto Eco‘s great essay Vegetal and mineral memory: The future of books:

Good news: books will remain indispensable, not only for literature but for any circumstances in which one needs to read carefully, not only in order to receive information but also to speculate and to reflect about it. To read a computer screen is not the same as to read a book.

…

After having spent 12 hours at a computer console, my eyes are like two tennis balls, and I feel the need of sitting down comfortably in an armchair and reading a newspaper, or maybe a good poem. Therefore, I think that computers are diffusing a new form of literacy, but they are incapable of satisfying all the intellectual needs they are stimulating.

Very true. I rarely look up anything in a reference work anymore, but reading fiction on-screen is not as satisfying as with a physical book – and the latter can be read at table or on the toilet, too

Well, it turned out that I had skipped step 16 on my long list of “just to make sure”, or rather, I’d neglected to do that after uploading a corrected image. For the second time.

No idea why it went wrong two times, but on the third everything seems OK. Meanwhile, new XRay users should download 1.0.9 again if they see a message “…Sorry, but to set everything up properly you must first run XRay once from an Administrator account.”

I woke up about 3AM to get a glass of water and on the way back from the kitchen I somehow felt I had to check my e-mail… I know that’s a symptom of something-or-other, but anyway it allowed me to see one user’s alert about my error several hours sooner than usual, and do damage control.

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…

(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…

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.

Der Schockwellenreiter quotes a marvelous cautionary paragraph from Daniel Steinberg‘s article Transforming iCal Calendars with Java:

This code is presented as an example. Do not use it on data for which you don’t have a copy. It hasn’t been widely tested. Consult a professionally trained computer scientist or a twelve year old child before attempting anything difficult on your own machine.

As I’ve mentioned before, I won’t be able to make it to MacHack this year… however, I strongly recommend this year’s conference for anybody interested in programming for the Mac.

MacHack #18: Unstoppable will be held from June 19-21, 2003, in Dearborn, Michigan. The official theme is the Spinning Pizza of Death . Have a look at the contents; I’ve never seen so many papers and sessions, all very interesting. This will certainly be a conference to remember.

For the first time, MacHack will happen before Apple’s WWDC, which will begin immediately afterwards: June 23-27 in San Francisco. In other circumstances, this close juxtaposition would make it possible for me to attend both conferences; let’s hope they do it again that way next year…