Solipsism Gradient

10.6 is early …and circumstances conspired to make me late in checking (or, at least, ensuring) compatibility with it.

I just posted on the Quay support forum about the situation with Quay. Briefly, an interim 1.1.2 version should be out soon.

Klicko installs and runs with no problem on 10.6. However, it being a 32-bit control panel, System Preferences will restart every time it is run. Once you’ve set the preferences, that shouldn’t be too onerous, but I still plan to do a 64-bit version as soon as possible.

XRay will mostly work if you have Rosetta installed, but with the same restrictions as on Leopard: the file browser may crash (though, oddly enough, less than on 10.5); and changing permissions on folder contents will probably fail without warning. XRay is, unfortunately, recommended for 10.4 (Tiger) users only, and most of its functionality will be reincarnated in some form or other in the delayed-but-upcoming Quay 1.2.

Zingg! and Nudge are Finder Contextual Menus, which are not supported by Snow Leopard. Their functionality will also be implemented through plug-ins for Quay 1.2.

My US International keyboard layout has finally been incorporated by Apple into their standard list of layouts, so you won’t need to get it from here anymore. Yay!

Stay tuned for further announcements regarding Snow Leopard…

WWDC 2006 had two main topics: the new Mac Pros and Leopard. Regarding the Mac Pros, they seem quite competitive and well-built. I’m very content with my current iMac G5 (which I bought at last year’s WWDC), so I haven’t looked at them closely; desk space is important to me. By the way, it seems that Apple Brazil has just released the local price of the standard configuration, and it comes out to US$5400. Ouch.

Regarding Leopard, there’s a nice write-up at Wikipedia, so I won’t try to enumerate everything here.

All in all, I can say this was one of my best WWDCs yet. As I’ve said before, the timing was excellent. Apple has obviously made the most of the (unusual) June-to-August delay and from the developer standpoint all important stuff was in place. Most of the Leopard APIs seem to be well-defined, reasonably stable, and of course the tools are all in place. Xcode 3.0 and the new developer tools “just work”. In one Q&A session Chris Espinosa, was asked about the stability of the tools – whether developers should rely on them for new products, or should wait for the GM release – answered “we all use them daily for building Leopard, so they have to work well!”

So, this is important news for developers. Before, existing tools were used to build a new system and the next generation of tools came out with (or after) the GM release. Now, Apple has obviously been working on the new stuff iteratively; first versions of the new frameworks were used to build first versions of the new tools, then those were in turn re-used to work on the new frameworks. Certainly this has always happened to some extent, but I believe that this synergy between tools and frameworks has now hit an important inflection point.

Apple has clearly been working towards this for years. Mac OS X ‘s frameworks are now 4-way universal, containing binaries for PowerPC 32, PowerPC 64, Intel 32 and Intel 64 bits. Therefore, applications can now be built for all 4 environments, and all are fully supported by the new developer tools. This is a well-known capability of the Mach-O executable format by the way, not a new thing; NeXT applications were also distributed for several architectures, and the Virtual PC 7 executable has binaries optimized for 5 (!) different PowerPC variants.

Framework synergy is a marvelous thing. Apple has just released a short movie showing off CoreAnimation. The “city towers” effect in the second half can be now rendered in realtime on a MacPro – something that even two years ago would have been impossible. Looking very closely you can see that some of those squares are actually playing movies! But only a developer can fully appreciate the other important aspect: the code to generate this movie has shrunk down to less than 10% of what would have been necessary in Tiger.

Let’s talk somewhat vaguely (NDA mumble mumble) about how synergy might have made this happen in the CoreAnimation case. The MacPro has a faster, 64-bit CPU architecture, as well as faster video cards. 64-bit processes can use extra CPU registers and the new vector operations which seem to, finally, have equivalent power to the PowerPC G5’s AltiVec. The LLVM compiler is now used in the OpenGL stack to add a significant speedup (and this even for low-end machines!). Add in Quartz optimizations. Add in easy Cocoa support for all of these. Add in runtime efficiences introduced by Objective C 2.0. Add in new debugging and optimization made possible by implementing DTrace. Add in the ease of programming all this with less and more reliable code. Add in some extra stuff I can’t talk about… it adds up! And comparable gains are visible all through the new system.

