Solipsism Gradient

You may have noticed some dozen trackback spam entries here, on various topics, over the last week. Had a merry time deleting them all, as doing consecutive deletes uncovered a bug in my post-deleting patches… I’m still undecided on whether I should spend time on fixing the bug or on perfecting the workaround I found. In any event, if you’re the unmentionable who’s doing this, your links won’t work, as they were all being tagged with rel=”nofollow” anyway. Which I implemented as soon as it came out. So you might as well give up.

On a similar note, attacks from Santy and its descendant worms are decreasing daily, since Google now seems to be actively blocking its searches. So that’s one less thing to worry about, I hope.

Meanwhile, the Creation Robot has posted a list of The Top 100 Mac OS X Applications and Nudge is on it. Thanks! Now… why aren’t my other apps on it…?

Work on RBSplitView is proceeding well; besides implementing several suggestions from users, I hope to finally have animated collapse/expand in place. So far the method of collapsing a subview has had to be changed completely; formerly I was moving a collapsed subview off screen, keeping it at its original size; now I’m keeping it in place, collapsed to a zero dimension, and jiggling other stuff around to keep it from squishing its own subviews out of shape. Once that is done, animating various intermediate stages should be easy. I think.

Hm, there’s more meta stuff. My Technorati tags now finally seem to be working; I overlooked that they have to be implemented in the RSS feed also, and have to look “just so”. A very interesting experiment. They’re also producing RSS feeds for tag updates, which should make tags very useful once adoption spreads.

Speaking of RSS feeds, my subscription list (on the left) has been updated once again. My stats show that only a third of you are reading this weblog over RSS; I wonder why, since other bloggers report much higher ratios, some as high as 90%. I’ve been asked why I don’t have a Atom feed; now that the final spec seems to be well on its way, I’ll do it as soon as I find some spare time.

Suddenly, a number of XRay users began e-mailing me with questions about a supposed version 4 (!), or saying that someone else had published an application with the same name, and that I should do something about it.

Well, I already knew there was a video app around called DivXRay (as well as dozens of Windows app with various spellings of the name), but nobody had ever confused them before… but upon checking more closely, there certainly was a new app there called XRay 4. Worse, their website made reference to “XRay 3” and “XRay 2”, and as you all know, I’m still working on XRay 2 myself… so something indeed had to be done.

I e-mailed Martin Hering, the author of the application, and in some few minutes we had a long conversation over iChat. He’s German too, so I got a chance to practice . Turns out he was indeed the author of DivXRay, took it with him when he left the company that formerly sold it, and had now shortened the name of the new version at the request (with a cease&desist, I suppose) of DivX.

He wasn’t at all overjoyed at the news that he would have to change the name again – especially since he’s already selling boxed CDs in German stores. However, XRay is a common enough word – although not in that particular spelling – so my intentions were just to avoid user confusion on VersionTracker and MacUpdate. We finally agreed that he would call the application “XRay Video 4” on those sites, and that we would link to each other’s sites to avoid user confusion; since our apps are not competitors, that’s quite satisfactory for me.

Well, there’s a lesson here: searching carefully for existing application names (and trademarks) is always advisable…

Time for another update on XRay 2.0.

With a little help from some friends, I have a preliminary idea of the GUI roughed out. It’s still too soon to present a screenshot, but I decided to go with the single-window idea I described previously. The main tool for the user to adapt the interface to personal needs will be the split view paradigm.

Vertically, the window will be divided into several splits, most of which will have subsplits. From the top down, we’ll have a simple file browser like XRay 1.1 has, with the Panther Finder sidebar at the left in a subsplit that can be collapsed. Below that, there’ll be a collapsible “history” list on the left, and the “Information” panel on the right. The latter will contain the actual information for any item selected in the file browser. But I plan to change from XRay 1.1’s switchable pane paradigm to an outline view, somewhat like the Finder’s “Get Info” windows.

In all probability, the information window will also be split – vertically, now – into “Metadata” and “File Content” sections, and the respective contents will be furnished entirely by plugins. Below that, there’ll be a third split for the batch processing interface, again subdivided into two subsplits, items to be processed on the left and actions to be taken on the right. Details are still hazy here, as I’ve never done batch processing before (at least not on the Mac).

