Nicholas Riley’s Weblog
Thoughts from a computer science graduate student,
medical student and Cocoa programmer (this week).

Skip over navigation
June 2003
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
May   Jul

made with
Click here to visit the Radio UserLand website.

NetNewsWire: More news, less junk. Faster

 

>
Monday, June 9, 2003
 
Over the weekend I made some progress with the most-requested feature in ICeCoffEE: hiding services you don't use.

I noticed a Cocoa/Carbon inconsistency while I was working on keyboard equivalent display. Displaying keyboard equivalents isn't as easy as it might seem: compare the above screenshot to the "Set Menu Keys" dialog in BBEdit to see what happens when you naively right-justify keyboard equivalents. Cocoa interprets service keyboard equivalents differently from Carbon and the documentation.

Here's the Services menu in the Finder (Carbon):

and in OmniOutliner (Cocoa):

Note that the same keyboard equivalent appears twice in the Carbon Services menu (?). All services get a Command-Shift equivalent in Carbon apps, which matches even the Cocoa documentation, whereas the case of the NSKeyEquivalent “default” in Info.plist defines whether the shortcut requires the Shift key in Cocoa apps. I'm attempting to implement the Cocoa behavior in ICeCoffEE since it matches what the user will actually see, but it's not made any easier by the apparent random assignment when two services have the same NSKeyEquivalent.

I've got a number of bugs to work out, and a few small promised features to add for 1.4. The code changes required to upgrade to APE SDK 1.3 were minimal, but I should be able to improve ICeCoffEE's launch-time friendliness by using some of the new features in 1.3. 4:17:54 PM | reply []

The Incredibles teaser shown before Finding Nemo is posted to Apple's site. No thanks to QuickTime Player for switching my screen resolution to 640x480; when I exited, I found my Terminal windows looking like this:

Didn't this work properly before? 1:43:16 PM | reply []
I'm completely addicted to the Safari bookmark sync. Camino/Firebird could one-up Safari by implementing roaming profiles (not just bookmarks, but history and preferences) which work, using WebDAV.

The only issue I've noted in synchronized bookmarks is those which refer to the Radio Web server. On byron, the Radio bookmarks point to 127.0.0.1:5335, etc.; everywhere else, they reference byron.sabi.net:5335. This would not ordinarily be an annoyance, but for two related problems.

First, Radio's gone into a funk where it won't accept posted forms from any IP address but localhost. This happened once before, then it mysteriously went away. I need to figure out what's going on.

Second, Safari doesn't authenticate reliably to Radio. For some HTTP connections (usually graphics), I have to reenter my password. I don't notice this problem with Konqueror, so it's likely Safari rather than KHTML and friends at fault.

Despite the great temptation of always-synchronized bookmarks, I'm still using Camino on my PowerBook. I can't wait for third-party interfaces to iSync to become available, so I can get the benefits of seamless synchronization without needing to use Apple's iApps. 1:18:49 PM | reply []


Looking for older (or newer) material? Click another date on the calendar at the top of this page.