At the risk of repeating myself, all this ho-hum talk about Leopard just being Spaces, Time Machine and some UI tweaks to iChat and Mail is so wrong. Granted that Steve Jobs had to show some non-developer news at the keynote, given the wildly unrealistic expectations. But, it really was a Developer Preview. It was released at the right time and to the right people in order to make sure that, whenever the Leopard GM comes out (my guess would be in January at MacWorld Expo), some hundred cool new applications will be available on the same day. And they’ll necessarily be Leopard-only; expect Leopard to be adopted by a significant portion of the user base in a very short timeframe.

Now to my own projects. I’d really love to have the upcoming XRay II to be Leopard-only, but that would delay release too much, and it doesn’t really need 64-bit capabilities. However, I’ll really need some fixes introduced in the last Tiger updates, so 10.4.7 will be the minimum supported version, which should be no hardship, as I can’t imagine anyone voluntarily staying with older Tiger versions. However, some of the stuff I’ve seen at WWDC has completely changed my plans regarding certain features and capabilities, so I’ll opt for implementing things in a way that might be a little constrained under Tiger but will really be much better under Leopard.

RBSplitView has been a marvelous experience for me. It’s been very widely adopted and even the Cocoa team has promised to take a look at it (no promises, of course). And it was very gratifying to be instantly recognized by many famous developers – of course my XRay II/RBSplitView t-shirt was intended to make this very easy! I’ve received lots of positive feedback and I’m working hard on implementing my own fixes and all suggestions. Hopefully I’ll have version 1.1.4 out in a very short time. This should be universal and fully compatible with Xcode 2.4. A 64-bit version compatible with the new Interface Builder will, unfortunately, have to wait until a more widely available Leopard beta comes out – I’m waiting for word from Apple about when it’ll be kosher, as I’ll necessarily have to include some new Leopard headers and APIs.

I have updated Nudge to be universal, and it seems to still be useful on Tiger for mounted network volumes. Expect the update to be available in a few days – I’m still doing some last-minute checking. Zingg! is, unfortunately, much harder to update at the moment. I haven’t touched it since 1.4.1 came out over 2 years ago, and the source code has been pushed out to some CDR backups – and the two I’ve found are, sadly, unreadable. I still have some hope of finding a copy someday (there’s a ton of stuff stashed away from my move), but don’t count on it. Recoding it from the ground up will have to wait for Leopard, where it’ll be much easier to do – there were some awful undocumented things I had to do at the time. Sorry about that. The USInternational keyboard layout will soon be repackaged in a way that (hopefully) will work around the “custom keyboard layout is randomly deselected” bug in Tiger. I’ll need to wait for a Leopard beta to come out to check if it’ll be upwardly compatible, though. I’m trying (again) to go through Apple channels to have it included with the standard system, perhaps this time it’ll work out?

I’ve finally solved a vexing problem that has been affecting version checks for my software.

Basically, checking for updates inside of XRay and Zingg! asks my webserver for a .plist file which contains the latest versions of everything, along with a brief message. On the server, however, this is actually a PHP script which also stores the user’s system version – which is appended to the URL – into a small database.

Since I changed over to DreamHost, my server has been set to gzip everything it sends if the receiver is capable of decoding gzipped files. However, for some time – not sure when that changed – this has messed up my version checking, and users would get a “website was unreachable” error. I did get some reports about this every couple of months, but always had attributed it to a network glitch somewhere… until I tried it myself and got consistent errors.

I read the .plist file directly using +[NSDictionary dictionaryWithContentsOfURL:]. Some combination of Cocoa, php and server parameters now causes the result to be gzipped, and NSDictionary doesn’t understand that format. Anyway, once I figured it out, I had to find a way to turn gzipping off for this particular file only, as I can’t change all the old software versions that are out there.

So, for now, adding this statement at the front of the php part of the file solved it:

header('Content-Encoding: UTF-8');

Strangely enough, rfc2616 says:

The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:

gzip…

compress…

deflate…

identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept- Encoding header, and SHOULD NOT be used in the Content-Encoding header.

