Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Development

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 icon_biggrin.gif. 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…

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 icon_smile.gif ). 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”…icon_wink.gif

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.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2014 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.