njr 3.0

The OS X version of the NCIDpop network caller ID client, originally written by Alexei Kosut, has not seen much development in a while, and had fallen behind the Windows version. In August I added a call history window, network change robustness, localized date formatting and reverse lookup support. NCID’s maintainer has been pretty busy, but he’s now integrated the changes in the official release.

And if you’re wondering “why use NCID when I already have caller ID?” If you have SIP service (e.g., Vonage) at home, NCID gives you caller ID on the first ring on every computer display in the place. Since I get pretty frequent calls from people I don’t want to talk to, such as Spanish-speaking bill collectors who won’t take no for an answer, it’s been a great help in reducing my stress when the phone rings.

11:14 AM | Computing, macOS
No Comments

Since releasing AntiRSI 1.4njr2 I’ve made a couple more minor releases.

1.4njr3, released on November 5, fixes some graphical rounding issues reported by Andy Reitz; the times were displayed as 3:01, 2:00, 2:59, etc. I was really surprised I never noticed this myself.

1.4njr4 shows the break window in all Spaces on Leopard; of course you could do this with the Spaces preference pane, but doing so by default makes sense. It also stops AntiRSI from getting focus when you hit the “Postpone” button (Cocoa’s API for this is…interesting). Or, if you have AntiRSI set to force itself to the front during breaks, it’ll bring your previous app to the front when the break is finished so you can resume work.

I’ve made some Spaces-related changes for Pester, too, and will try to get beta 8 released one of these days. Happily, my research is going really well at the moment and I don’t want to disturb my focus.

Download AntiRSI 1.4njr4 here, or just use the “Check for Updates…” item in the AntiRSI menu if you’ve already got my version of AntiRSI installed.

11:00 PM | Computing, macOS
No Comments

Pester 1.1b5 is out. If you’re wondering where betas 1–4 went, they were released privately…in 2003. Looking back at my weblog posts from May 2003, I see my comment about my parents “finally finishing up renovations on their house in Boston”—four years later, they’re still living in a single room of that house, though they continue to make steady progress on fixing the disaster left by their contractors.

For various reasons I didn’t pick Pester back up until this weekend, because NSDateFormatter broke natural language date parsing for Pester 1.0 in Leopard. Pester 1.0–1.1b4 ran on Mac OS X 10.1 or later; Pester 1.1b5 requires Mac OS X 10.4 or later. It was a bit sad to rip out painstakingly developed workarounds for old Cocoa date parsing bugs, but good to see that the new ICU-based formatters basically work, even if they completely lack any natural language parsing ability.

In an effort to get something usable on Leopard released, this version has some features disabled because they aren’t stable enough yet (QuickTime playback, speech), don’t work at all (dock bouncing) or are untested (wake from sleep). The user interface is still mostly what I came up with back in November 2002 (wow, Jaguar really was that ugly).

Among the changes that aren’t from 2003 are my first use of Sparkle:

Subsequent updates should therefore be simple.

Back to the reason for this update: NSDateFormatter in pre-10.4 mode used to understand “tomorrow”; in Leopard, it doesn’t, despite being documented as doing so.
There seems to be a severe lack of open source libraries for natural language date parsing—all I found was chronic (Ruby, English only); jchronic (Java port of chronic, English only) and Date::Manip (Perl, multilanguage).

I chose Date::Manip.

Yes, this means Pester now embeds a Perl interpreter.

Perl’s embedding API is interesting, but it works, and aside from the memory usage, nobody has to know. I don’t actually have non-English parsing in this version yet, because I ran into some weird bugs in Date::Manip; I’ve emailed the author but haven’t heard back yet.

I’m otherwise in the middle of the final work for my PhD, so I can’t guarantee 1.1 final will come out soon, but I think it’ll be less than 4 years!

10:45 PM | Computing, macOS
3 Comments

Onne Gorter’s AntiRSI is a Mac OS X application which reminds you to take periodic breaks from typing. Along with my beloved IBM model M15 keyboard, it’s essential to my getting any work done at all.

However, AntiRSI had some problems. The animated progress bar displayed during breaks sucked CPU like crazy, causing problems if I was watching a video at the time. Breaks kept getting prematurely reset because AntiRSI thought I was typing when it was a program like VLC calling UpdateSystemActivity, trying to avoid triggering the screensaver. Finally, the break window was just plain ugly—look at those poorly antialiased corners.