After taking some time to get the splits working exactly right, I ran into serious limitations with Cocoa’s built-in NSSplitView class. For instance, programmatic collapsing/expanding of splits isn’t supported, and assigning minimum sizes to the splits works only under certain circumstances; in others, the subviews of the split can be pushed out pf view without any notice. I had both problems almost solved – the first by generating fake mouse drag events, the second by intercepting subclassing most of the default resizing methods – when I ran into some conditions where my solutions would fail to work correctly, with no alternative in sight.

So much for trying to fix NSSplitView. After examining and discarding some other fixes floating around on the net, I decided to reimplement NSSplitView from the ground up as a NSView subclass. This, in turn, launched me into writing an Interface Builder palette so I could set up my window as usual.

Unfortunately, after over a week of fiddling around, I have to report that the current documentation for writing complex palettes is almost non-existent and that there’s a serious bug in Interface Builder (at least in the current 2.4.2 version that comes with Xcode 1.5). Dragging other views into my container view doesn’t work at all and I was unable to find any workaround.

Still, I haven’t given up and I’m now deciding whether I should build my window entirely programmatically or spend a “Support Incident” at Apple ADC to get an official workaround… stay tuned.

John Gruber just posted a long review of BBEdit 8.

John’s articles are always very well written, but his thoughts on user interface are especially interesting for programmers:

From the perspective of users, however, the importance of the user interface is profound. For users, the application is what they can see, click, and interact with. A user?s relationship with an application is perceptual, sensual.

The raw capabilities of a particular application are, for most users, irrelevant; it’s the usability that matters. Features which aren’t presented via an intuitive, discoverable, usable interface might as well not even exist.

…

I won’t dispute that BBEdit’s interface is relatively unadorned; but so while it’s not pretty, it isn’t trying to be. Handsome is perhaps more apt. The layout of windows, dialogs, and menus is meticulous and thoughtful. The point is not to impress you; the point is to enable to you get work done.

In fact, it’s very tempting to make a feature list for XRay 2.0’s user interface just by going over John’s points one by one…

It’s been a busy month with many interruptions. So we interrupt our hiatus to present you a <cue trumpets!> philosophical update on XRay 2.0.

As I mentioned before, 2.0 is being rewritten from the ground up. No source code, graphics or window designs from 1.x will be reused. XRay was my very first Cocoa application and while I got it working, often in ignorance of the right way of doing things, it’s beginning to show its age and maintaining it is becoming a difficult and, dare I say, embarrassing proposition. Starting again from the ground up has so far been as much fun as I had hoped.

The first important decision was of course to code for Panther (Mac OS X 10.3) and up. The statistics show that around 93% of the users that downloaded 1.1 are already on Panther, and until 2.0 comes out earlyish next year I hope that most of the holdouts will also have upgraded; so this hopefully won’t be a big issue. Cocoa on Panther has many added features that I’ve always been eager to take advantage of, so the user’s benefits will be smaller code with less hacking around limitations.

One new-for-Panther API that I won’t use yet is Cocoa bindings. From the many questions and head-scratching I see on the developer lists, this technology still isn’t as fully documented as I’d like, and some of it is still evolving. Also, it acts in an indirect way – bindings seem to be, essentially, useful side effects – that appears to be difficult to debug for someone who has only now fully absorbed things like Interface Builder’s outlets and actions. So I’ll pass on this for now and will look again at it when Tiger (Mac OS X 10.4) comes out.

Q: How many Mac developers do you need to change a lightbulb?

A: Six. One to come up with a snappy project codename, one to design the team T-shirt, one to draw the icon, one to design a completely new GUI, one to hack out a public beta of the lightbulb over the weekend, and one to draft the memo to management to ask for more powerful development hardware. 😆

As it’s just me toiling away here in the code mine, I skipped steps #1 and #2; the last step will hopefully be possible when a new 17″ PowerBook comes out. So I decided to make a new GUI and base the new icon on it. At the same time, I needed to have a strong reference to the original XRay icon:

