|
| View previous topic :: View next topic |
 |
| Author |
Message |
|
|
# 02 Jan 2009 22:09:13 Year++ |
 |
|
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. |
|
|
|
|
|
| # 18 Dec 2008 09:00:25 Klicko 1.0.1 (123) |
|
|
Well... let's hope this one will last more than a few hours...?  |
|
|
|
|
|
| # 17 Dec 2008 20:12:41 Cocoa musings pt.2 |
|
|
One of the nice things Objective-C inherited from C is the switch statement. If you have set different tags in all your menu items, you often find you can do things like:
| Code: |
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
switch ([menuItem action]) {
case 1:
...
case 2:
...
}
return YES;
}
|
Those tags have to be set in Interface Builder, and you probably will have an enum somewhere to use symbolic constants instead. However, the standard C switch() is restricted to integer values; you can't switch on strings or selectors. So, if you don't want tags and need to switch on the menu item's selectors, you'll have to do:
| Code: |
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
SEL action = [menuItem action];
if (action==@selector(firstAction:)) {
...
} else if (action==@selector(secondAction:)) {
...
} else...
return YES;
}
|
Bearable if you have two, or even four or five cases, but what if there are dozens? Or suppose you have to compare strings instead of selectors:
| Code: |
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
NSString* title = [menuItem title];
if ([title isEqualToString:@"firstTitle"]) {
...
} else if ([title isEqualToString:@"secondTitle"]) {
...
} else...
return YES;
}
|
Not that it's recommendable, in practice, to compare menu item titles, but it's a good example.
Well, there are other ways to make this more readable, or even more efficient. But here's one neat way to convert a group of strings into integers for use in a switch(). First, let's write an utility C function to do so:
| Code: |
NSUInteger CaseCodeForString(NSString* string) {
static NSArray* array = nil;
if (!array) {
array = [[NSArray alloc] initWithObjects:
@"zeroth string",
@"first string",
@"second string",
@"third string",
...
nil];
}
return [array indexOfObject:string];
}
|
Note the standard lazy allocate-once trick of declaring array static, initialize it to nil, and test before using. Anyway, this function will return 0 if you feed it @"zeroth string", 1 for @"first string" and so forth... and return NSNotFound if the string isn't in the array. So you could, in our last example, do:
| Code: |
- (BOOL)validateMenuItem:(NSMenuItem*)menuItem {
switch (CaseCodeForString([menuItem title])) {
case 0:
...
case 1:
...
}
return YES;
}
|
If there are many strings, this will be faster than a series of isEqualToString: calls; this is because NSArray uses a hash table to find the index of a particular object, and only goes into the actual string comparison if the two string's -hash methods return the same value. |
|
|
|
|
|
| # 17 Dec 2008 16:10:01 Klicko 1.0.1 builds 119 and 120 out |
|
|
| Pushed out 119, then literally a second later got a bug report, had to do 120. Sorry about that. |
|
|
|
|
|
| # 15 Dec 2008 11:38:19 Re: Cocoa musings pt.1 |
|
|
In my post on event taps, I mentioned the following code to get a global event tap:
| Code: |
CFMachPortRef tapg = CGEventTapCreate(kCGAnnotatedSessionEventTap, kCGEventTapOptionDefault,
CGEventMaskBit(kCGEventLeftMouseDown)|CGEventMaskBit(kCGEventLeftMouseUp),
ProcessEvent,NULL);
|
This taps the event stream at the "annotated session" point (hence the kCGAnnotatedSessionEventTap parameter). Basically, this means that the event has already been analyzed as to destination application, and you can ask the passed event directly for that application's process ID. This is was I was using in Klicko.
Unfortunately the docs don't mention another step that takes place while "annotating" a mouse-down event: apparently, if the click was on a window's title bar (not elsewhere in the window), the owning process is brought to the front before the tap sees the event! Klicko's processing varied depending on the clicked-on window's and the owning process' state, so I was seeing different results depending on the click location - title bar or inside the window. Worse, a workaround I needed to do to bring non-main windows to the front for background processes wouldn't be applied at all if the user clicked on a title bar!
A more subtle consequence was that I was intercepting (and discarding) mouse clicks, while the system was expecting the click that brought the process to the front to actually arrive at the process... the result was that, while the menu bar changed to the process, its windows would remain in the back.
After beating my head against this wall for several days, I was rereading the CGEvent docs again for ideas and noticed that I hadn't tried applying a global tap before event annotation:
| Code: |
CFMachPortRef tapg = CGEventTapCreate(kCGSessionEventTap, kCGEventTapOptionDefault,
CGEventMaskBit(kCGEventLeftMouseDown)|CGEventMaskBit(kCGEventLeftMouseUp),
ProcessEvent,NULL);
|
Note the kCGSessionEventTap parameter. This meant that I had to discover the owning application's process ID myself (instead of asking the mouse-down event directly). Premature optimization strikes again; I'd selected the annotated tap just to avoid doing these steps.
At any rate, I immediately discovered that I now could properly intercept clicks anywhere, discard them, and do process and window activation as I wanted to. Well, almost; there was still some redundant window activation to do, as Carbon and Cocoa apps seem to still have some residual differences in that regard. I'll be filing bugs at Apple about some of these things. |
|
|
|
|
|
| # 15 Dec 2008 11:15:27 Klicko 1.0.1 (113) hopefully final |
|
|
This latest build of Klicko fixes all known bugs and edge cases, and some memory leaks. Hopefully this will be the last build for a long time.
In my next post I'll explain some technical details. |
|
|
|
|
|
| # 08 Dec 2008 19:25:47 Travel updates |
|
|
Oops. I just realized I forgot to update my travel maps. Here's the current world map (44 countries visited):
and here's zooming in on Europe (28 countries visited):
 |
