GSoC2010 Status Update: Week 8

July 16, 2010

Ones may take various approach implementing AppleScript support in their Cocoa application. Generally, there are 3 approaches:

  • Subclass NSApplication and implement the functionality there.
  • Create a category of NSApplication and implement the functionality there.
  • Implement the functionality in a NSApplication’s delegate.

Before deciding which approach to take, I started digging through Camino’s source. This is because Camino is written in Mac-native and has a reasonable amount of AppleScript support already implemented. Thanks to Camino’s well organized source tree, I quickly found what I needed: ScriptingSupport.mm.

Camino’s approach to implementing AppleScript support is a mix of the 2nd and 3rd approaches above. One learns from the code that MainController is NSApplication’s delegate. Thus, it has the chance to handle Apple events (AppleScript included – which is mainly Key-Value-Coding, KVC calls). It implements this method to specify which keys it wishes to handle. Then, for keys it does not handle directly, it passes the keys to other classes here. The rest of the file specifies categories (a way of adding functions to a class) of existing classes to handle AppleScript events.

Applying Camino’s approach to Thunderbird is not straightforward because of its cross-platform nature. Initially, ones is interested in finding out which class is NSApplication’s delegate in Thunderbird. A simple [NSApp delegate] (added somewhere it may be called) shows that MacApplicationDelegate.mm is the delegate. This must be the right place to start hacking. After making some changes, I was able to expose a simple boolean property through AppleScript. However, there are still some concerns about making changes to MacApplicationDelegate.mm because it is compiled into libxulapp_s.a library.

This is the first important step in implementing AppleScript support in Thunderbird. The next step is to design what should be supported through AppleScript. At first, I plan to start with “composing a new email message” use case, but this is impossible now, due to Thunderbird’s different mechanism of handling/sending messages. The only way now to create a new message is through a Compose window. Therefore, I’ll probably be exposing the address book in the next few weeks.

Lastly, I have also integrated QL-Enabler into the source. The repo can be found here. Simon has kindly package a Thunderbird 3.2a1pre (10.6 SDK) with QuickLook enabled here. *Note* the build is not stable yet. It works nicely when you read the email in the message pane. But if you open the mail in the standalone window, then it sometimes crash when you quicklook the attachments. Thanks a lot, Simon 😀

Advertisements

GSoC2010 Status Update: Week 6

July 2, 2010

After version 1.0 of the extension is available for download, Simon has tested it with a few file formats:

  • RTF -> Works. Shows file icon instead of the preview (highly due to missing of a RTF QuickLook plugin).
  • PDF -> Works in most cases, but sometimes it crashes. If  the same PDF file is tried the next time, then it works. (Random crashes)
  • JPEG -> Works perfectly.
  • RAM (Real Player) -> Shows the icon (highly due to missing of a RAM QuickLook plugin).
  • MP4 -> Works in most cases, but sometimes it crashes. (Random crashes)
  • TXT -> Works.
  • HTML -> Works.

Several Apple logs collected shows that two functions are causing the problems, QlXpcom::Release() and QlXpcom::URLInDict().

However, QlXpcom::Release() should not be called while Thunderbird is still working. It is called only when Thunderbird is exiting. Thus, the crash should not occur at all while TB is still working. This may be due to instability in 10.6 SDK build. The crash in QlXpcom::URLInDict() is highly due to passing strings around in XPCOM. Moreover, Mozilla XPCOM is undergoing major changes. The new API changes the way how a XPCOM component registers itself. Because my extension makes use of  XPCOM component, I will have to make changes to conform to the new API. However, the tree is expected to be burning for the next few weeks, thus my performance will be greatly affected.

Next week I’ll be reading various Apple documentations on implementing AppleScript support in Cocoa application.