Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Development

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

icon_lol.gif

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.

Posted by Buzz Andersen:
Rainer,

Some good points. Upon further reflection, I think I’ve started to soften my stance a bit (I think the vehemence of my post may have been somewhat influenced by the rather irate support email that I received). 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.

You also brought up some good points about Internet-enabled disk images. 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.

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.