Solipsism Gradient

Fast update: autosaving subview states is now working in the RBSplitView, and I fixed a couple of bugs. It proved harder to do than I supposed, but seems to working quite well.

I wrote before the trip:
Rainer Brockerhoff wrote:

Time for another update on XRay 2.0.

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

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

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

As I took my old iBook on the trip, I was able to devote some time every day – after the “official” touristy duties – to reimplementing the split view. (The official class name is now “RBSplitView”, by the way.)

The view implementation itself was actually quite straightforward, although complex; it was the IBPalette that took most of the time. It took quite a bit of testing and checking unsupported APIs to find out a way that works for most of the expected Interface Builder actions, and in the end I managed to do it all by using only the “normal” APIs.

If you’re interested, the current version of RBSplitView and the associated IBPalette will always be downloadable here. Xcode 1.5 running on Panther is required.

Highlights:

• Full reimplementation of split view, not a subclass
• Not a 100% drop-in replacement for NSSplitView though
• Uses container subviews for each split
• Allows easy nesting of split views with automatic 4-way thumbs
• Source and IBPalette available under modified BSD license.

Still to do:

• Autosaving of subview state
• Separate documentation
• 100% glitch-free working in Interface Builder

Comments will be extremely welcome!

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.

Yesterday I received an e-mail from someone asking a question about Nudge. I replied on the same day, as I always try to do. My e-mail bounced with the following helpful message:

Hi. This is the qmail-send program at vega.planetarium.com.br.

I’m afraid I wasn’t able to deliver your message to the following addresses.

This is a permanent error; I’ve given up. Sorry it didn’t work out.

<somebody@rsandk.com>:

Connected to 24.196.135.162 but sender was rejected.

Remote host said: 550 5.7.1 mail from spam friendly countries with admins who overwhelmingly ignore or bounce complaints not welcome here

In the past, I’ve seen various concise wordings of the “550 5.7.1” message; usually something to the effect that my address was on some blacklist or another. A polite request to the provider’s postmaster address usually worked.

But from this one I gather that they’re now unconditionally rejecting all e-mails from Brazil. Isn’t that rather excessive…? Should I sue about restraint of trade, or whatever?

So if you’re a user of one of my products, and I don’t answer your e-mail, you may want to switch providers – or post here on the support boards. Sorry about that.

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…

XRay 1.1 is out, and fixes several bugs. Here are the release notes.

Now back to ye olde drawinge board to start version 2.0. News at 11…

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