Solipsism Gradient

We’re back, and I’m catching up on mail, sorting pictures, the usual post-trip routine. Normal life should resume next Monday.

PS: gasp.

Early tomorrow we’re leaving for a short (6-day) trip to Tocantins, or more specifically, the Jalapão State Park.

It should be good to unwind a little from 2008, and I plan to bring back some good pictures. For the first time in several years, I won’t take a laptop; there’s supposed to be very little infrastructure at the campground. Hopefully the withdrawal symptoms will be mild…

Unfortunately, this means I’ll be unable to answer email, do product support, or even approve new users here at the forum. All will back to normal on the 16th, so please bear with me.

While most of yesterday’s Macworld keynote was uninteresting to me personally – I rarely use any of the updated software, and don’t have iTunes store access – the new 17″ MacBook Pro was mostly as I expected: the additional space was used for a larger battery, and more USB ports.

It was gratifying to see Apple’s battery page practically repeat my reasoning about the infrastructure (and wasted space) needed to accommodate removable batteries. (See also Chuq Von Rospach‘s discussion of the issue.) Not that the 15″ model’s infrastructure is quite as large as they show in the video, of course… but it makes the point well.

Judging from the pictures, the hard drive is inside a space that’s almost exactly square. In theory, they could have rotated the drive 90 degrees and made the battery 30mm wider, for maybe 10% more capacity. So why didn’t they do that? It would have meant extra weight, a beefed-up charging circuit, more heat dissipation, and either a larger power supply (which already is at 85W) or a longer charging time.

I don’t doubt that we’ll see incremental upgrades for iMacs and Mac minis rolled out without much fanfare over the next two months. My tip for the iMacs is that they’ll use the exact same front and back bezels as the corresponding-sized displays, with only a 10mm shim module inserted to accommodate the CPU and drives. The advantage, of course, would be that you could add a second display to your iMac with the exact same styling, screen parameters, and height; a good selling point. It would be a no-brainer for the 24″ model. I’m not sure that a 20″ display from Apple would sell well by itself, but if it used bezels and nearly all components from the 20″ iMac, it might be price competitive, and the styling advantage would be worth paying a few bucks extra. A 28″ iMac has been rumored; would that, then, mean that the current high-end 30″ display would be shrunk to 28″ too? I hope we’ll have the answer soon.

Finally an interesting test to open the year. Can you think logically?

I got 14 out of 15 right. The last one (which I got wrong) is declared “controversial” in the answers. Bah.

It’s been a couple of weeks since my last post, but I haven’t been idle. Well, a few of the holidays excepted, of course. Here’s what’s on my radar for the new year, or at least for the first months.

I’ve finally had time to look at the SnowLeopard (Mac OS X 10.6) beta. Can’t say much about it, except that there are interesting and significant changes in the infrastructure – important for programmers. I really hope that, once out, a majority of users will adopt it.

A consequence of seeing the 10.6 APIs is that I decided to do a serious rework of Klicko and Quay, so they’ll be ultimately easier to migrate to 10.6 and a 64-bit environment. Klicko inherited a lot of code, and I’m really glad that I decided to do it as a training exercise, since I’ll very soon back-port much of that back to Quay, after enhancing and optimizing.

If all goes well, Klicko 1.1 will be out soon. I’ve got all but installation and updating procedures done. Most notably, it’s now a System Preferences panel that installs a background process. While this is a departure from the easy-to-run, simple-Cocoa-app mantra, splitting this type of application into a faceless background process and a foreground GUI will soon be mandatory for all practical purposes, and there are advantages; for the user, once properly installed and configured, Klicko will “just work” automatically and in the background, and use very few resources.

One new Klicko feature was requested by several users (and others who have emailed me in the past). There will be a (configurable) preference to have the window’s “zoom” button do a true maximize – or at least attempt to, not all applications will support it properly. While I find the importance that Windows users attach to maximizing everything all the time a little puzzling, trying it out convinced me that it’s useful now and then. I always maximize NetNewsWire, Xcode, and a few other application windows, for instance. I also decided that it may be useful in pointing users that are new to the Mac to shareware software in general and to my own applications.

Once that is done – hopefully with very few build updates – it’s back to reimplementing everything I learned into Quay (probably 1.2). I’m not decided whether that will become a preferences panel too, but it may be possible. More importantly, I’m now pretty fluent with the event tap and accessibility APIs that both Quay and Klicko use.

The major new feature of Quay will be that Quay menus will also pop up for Finder icons. Ultimately, I’d like to make this work in any and all Finder window modes – icon, list and column – and in all circumstances where the Finder’s own contextual menus pop up. I’ve done some preliminary testing and it looks like it might be possible. There are a few edge cases where I’m not sure that I’ll be able to compute the correct path for the icon.

Anyway, if all works as planned, I’ll be able to introduce more flexibility through plug-ins. A plug-in would get a file or folder handed to it and would produce either a popup menu, or an information window. This would allow me to finally declare XRay entirely defunct (it already runs very poorly on Leopard), and replace it with many small, specialized plug-ins. My older contextual menu plug-ins, like Zingg! and Nudge would also be trivial to rewrite as Quay plug-ins.

A similar, much more ambitious plug-in scheme, was planned for XRay II, and I can reuse some of that code… there are still some complex issues to decide, however. Opening the plug-in interface to other developers is of course what I’d like to do, but licensing, updating, keeping plug-ins from interfering with each other will be very tricky.

All in all there’s lots of ideas to implement and this should keep me busy for most of the year. I’m not considering going into iPhone/iPod development for now; there’s a glut of $0.99 applications and the way the App Store is working seems overly opaque to me.

More soon! Stay tuned.