Solipsism Gradient

Quay 1.1.2 (293) is out, and supports 10.6 (Snow Leopard).

Progress report on Quay 1.1.2.

I’ve got it mostly running on Snow Leopard now. There are at least two small things that aren’t working yet though, and I want to implement a couple of feature requests that should be fast and easy. All in all, it shouldn’t take more than one more day, or two.

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…

Ted Landau of MacFixit fame interviewed me last Wednesday and the interview is up now on the Mac Observer. Many thanks to Ted for this opportunity to get word out about the upcoming Quay plug-in SDK.

A few small corrections:

…I also had a job working with the Macs installed at a medical equipment company…

what I said was that, at that company, I designed medical equipment based on a Mac-like architecture (68K processor and all) and used a Mac as a development workstation.

…The staff here at the WWDC have always been helpful, although probably a bit more so back in the 1990’s than now…

I actually was referring to the people at developer relations, not at WWDC, and the situation is reversed; they’re a bit more helpful now, since in the 1990’s they hadn’t quite gotten their international act together, and I depended more on personal acquaintance with some of the Apple folks.

Well, since I last wrote, a reasonably definite version of Klicko has been published (1.1.1 build 207) and I deemed the supporting code to be mature enough to serve as basis for the next version of Quay. So, since then, I’ve been busy on that.

On June 4th I’ll be arriving in San Francisco – WWDC starts on June 8 – and hopefully by then I’ll have an early alpha version of Quay 1.2 (or maybe 2? II?), and of the Quay Plugin Developer Kit as well. Stay tuned.

Also, yikes. 26 days without posting! I plead temporary insanity brought on by tax filing time, and Twitter – the latter being a more convenient outlet for short links and thoughts.

Anyway, taxes are filed and we’re now having a short working vacation in the hills of Petrópolis, an old town north of Rio de Janeiro. Dorinha is taking a short English immersion course (excellent BTW), and I’m coding again, yay!

I’m patching up some loose ends in Klicko in preparation to cloning its preference panel for the next version of Quay, as I’ve mentioned before. While doing that, I’m also trying to refactor my code into a tighter and more readable form. Some of that might be interesting…

For instance, the automatic update checker has a dialog button to “Open System Preferences” and this should go to the Klicko preference panel. Now, System Preferences may already be running but with another panel selected; in any event, the Klicko panel should be opened and ready for the user to see update details. There are several ways to accomplish this.

Most people probably will consider, at first, writing an AppleScript to open System Preferences and then select the Klicko preferences panel. This is unnecessarily complex, and I’ve looked at several solutions. The simplest one-liner to do so from Cocoa would be:

[[NSWorkspace sharedWorkspace] openFile:@"/full/path/to/my.prefPane"];

There’s a non-obvious down-side to that: NSPreferencePane is generic and may be implemented by other apps for their preference plug-ins. Someone’s application might use it and declare .prefPane in its Info.plist. This would in my opinion be a mistake, in that double-clicking or running the code above might (or not) open that other app instead of System Preferences!

The solution I finally hit upon uses Launch Services to open the correct application with the preference panel, like this:

FSRef ref;
if (LSFindApplicationForInfo(0, CFSTR("com.apple.systempreferences"), NULL, &ref, NULL)==noErr) {
   LSApplicationParameters parms = {0,kLSLaunchDefaults,&ref,NULL,NULL,NULL,NULL};
   NSArray* args = [NSArray arrayWithObject:[NSURL fileURLWithPath:@"/full/path/to/my.prefPane"]];
   if (LSOpenURLsWithRole((CFArrayRef)args, kLSRolesAll, NULL, &parms, NULL, 0)==noErr) {
      // success!
   }
}

This code first finds the System Preferences app by its bundle ID, and makes a FSRef for it. The FSRef is then pointed to from the LSApplicationParameters structure, and passed to LSOpenURLsWithRole; this will run System Preferences if it’s not already running, and tell it to open the panel.

It’s tempting to pass the panel’s path as an argument inside of LSApplicationParameters. This does indeed work if System Preferences is not already running, but unfortunately it’s ignored if it is.

An hours-long outage somewhere inside my ISP made me re-evaluate the idea about a reachability transition callback. It seems to be reliable enough when the local network is involved, but when the clogged pipe is several routers away, it can go down – and never go up again.

So what I’m doing now is, while the network is down, retry with a direct reachability test every half hour or so; of course if the callback says it’s back up, I tear that timer down again. Seems to work OK.

Several interim builds of Klicko went up in the meantime, implementing this and other small changes. The latest one is now in testing; build 1.1 (201) will implement full keyboard accessibility and VoiceOver support. At least in the preferences panel part; the background process is still mouse-oriented, and I don’t foresee disabled people needing any of the Klicko functions. Still, it’s good practice since nearly all of the Klicko panel code will be re-used in the upcoming rewrite of Quay, and there it will certainly be useful.

It’s been a while since the last post, but I’ve finally gotten past the boring parts of the new Klicko System Preference pane & background process. The latter is actually a per-user Launch Agent. I’d used launchd before in the last Quay implementation, but didn’t fully understand what I was doing.