|
|
|
|
|
| # 08 Dec 2008 12:30:42 Re: Klicko and Quay bug fixes |
|
|
Found an error in the code signature for both Klicko and Quay, induced by the presence of a newer signing certificate for iPhone apps.
So I pushed out new builds for Quay 1.1.1 (285) and Klicko 1.0.1 (103). Klicko also has other small improvements; see the release notes. |
|
|
|
|
|
| # 07 Dec 2008 21:17:33 Klicko 1.0.1 (97) |
|
|
I decided to rev the version number, not just the build number, for this release.
The main reason is that now we have a slight difference (and a UI difference) on first run. Klicko needs "access for assistive devices" turned on in the System Preference, and complains if that's not the case. However, now you have two options:
1- turn "access for assistive devices" on, and click "Continue"
2- click "Authorize" and enter your administrator password.
In the latter case - and this will work only if you installed Klicko inside the main /Applications folder - Klicko will set itself to run in a privileged group that can use the Accessibility API without that option.
Beyond small internal optimizations, the other notable feature in 1.0.1 is that you can change the icon, if you don't like it. Just make or copy your own icon, paste onto Klicko's icon in the Finder's "Get Info" panel, and there it is - you can do this even while Klicko is running! If your icon has a 16x16-pixel version, that one will be used in the menu bar.
Of course, if you have an icon for Klicko that's better than the default one, send it in! It shouldn't be too hard to do...  |
|
|
|
|
|
| # 06 Dec 2008 11:42:54 Re: Cocoa musings pt.1 |
|
|
Just saw Rob Keniger's Wrapster plug-in for Coda, an interesting use of event taps; it's a plug-in that intercepts key events for its master application.
The version I looked at (1.2) uses a global tap and checks if its master application is active:
| Code: |
if(![NSApp isActive]) {
return event;
}
|
Of course, it would be conceptually more reliable to obtain the event's destination process PSN and test against that; but the best way would be to tap the current process like this:
| Code: |
ProcessSerialNumber psn = {kNoProcess, kCurrentProcess};
CFMachPortRef tapg = CGEventTapCreateForPSN(&psn, kCGTailAppendEventTap, kCGEventTapOptionDefault, CGEventMaskBit(kCGEventKeyDown), ProcessEvent, NULL);
|
Global event taps are a great tool, but they're also easy to abuse, and I suppose that in a year or two we might have dozens of utilities or plug-ins tapping events; the actual results might be dependent on the order they run or load, for instance, and overall responsiveness might suffer. Therefore, please make absolutely sure that you need a global tap to do whatever you want to do, that it takes as little time as possible, and that it does careful parameter checking.
One great application to test event taps (and to check their presence) is Event Tap Testbench. It's author, Bill Cheeseman, has helped me a lot with subtle details of both event taps and the Accessibility APIs; thanks Bill! Do also check out their other products.
Rob tests if Accessibility is enabled by trying to create a tap and seeing if it succeeds. While this works, I think it's easier to do it like this:
| Code: |
if (!AXAPIEnabled()&&!AXIsProcessTrusted()) {
// error dialog here
}
|
The first call checks if Accessibility is enabled in System Preferences; the second checks if your process is allowed to set a key tap even with Accessibility disabled. To achieve this, you must (from a process running as root) call AXMakeProcessTrusted() on the tapping application's executable - this will take effect on its next run.
In the case of Klicko, it taps only mouse button events, for which Accessibility doesn't need to be on; however, it uses the Accessibility APIs to check out details about the clicked-on windows. Some people dislike turning Accessibility on in System Preferences, so a future version of Klicko might use AXMakeProcessTrusted() to avoid this; this means asking the user for an Administrator password and running a separate tool, like Quay does. I'm still evaluating the trade-offs for that: it precludes running Klicko from ~/Applications or from the disk image, adds to the application size, and the user has to navigate an extra dialog on first run.
Update:Klicko now uses AXMakeProcessTrusted().
Last edited by Rainer Brockerhoff on 08 Dec 2008 12:45:56; edited 1 time in total |
|
|
|
|
|
|
|
You cannot post new topics
You cannot reply to topics
You cannot edit your posts
You cannot delete your posts
You cannot vote in polls
|
|
(RSS 2.0)