…and that’s it. No “UTF-8” is mentioned, so why is it working now? I tried “identity” (before seeing the SHOULD NOT comment) and it had no effect at all. I suppose I should try to debug this on my local server adn see where the problem lies, but time is short…

I don’t plan to use this method in XRay II, so it’s not urgent. I’ll probably use Andy Matuschak‘s Sparkle, of which I’ve had good references.

Whew! I finally succeeded in downloading and installing 8A428, the “Golden Master” build of Tiger (Mac OS X 10.4). So far everything works great. And AAPL also closed up at $37.24… I’m happy.

I was just looking at my user’s version stats – that is, the versions recorded when XRay and Zingg! check for updates – and I’m amazed. Tiger came out officially on April 29th, yet April closed with a 10% adoption rate! And for May so far, late on May 6th, 52% of my users are already running Tiger!

For the record, 4% are still on Jaguar, 35% on 10.3.9, and 9% on other Panther versions. I thought adoption rates would be high, but this is beyond all expectations. It quite confirms my decision to make XRay 2.0 Tiger-only.

Also, RBSplitView 1.1.1 is in final testing and should be out tonight or tomorrow. I’m just polishing the docs right now, so look for it later…

Apple Cocoa

Well, this is progress.

Allume Systems just announced, at MacWorld that Ten For X Utilities Vol.3 is out.

Despite the name, it contains 14 utilities, three of which happen to be by your humble programmer . 3 out of 14 is a nice percentage… XRay, Zingg! and Nudge.

It costs $39.99 and all utilities are pre-registered, a pretty good value. Should you consider buying it, I remind you that the latter two programs are freeware and that donations are accepted…

I’ve just posted a new installment of my Interesting Times column, after quite a hiatus. This time, I’m commenting on the recent MP3Concept Trojan flap. Here are some highlights:

…Let’s see what we have so far:

– You can name an application anything and have it show any icon you wish. Always could.

– You can code an application to do anything, even harmful or deceitful things.

– The Finder will always show if it’s an application – but it can’t protect you from misleading icons.

– If you download such an application over a browser, file types, resource forks, or folder structures won’t be properly preserved unless it’s in an encoded form such as .bin, .zip, .sit or .dmg.

– If you get such an application as an e-mail attachment, most attachment formats will preserve resource fork and file type, but most e-mail clients will present an alert when you double-click on an application that came in as an attachment.

– Nevertheless, if there’s a deceitful document icon and an enticing name the user may double-click on the application even if there’s no extension at all.

…

What can the user do, then? Standard cautions apply. Don’t download applications from unknown sources. Check data files in the Finder to see if the “kind” field says “Application”. Don’t trust file icons on downloaded files. Don’t double-click on files you’ve downloaded; either drag the file onto the application you want to use it with or use the “Open With” contextual menu (or my Zingg! contextual menu to open it in a specific application. Don’t trust antivirus programs either, as they will either give you too many false positives or a false feeling of security. Disable automatic unstuffing, unzipping or running of downloaded items.

…What could Apple do? Options are limited here. Recall that this is not a Finder or Launch Services bug, so there’s no obvious fix.

…Summing up, a “social engineering” trojan application is not a new concept, but now that attention has been called to it, we may begin to see malicious implementations of it, more’s the pity.

Read the whole article if you want more details…

Kevin Schmitt posted a very nice review of Zingg! in his last installment of Ten Programs I Can’t Live Without (This Week, Anyway). Zingg! is in the company of programs such as Default Folder X, NetNewsWire Lite, SubEthaEdit, Graphic Converter and the Unsanity stuff, among others… very flattering. Thanks, Kevin!

Quick update.

A few hours after posting the lamentation below I found out how avoid the text cursor. Both selecting and editing have to be disabled. Turning editing on (as I do, briefly, when inserting new stuff) turns selecting on again.

Turning all that off messed up some other functionality but I’m happy to report it was all easy to fix, and I now seem to be where I should have been a month ago.

Ah yes, and the contextual menu itself turned out to be a piece of cake… most of the code from Zingg! and Nudge could be reused.

So I hope to have something publishable Real Soon Now™…