Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts tagged Zingg!

Version tracker

No comments

No, not that VersionTracker

As regular readers might recall, my last versions of Zingg! feature an improved update query that allows me to tabulate which Mac OS X version the client is running. Preliminary results show that roughly 3 out of 4 Zingg! users are running Mac OS X 10.3 (Panther). Nearly all Panther users are running 10.3.2… but curiously, about 15% of the Jaguar users have not yet updated to 10.2.8, the last Jaguar release. These figures may be distorted by the fact that most users who check regularly for new versions will of course also upgrade to the latest Mac OS X as soon as possible.

There are no figures for 10.1.x users, as there’s no way to distinguish them from users of XRay, which doesn’t yet have the new version-tracking code. In any event, other surveys have found that they number under 10% (some say 5%) of active Mac OS X users. I don’t plan to support 10.1.x for any new version of my products, and indeed no longer have a Mac that runs it available for testing.

Starting with Jaguar, Mac OS X has facilities for weak-linking system calls and for easily checking if certain calls are available or not. This makes writing software that runs on both older and newer systems much easier. Hopefully Panther adoption rates will be such that I’ll soon be able to release Panther-only software.

Positive feedback on Nudge is mounting. There’ve been over 3000 downloads so far in 3 days, beating XRay‘s 2800 and Zingg!‘s 2000+ downloads over the whole month!

c.k. over at 3650 and a 12-inch links to Nudge and suggests:

Apple should send him a rather large donation for providing a solution to one of their major Finder bugs…

Not that I would mind… 😆

I’m sure that the Apple folks are working hard at this. However, from the rumor sites, it seems they’re stretched rather thin at the moment, working on Mac OS X 10.3.3. Also, Nudge is more of a stop-gap solution; I certainly wouldn’t want it made permanent.

The links and referrals stemming from John Gruber’s article are becoming too numerous to list. This shows, once again, how word of mouth is important for Mac developers. I also found a flattering side-effect at Ryan Wilcox’s h4ck3r+=boi:

Brent Simmons has created a Mac Software Business mailing list on Yahoo Groups.

The description: “This group is for small, independent Macintosh developers who want to talk with other developers about the business of Mac development. Questions on pricing, packaging, advertising, e-commerce providers, and so on are on-topic. Note that this list isn’t a vehicle for promotion: announcements and press releases are off-topic.”

The members of the group include some heavy hitters in the Mac Software industry, in addition to Brent: Rainer Brockerhoff, Michael Tsai, along with a cast of additional others.

Brent’s mailing list seems to have great potential; if you’re a shareware/indieware developer, I recommend it highly.

Re: One more…

No comments

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:

  • set either DropStuff or Disk Copy to “always/override”;
  • set the “Show” popup to either “No comment” or “Styled name”;
  • open the contextual menu and the Zingg! submenu;
  • without releasing the mouse, go outside the submenu to close it;
  • still without releasing the mouse, go back and reopen the submenu. Boom, as Steve Jobs is fond of saying.

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…

One more…

No comments

After a few days of concentrated effort, Zingg! 1.4 is out the door.

There were several things left out from the recent 1.3 release and I felt it worth the effort to learn how to do them. Putting icons into the contextual menu and a better user interface for the configurator’s application list were the two most troublesome implementations. I’ll write up some details later in the week.

Zingg! out…

No comments

Well, Zingg! 1.3 is out.

It took a few days longer than I expected. First there were some more bugs and suggestions; then I tested it on Jaguar and two things didn’t work at all; and finally I had a run-in with configuration problems for my local database server. If you’re wondering about the last item, it’s because Zingg! 1.3 now incorporates the latest version of my online version-checking code… which incidentally feeds me the user’s version of Mac OS X for my statistics.

As I type this, the VersionTracker page counts 387 downloads. If past stats are any indication, that means about 800 or 900 downloads total… many people go directly to my site. My site statistics run every midnight, so I have no exact figures yet. Meanwhile, 206 of those people (let’s say 25%) used the new version-checking code. 204 are on Mac OS X 10.3.2, 2 are on 10.3.1. No earlier versions at all! I’ll have to check whether this is a bug or a reliable statistic…

Then again, this is good news, as I’d like to do Panther-only software in the near future. I’ll try and hurry up the next version of XRay to get stats from those users, too.

The Jaguar incompatibilities were quite puzzling. The Zingg! Configurator relies on a main NSTableView to show a list of applications. I wanted to allow the user to sort the table by any of the 4 table columns. The standard way of doing this, by clicking on the column headers, seemed simple to implement. Since I used NSURL objects to store the application names and paths, I subclassed this to store a complete table row in each object and then used the standard NSArray sortedArrayUsingSelector: method to sort this in different ways. It worked on the first try on my Panther development machine… but then in Jaguar it threw an exception indicating that my subclassing wasn’t working at all.

This was complicated by the fact that I’ve migrated all my projects to Xcode, so I couldn’t use a debugger on the Jaguar machine… but I finally found some hints that the NSURL internal workings had changed significantly from Jaguar to Panther – apparently it used to be a class cluster, but wasn’t anymore. To save time, I changed from a is-a to a has-a pattern for my table row object, and this worked again.

Then I ran into a Jaguar bug: the delegate tableView:didClickTableColumn: method isn’t always called, unlike in Panther. The workaround is to turn on the option to allow column reordering (by drag&drop) – I thought it kind of useless but found no other way.

Then (after already uploading the disk image) I had to go back and rewrite the docs for the changes… c’est la vie. At least it’s out now and no bug report’s arrived so far…

Re: Off we go…

No comments

Tomorrow morning the vacation’s over. Whew. It’s been marvelous: no interruptions, good food, beach runs after sundown, lots of coconuts and peace to work on my software; and terrible: heat, unrelenting sun, mosquitoes, constant Axé music thumpa-thumping along somewhere in the background, spotty Internet access and the general discomfort of being away from home.

The good news is that, as seems to become traditional over the Christmas holidays, I found time to do a new version of Zingg!, with lots of new goodies. Expect it in a couple of days; I just need to do some more testing and of course, constant Internet access to do all the publishing, notifications and hands-on support for early adopters.

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2022 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.