The last problem was more of a missing feature. While programming, I spend enough time thinking that I’m generally pain-free even if I work all day; unfortunately, debugging, writing and system administration can be much more typing-intensive, so I have to limit my daily typing time in aggregate, but AntiRSI didn’t keep track of it.

Over the past few years I’ve fixed these issues, and since my previous emails offering patches have gone unanswered, thought the result might be useful to others: download AntiRSI 1.4njr2 if you’re interested.

Some screenshots:

If you have a Mac and don’t like AntiRSI, try Time Out: it’s much more customizable, but takes over the entire screen, making it unusable for me. According to a VersionTracker review, it also hogs CPU during breaks.

For Windows and X11, check out Workrave; it’s great, includes a session timer and even comes with network support if you use multiple computers.

10:33 PM | Computing, macOS
2 Comments

While taking a break to work on ICeCoffEE today, I discovered an annoying internationalization bug.

First, some background. Since version 1.4, ICeCoffEE has let you hide items in contextual Services menus. Peter Hosey covers the feature nicely here.

Service menu items can be localized, like almost everything else in Mac OS X. The service provider apps include one or more language translations for their item names. The user configures a list of languages in order of preference in the International System Preferences. And the service-invoking application—the one from which you pull down or pop up the Services menu—also has a list of languages in which its user interface is localized.

Mac OS X makes the (sensible) choice that the service-invoking application’s user interface language dictates the language of all text in that application. But the fact that we’re dealing with ordered lists of languages, rather than individual languages, makes things a bit more complicated. Let’s take an example:

Your user interface language preferences are, in order, Japanese, German and English.

(Those also happen to be the languages I understand in ascending order of proficiency, with a gigantic gap between Japanese and German.)

Service menu item A has Japanese, German and English localizations. Item B has only German and English.

Say the app you’re running has only an English localization. Items A and B both appear in English.

What if your app has a Japanese localization? Item A appears in Japanese, but item B appears in German, even if the app has no German localization.

I’m guessing (have not completely verified) that OS X picks a list of potential service menu item languages by looking at the user’s preferred language list, starting with the user interface language of the current application.

What’s the bug? ICeCoffEE’s configuration sheet is hosted in System Preferences. When looking for a list of filter-able services, ICeCoffEE asks System Preferences for its Services menu and saves your choices according to the displayed item text. See for yourself:

% defaults read net.sabi.icecoffee ICServiceOptions
{
    ChineseTextConverter = {ICServiceHidden = 1; }; 
    "CocoaMySQL-SBG" = {ICServiceHidden = 1; }; 
    "Define in OmniDictionary" = {ICServiceHidden = 1; }; 
[...]

I did this because it seemed to be a WYSIWYG method of filtering, but it means that the user interface language of System Preferences influences what service names you see. If an item is also localized in a different language, it won’t get hidden.

I’ve never received a report of this bug. However, if it affects you, I can suggest two workarounds.

1. Edit the preferences property list yourself. The format is pretty simple, but I don’t recommend this. If you break it, you get to keep both pieces.
2. For every user interface language you use, launch System Preferences with that language at the top of the preferred list, and select the localized service names for that language in ICeCoffEE’s preferences. This assumes, of course, that System Preferences is localized in every language for which a service item you want to hide is localized. At worst, you will end up with something like this, where ICeCoffEE’s interface is in German and the service names are in Japanese:

   

   (Sharp-eyed people may notice two changes in the screenshot above, which hint at features coming in ICeCoffEE 1.5 :-)

I plan to fix the bug by doing something like option 2, adding the text of every available service menu item localization to the ignore list. It makes things more complicated because I currently store hidden services hierarchically, such that if you disable the submenu, everything inside it goes away; however, it’s possible that different localizations of service names will have different submenu structures. (Yuck.) This method also breaks if a newer version of an application adds a service name localization, but simply opening and closing the ICeCoffEE configuration sheet should fix that problem.

There are other ways I could handle this. I could store the bits used to define a service (NSMessage, NSPortName, etc.) but that would mean a lot more work to do when filtering the service list without scanning the disk as Service Scrubber does. Or I could canonicalize to English before filtering, which conflicts with applications that have no English localization, or applications like Monolingual which delete localizations—although deleting English is often unsafe because it’s the ultimate “fallback” language.

10:35 PM | Computing, macOS
No Comments