Written: July 12th, 2007, 22:26 (UTC) By: omer
Progress lately has been moving in bursts. There are times during which I feel like there is not much for me to do at the moment, as I wait for people to look at my code and my patches before I apply them. So far, Patrick Luby (of NeoOffice) has supplied two patches for my code. Then, for one reason or another, a specific task becomes available (e.g., fixing mail merge, for which I got some helpful advice by Florian Heckl that let me start working on it), and I work on it until it is complete. Progress on the Address Book Integration over the past week has been:
- Premac/postmac fix (by Patrick Luby, posted to OOo issue 77591) - this patch includes "premac" and "postmac" headers around included Mac OS X headers to fix various conflicts between Mac OS X and OOo (I believe).
- Null headers patch (originally by Patrick Luby, with a slight modification by me, posted to OOo issue 79512) - this patch creates three crash-preventing checks for NULL values.
- multiple groups fix (by me, posted to OOo issue 79513) - this patch solves an issue in which groups with the same name in the Address Book don't show up in the OOo data source.
- mail merge fix (by me, posted to OOo issue 79514) - this patch forces the fields that could appear in an OOo mail mege template to be present and be at the beginning of the OOo data source. Because it modifies the way that the OOo integration sorts fields in the address book, it also includes a much cleaner version of the sorting algorithm.
- I also created a new version of the ABColumns program (originally presented here) to work with Cocoa instead of Carbon. The new version is called "ABCocoa." You might remember that this program provided the basis for the Mac OS X Address Book integration into OOo, and - although the integrated version is rather different at this point and has solved several bugs in ABColumns - a Cocoa version is still a significant step toward the Cocoa version of the integration into OOo. I decided to move ABColumns to Cocoa before the integration because I am waiting for a relatively stable version of the integration in Carbon before I start this process, but I still wanted to see if the move to Cocoa was possible and what sorts of issues would come up. ABCocoa should make that move, when it comes, a lot easier.
This work, if there are no problems with it, solves half of the issues presented in my last post, just leaving: Cocoa integration, commenting, and localization of labels. And, reading up on how localization of strings works within Mac OS X (specifically this article at MacTech), and testing things like genstrings, it appears that there is no way to specifically invoke Mac OS X's own localized labels directly (e.g., I cannot ask for the localized version of the constant string kABFirstNameProperty, at least not in Cocoa). It might be that there is some way to localize kABFirstNameProperty itself, but if there is, I cannot find it. It also may still be possible to use the Carbon function ABCopyLocalizedPropertyOrLabel, but I have not managed to use it successfully, and it is strictly for Carbon, so it couldn't be included in the Cocoa version. So, after a bit more testing, I might call the goal of localizing labels currently unachievable (for me), which would leave only two more goals (other than testing and debugging) : commenting and creating a Cocoa version. I'll let you know my progress!