A couple of weeks ago I noticed some complaints out on the net about the Mac OS X 10.3 (Panther) Finder not updating its windows. Later on, I myself noticed that it happens sometimes.
The thing is, today the Finder usually waits passively for notification that one of its items has been changed. And not all applications post that notification. Yes, it polls certain folders at strategic times, but apparently not in a way that covers all eventualities.
In Panther, parity with FreeBSD 5 introduced the so-called kqueue mechanism (PDF file), but unfortunately it’s still experimental, and the Finder doesn’t use it. I suppose 10.4 will implement that…
…in the meantime, I wrote a little Contextual Menu called “Nudge” and sent it to some people who complained about that problem. Mosty, there were no replies. Since it worked for me, I let it rest until today, when I noticed a MacFixit article about this very same problem. So, I took a few hours off to recompile “Nudge”, have a half-hearted stab at designing an icon for it, and publish it. So here it is (VersionTracker listing).
Preliminary reports indicate it works in most situations. Icon donations are accepted – I tried to draw an elbow (or fist) whacking a folder, but results were unsatisfactory .
Yesterday, January 24, the Mac turned 20.
|In 1984||In 2004||Increase|
|Macintosh 128||Power Macintosh G5||A lot!|
|8 MHz 68000||2 GHz PowerPC 970 (two)||512x|
|128KB RAM||512MB RAM||4096x|
|400KB floppy||700MB CDRW/4.3GB DVD||1792x|
|No hard disk||160GB hard disk||infinite|
|9-inch black and white display (512×342 pixels)||17-inch LCD color display (1280×1024 pixels)||7.48x|
|21.375K screen RAM, shared||64MB screen RAM, dedicated/td>||3066x|
|230.4Kbps LocalTalk||1Gbps Ethernet||4551x|
|One mouse button (it’s all you need)||One mouse button (it’s all you need)||1x|
|$2495 (1984 dollars)||$2533 (1984 dollars)||1.015x|
Meanwhile, Andy Hertzfeld and the rest of the original Mac gang are collaborating to write the definite, unsurpassable Mac Folklore website. Not to be missed by any Mac fan! It even has a RSS feed ! (Thanks to “Daring Fireball” John Gruber for the link.)
Whole Earth magazine – spawn of the amazing Whole Earth Catalogs, source of the WELL, first to mention in print the Gaia Hypothesis, the Internet, Virtual Reality, the Singularity and Burning Man (or at least so the legend goes), the place where folks like Stewart Brand, Kevin Kelly and Howard Rheingold found their voices, and where a whole generation of young commune-kid geeks like myself learned to dream weird – is no more.
This is sad news. Sometime in the early eighties, I found a copy of the Whole Earth Catalog at a bookstore, took it home, and practically learned the whole thing by heart. I wrote down a long list of book recommendations, and on my first trip to the Bay Area in 1984 I went to several Berkeley bookstores and to the original Whole Earth Access shop, then shipped back about 100 Kg of books. I also drove up to Sausalito, to the Co-Evolution Quarterly (as it was called then) offices, and subscribed to the magazine – and came back several times over the years to renew.
Later on the magazine underwent some name changes – first to Whole Earth Review, then to Whole Earth Magazine – and several editorial and ownership changes. Its financial situation had always been uncertain, and at some point I neglected to renew my subscription. I did buy the Last Whole Earth Catalog, and then the Millennium Whole Earth Catalog, with the white cover, and it still is prominently displayed on the bookshelf behind me.
For myself, at least, the era of print magazines is practically over. Back in the eighties I regularly bought at least 30 magazines each month – now I’m down to one regular (Wired, whose print edition still is oddly much more interesting than the online version), and the occasional magazine bought for reading on the plane. Whole Earth Magazine’s online edition, too, somehow couldn’t recapture the magic. Kevin Kelly’s Cool Tools is more successful in that, but has a narrower focus.
Let’s hope someone finally figures out the magic formula to bring the magazine back to life.
Slava of Unsanity posted part I of a good article about being successful in what he calls “Indieware” (formerly known as shareware) – reasonably-priced software developed by small companies, or individual developers such as myself.
First thing to ask yourself is how useful your software would be? Would you use it? Some people I know are making software they don’t use personally and try to sell that (OK, “day job” work doesn’t count, I am talking about indieware here and in the rest of the article). My vague point is that the product will not sell good enough if you do not use it yourself daily, or see no real use for it, or are not inspired enough to use it. Call me superstitious, but how you feel about your software creation is more or less how users will feel about it, except they will have less love and tender feelings than you do towards it.
Some younger developers I directed to the article found this point too self-evident, but it’s not!
Successful indieware developers “get it.” They’re Mac users to the core. Mac users are picky. They have high standards. Mac users care about the whole experience – is your site great, icon cool, and application dock-aware? “Where’s my damn AppleScript support!” they’ll ask. Do your keyboard shortcuts meet their expectations? Is your toolbar pretty? Do you even have a toolbar?
If you’ve been using a Mac for five years or more, you “get” this already. You’re a picky sonofabitch too, and you despise crap applications,especially if they’re your own. Indieware developers spend an inordinate amount of time thinking about the above issues and more during development – great UI doesn’t just fall from the sky. Slava says that new developers should not “ be ashamed to spend a week or more in the planning stage.” I say they should be ashamed (and will be shamed) if they only spend a week. Planning never ends. Mac users expect nothing less.
Couldn’t have said it better myself.
Well, the details caught up with me very fast. By late afternoon, one user e-mailed me a crash report for Zingg! 1.4. After dinner, another user e-mailed me with a simple way to reproduce the crash. 30 minutes later it was fixed, so 1.4.1 has just been published.
This sort of thing is very embarrassing… neither I nor my handful of beta-testers thought of doing the particular choreography that causes the crash. Namely, one has to:
Actually, any application which has exactly 8 or 9 letters and which starts with any hexadecimal digit would cause the crash, but only DropStuff (and, for Jaguar users, Disk Copy) fall within these parameters. At least of the applications I have here.
OK. Why can such a weird combination of circumstances trigger a crash? The answer lies within the way Contextual Menu Plugins work. Briefly, the plugin is a loadable bundle with a few precisely defined entry points. When the user control-clicks (or right-clicks) on some item(s), the “Examine Context” entry point is called with a list of AppleEvent records – one for each item. Such a record resolves to a file path or URL. So I have to loop over the list and by a somewhat complex logic return another list containing parameters for the items I wish to have inserted into the Finder’s contextual menu.
These parameters unfortunately are somewhat restricted; I can pass the menu item’s text, a so-called command-ID, and a few attributes for the item. Later on, if the user selects one of my menu items, the “Handle Selection” entry point is called, this time with that item’s command-ID, and the same list of records that was passed to the first call I described. At this point, I decode the command-ID to get back which application I should open, and I re-decode and encode the record list to pass the list of items to be opened to that application.
All very well, but how to attach application icons to each menu item? This demands more complicated hackery. First, I had to register yet another entry point: a “Menu Event Handler”. Unfortunately, this gets called for the main contextual menu and for every submenu – not just for my own little submenu! So first I had to detect my own submenu among the others; not easy when contents are wildly variable. I finally hit upon the trick of setting an invisible first item with a special encoded title.
Also, for some weird reason, at the point this handler gets called the command-IDs haven’t yet been attached to the menu items – so there’s no way of telling directly to which application each item corresponds. So I simply encoded that information into the menu item texts I return from the “Examine Context” entry point, instead of putting in the actual application name. When the handler sees such an encoded text, it decodes it to obtain the application path, and from that gets both the name and the icon, and puts them into the menu item.
What I conveniently forgot is that the handler gets called every time the submenu is opened – not just when it’s built. So the second time around, the handler dutifully tries to re-decode the menu items again – only now they already contain the actual application names! And for certain names, the decoding will actually proceed with invalid data and crash later on. So, a simple first-time flag and it was fixed. For some reason, in my tests I never played around with the mouse, opening and closing the submenu…