Well, I still can’t claim I fully understand all, but I’m definitely getting better at this. As soon as Klicko 1.2 is out and working (hm, maybe that should be the other way around?) I’ll back-port everything I learned to Quay.

One important part of messing around with launchd agents is that you have to set everything up just so – permissions of the executable and of its containing folders, as well as of the controlling plist if it’s a global agent; and you have to run launchctl to load (register) the controlling plist with launchd. Only then, and if the conditions inside the plist are satisfied, launchd will run your agent for you.

Uninstalling your agent, usually for putting an updated version in its place, must also be done carefully. You have to unload it if it’s loaded (even though it may not be running at the time) before swapping in the new executable and plist. Ideally, to avoid wasting time, there should be an easy way to test if your agent is properly loaded – the user might have unloaded it manually, or whatever. Unfortunately, the only “official” way to do so is to run launchctl again, passing in the “list” parameter, and parsing the output; not ideal.

However, there’s a primitive API in place in <launch.h>, and in fact launchctl uses this API itself to communicate with launchd. Still, there’s no documentation about it; only some sample code. Also, there’s this recent reply on the launchd-dev mailing list:

Right now the <launch.h> API is only rated for
daemons checking in with launchd (ala SampleD).
It is not really designed for job management.
Rather, we recommend that folks do their job
management by fork/exec of launchctl.
…
Quinn “The Eskimo!”

Still, I thought it would be interesting to use this API to check on the agent; after all, if something fails you’ll get an error back, and nothing will be messed up. So here’s the code for doing so:

#include <launch.h>

static id GetFromLaunchData(launch_data_t obj);

static void Launch_data_iterate(launch_data_t obj, const char *key, void* dict) {

   if (obj) {
      id value = GetFromLaunchData(obj);
      if(value) {
         [(NSMutableDictionary*)dict setObject:value forKey:[NSString stringWithUTF8String:key]];
      }
   }
}

static NSDictionary* GetFromLaunchDictionary(launch_data_t dict) {
   NSMutableDictionary* result = NULL;
   if (launch_data_get_type(dict)==LAUNCH_DATA_DICTIONARY) {
      result = [NSMutableDictionary dictionary];
      launch_data_dict_iterate(dict, Launch_data_iterate, result);
   }
   return result;
}

static NSArray* GetFromLaunchArray(launch_data_t arr) {
   NSMutableArray* result = NULL;   
   if (launch_data_get_type(arr)==LAUNCH_DATA_ARRAY) {
      size_t count = launch_data_array_get_count(arr);
      result = [NSMutableArray arrayWithCapacity:count];
      for (size_t i=0;i<count;i++) {
         id obj = GetFromLaunchData(launch_data_array_get_index(arr, i));
         if (obj) {
            [result addObject:obj];
         }
      }
   }
   return result;
}

static id GetFromLaunchData(launch_data_t obj) {
   switch (launch_data_get_type(obj)) {
   case LAUNCH_DATA_STRING:
      return [NSString stringWithUTF8String:launch_data_get_string(obj)];
   case LAUNCH_DATA_INTEGER:
      return [NSNumber numberWithLongLong:launch_data_get_integer(obj)];
   case LAUNCH_DATA_REAL:
      return [NSNumber numberWithDouble:launch_data_get_real(obj)];
   case LAUNCH_DATA_BOOL:
      return [NSNumber numberWithBool:launch_data_get_bool(obj)?YES:NO];
   case LAUNCH_DATA_ARRAY:
      return GetFromLaunchArray(obj);
   case LAUNCH_DATA_DICTIONARY:
      return GetFromLaunchDictionary(obj);
   case LAUNCH_DATA_FD:
      return [NSNumber numberWithInt:launch_data_get_fd(obj)];
   case LAUNCH_DATA_MACHPORT:
      return [NSNumber numberWithInt:launch_data_get_machport(obj)];
   default:
      break;
   }
   return nil;
}

static NSDictionary* GetFromJobLabel(NSString* job) {
   NSDictionary* result = nil;
   launch_data_t msg = launch_data_alloc(LAUNCH_DATA_DICTIONARY);
   if (msg&&launch_data_dict_insert(msg, launch_data_new_string([job fileSystemRepresentation]), LAUNCH_KEY_GETJOB)) {
      launch_data_t response = launch_msg(msg);
      launch_data_free(msg);
      if (response&&(launch_data_get_type(response)==LAUNCH_DATA_DICTIONARY)) {
         result = GetFromLaunchDictionary(response);
      }
      launch_data_free(response);
   }
   return result;
}

To use it, just call the last function like this:

   NSDictionary* dictionary = GetFromJobLabel(@"com.yourcompany.agentlabel");

and examine the dictionary. If it’s nil, some error happened, or your agent isn’t loaded into launchd.

If you do get a dictionary back, it will be autoreleased, and the “Label” key’s object should be equal to the string you passed in. There are two more keys that might be interesting to check: “PID” will contain your agent’s pid if it’s running, and will be missing if it’s not; and “LastExitStatus” will show you what your agent’s main() returned on its last run.

Note that most of the code above is actually based on the launchd source, converted to use Foundation objects instead of CFTypes.