I drew this icon overnight at MacHack 2001 and it’s become one of my most successful icons. Still, it’s based on the original Mac OS X aqua interface and I wanted to emphasize that the new version will be Panther-only, so here’s a preliminary rendition of what it will look like:

By the way, I successfully resisted changing the blue X to Jaguar fur (shudder) when 10.2 came out; it didn’t scale well. And it looks like Tiger will keep the metallic look of 10.3, so the new design should look up-to-date for some time.

While trying to draw the new icon I became obsessed with getting the metal texture exactly right, while not copying outright the metallic X best seen in Apple’s Installer window background. Not only because of trademark considerations, but also because it proved devilishly hard to reproduce. For one, the X isn’t drawn in any publicly available font; for another, the subtle shading effects would be mostly covered by the XRay “film”. So I settled for using the standard “metal window” background for the X, which is also instantly recognizable.

As I tried to draw the new icon in several sizes, including the 256×256 extra-large size required for Tiger compatibility, I noticed that the metal texture and edge shading shouldn’t scale with different sizes; also, the curvature of the film corners looked better when kept the same. In order to impress other programmers with my l33t C0c04 sk1llz, I decided to make the “About Box” window’s background into a scaleable version of the icon itself. This in turn led me to learn about partially transparent windows, the way window backgrounds, views and window controls are drawn, and how to produce various interesting animation effects. Eye candy, to be sure, but useful and impressive eye candy.

Again, what I learned in doing the “About Box” immediately suggested interesting options for the main GUI. Originally, XRay was a complement to the Finder’s single “Get Info” window, which in the days of 10.0 and 10.1 was seriously underpowered. Also, users migrating from Mac OS 9 were clamoring for separate info windows for different items, so XRay was patterned after the Mac OS 9 “Get Info”. XRay information windows were supposed to be relatively large and well-readable while still being small enough to allow having several of them open.

But times changed. With 10.2 and 10.3 the Finder’s “Get Info” changed to a different format and it also became able to do formerly missing things like changing permissions and deleting stubborn files with Administrator authorization. I noticed that I very seldom had several windows open anymore, and that my usage of XRay’s permissions panel was also rare. Many users were asking for batch-mode operations which the one-window-per-file paradigm didn’t accomodate well. At the same time, my idea of writing plug-ins to allow XRay to examine the internals of different file formats was running into snags, both because of the limitations of my first plug-in API design and because of the smallness of XRay’s windows.

So the new XRay will have one large window instead of several smaller ones. In other words, it will follow the quite successful browser paradigm of applications like iPhoto and iTunes: lists of favorite items, a structured large (but collapsible) browser pane, and another structured+collapsible information pane. Exact details are still being worked out, so I can’t show a window image yet. However, one problem presented itself immediately: Apple’s guidelines suggest using a metal window for this sort of application, as indeed iTunes, iPhoto, the Address book and several others do. It turns out that I like the metal interface well myself, but most of my beta testers hate it with a passion. Making the interface a user preference was immediately obvious, but forcing the user to restart the application to change it didn’t seem right; unfortunately Cocoa windows can’t be changed after they are open.

Well, my experiences with the non-standard “About Box” immediately suggested a possible way to do user-selectable window themes on-the-fly, and after some surprising detours I’m happy to report that it seems to be working well. Of course, all user interface widgets have to change theme as well when the window’s theme changes, and as I had to do some non-standard widgets for the “About Box” anyway, it proved relatively easy to extend the new concepts to the whole UI. This in turn led to the possibility of developing an entirely new theme, which in turn caused me to investigate other parts of Cocoa I hadn’t had occasion to explore before…

The challenge in these cases is to do new widgets in a style that is immediately obvious and coherent with existing widgets, or even in a way that most people won’t even notice that they’re not standard. Looking through current Apple applications that use the metal interface I was surprised to see a wide variety of non-standard widgets; evidently Apple is using their own applications as a development laboratory, in the sense that the most useful new widgets tend to become standard interface items in subsequent system versions. Hopefully my own UI items will be unobtrusive in this way.

More later…

I still find time to fire up NetNewsWire every day or two and skim through a part of my blogroll. And it’s awesome to see the number, size and quality of posts on many of them. One of the things holding me back from posting a link or two every day or so is, frankly, lack of energy/chutzpah to even try to do something on that level.

That said, XRay 1.1 is in final testing, and will be released sometime next week. Whew.

As some of you may recall, I lost quite a bit of data to a runaway script sometime in March. Among other things, I lost parts of source code I was working on in XRay and in some other projects; some of that was recovered either from the erased drive or from scattered backups, but due to several other unfortunate circumstances, my only backup at the time was also unreadable.

Anyway, I’m happy to report that I successfully redid most of the work I was doing on XRay. Nearly all known bugs have been fixed in 1.1. (It should really have been called 1.0.10, but the vagaries of alphabetical ordering made my version-checking code in previous versions not recognize 1.0.10 as an upgrade…) What is missing from my original update work is a somewhat laborious routine to rebuild the Mac OS X LaunchServices cache.

If this is greek to you, skip this paragraph. The problem is, there’s no official Apple API to rebuild this cache, and I managed to do it in a somewhat unsupported and version-dependent way. Unfortunately, further testing revealed that the rebuild wasn’t reliably recognized by other parts of the system short of a full log-out/log-in cycle, and initiating this from inside XRay proved to be quite a pain. So this time I simply resolved to leave this out – it’s needed very rarely anyway – and if anybody absolutely needs to do it, I can e-mail in detailed instructions.

Otherwise, I’ve taken an important decision; namely, to throw most of XRay away and start coding “XRay 2” entirely from scratch. XRay was my very first Cocoa application, and some of the initial design decisions I made early in the process – now about 3 years ago! – are no longer appropriate for the current state of Mac OS X, or for my knowledge of Cocoa programming. In fact, updating XRay properly has become a slow and unreliable process and starting out fresh will, hopefully, make it rewarding again.

Despite this being a 2.0 version, I plan this to make a free upgrade for all registered users; however, for whoever migrates from 1.x, a hopefully not too annoying welcome screen will discreetly hint at the possibility, nay, the utter rightness of making a donation to my coffers for this effort. Otherwise, details are still hazy. Yes, the user interface will be quite different. There may be some sort of limited batch processing, beyond what’s already available, but nothing too extraordinary. Also, as the Finder’s “Get Info” window now does most of what I originally wrote XRay for, I see little sense in trying to duplicate its facilities needlessly. So, XRay will go further towards the implications of its name: to look below the surface, not only regarding hidden file attributes but also inside the file data.

Needless to say, suggestions are extremely welcome and should enough fellow developers be interested in writing plug-ins to look at file contents, I’ll set up a new forum to discuss technical details. In particular, plug-ins to dissect structured file formats – like resources, MP3 tags, QuickTime atoms, various executable formats and so forth, will be the next new thing.

More soon (I hope)…

CodePoetry and a bunch of others are pointing at this very long and interesting rant about developing for the Mac, by drunkenbatman.

It’s way too long to justify quoting any part of it; if you’re developing for the Mac, you must go read it (and the comments, too). I disagree with some of the conclusions – especially regarding Java and .NET – and the style is a little grating; I for one wouldn’t use slang like “prolly” outside of an informal e-mail or chat. Still, very recommended.

Rael Dornfest points out this article:

If you think all ”hackers” are computer criminals, think again: A new generation is reclaiming a creative, do-it-yourself approach to everything from home electronics to home improvements.

…The spread of hacker culture is very much related to the spread of technology, which now pervades almost every aspect of life. Among techsters, hackers are the good guys, as opposed to the malevolent cybercriminals to whom they refer as ”crackers.”

…Said (Rael) Dornfest: ”The difference between a hacker and consumer is a consumer says, ‘I wish it would work this way.’ A hacker says, ‘I’ve got a screwdriver and a few minutes.’ “

Well worth the read.

Needless to say, I’m solidly behind this definition, being a screwdriver/soldering iron/whatnot-wielding practitioner since early childhood.