GreenRecycleBin

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 😀

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.

June 25, 2010

June 21, 2010

• Single attachment preview now integrates into Thunderbird.
• Temporary files are ensured to handle correctly when Thunderbird (cleanly) exits.
• Going to add QuickLook option to attachment context menu, and support for multiple attachments preview (slideshow).

June 22, 2010

• Fix a bug where control to QLPreviewPanel is lost when a new window of Thunderbird is open. Now, the last request (among several ones) to QLPreviewPanel is ensured to have the control.
• Adding support for multiple attachments preview (slideshow)

June 23, 2010

• Support for multiple attachments (slideshow) is available
• Going to add support for hotkey (spacebar), and clean up the code

June 24, 2010

• Support for hotkeys is added.
• Code cleanup perform.
• Prepare the testing suite (including a compiled release version of Shredder using 10.6 SDK, and the extension itself).

June 25, 2010

• Testing suite is ready and uploaded. Waiting for feedback from developers.
• md5 31D092B859EE580D9F54BC915F2A061C, download here.

June 18, 2010

June 14, 2010

• Research about compiling comm-central using 10.6 SDK
• Successfully compiled my XPCOM component on 10.6 SDK
• Integration problem due to Shredder doesn’t register the new component

June 15, 2010

• Successfully compiled comm-central using 10.6 SDK -> Shredder
• Successfully integrated XPCOM component to Shreeder -> Now able to open QLPreviewPanel in Shredder
• If your XPCOM is not registered with Shredder, try adding your_lib.dylib to the components/components.list in Shredder.App

  

June 16, 2010

• Add File -> Attachments -> <Specific attachment> -> QuickLook
• Coding and debugging functionality for single-attachment preview in QuickLook

June 17 – 18, 2010

Debugging shows these problem:

• My class is not *registered* in the Responder Chain. Therefore it cannot take control of the QLPreviewPanel because – (void)acceptsPreviewPanelControl never get called.
• Difficulty in dealing with Mozilla internal string data types (ACStirng, AString). Converting to const char* for passing to Obj-C function is not reliable, result differs from time to time.

June 11, 2010

I started this week by trying out David’s tutorial on Linux and Mac. The tutorial compiled successfully on Linux (with a small additional step to the tutorial). If you’re following the tutorial on comm-central build, before building your component(s), you should “mkdir obj-tb-debug/mozilla/extensions/firstxpcom” (assuming you are at @TOPSRCDIR@). Then you will be able to do a “make” in obj-tb-debug/mozilla/extensions/firstxpcom to generate the header(s).

Unfortunately, the same process on Mac isn’t as successful. I had a hard time compiling a Thunderbird debug build using 10.6 SDK. Besides the burning tree, my usual .mozconfig doesn’t seem to work. However, with a sample .mozconfig from Nomis101, I finally had a working debug build. The next step is to compile my XPCOM component under this new build to make use of QLPreviewPanel class added in 10.6. My goal for next week is implementing some basic functionality for QuickLook in Thunderbird, starting with being able to open a QuickLook panel and display a single attachment preview.

June 4, 2010

At the beginning of second week, I finished my reading on Jeff’s “Working without a nib” series. Although all the experiments are on Leopard (which is not current anymore), one can learn many things out of the series. While some people prefer the nib-approach (isn’t the framework expecting you to do so?), Jeff pointed out some inconvenience using nib. First of all, you can not search/diff a nib file, thus it is hard to see which changes in the source code may break the nib. Secondly, for the same reason, merging from version control with nibs is frustrated. Lastly, there are times in which “it’s simply easier to create the UI programmatically than to use a nib”. In conclusion, if you find yourself stuck in one of these situations, maybe you would like to give “nib-less” programming a try 😛

The rest of the second week was spent on researching XPCOM technology. Although XPCOM is widely used in many softwares (including Mozilla products), there is just too little guide on this technology. And the situation is much worse for XPCOM on Mac. What seems lacking is a simple step-by-step tutorial that *just* works. Luckily, Blake pointed me to David’s XPCOM tutorial. Another good guide is here, although it didn’t make full use of all the helper macros. Next week I will try David’s tutorial on Linux and Mac as a starting point to writing my own XPCOM components.

May 28, 2010

I have spent most of my first week on reading Cocoa Programming for Mac OS X (Aaron Hillegass). This book helps me a lot on familiarizing myself with Xcode, Cocoa, and (most important) Objective-C because it is my first time developing on Mac-platform. I’m currently on Chapter 8 and planning to finish the book soon.

My first goal was to open a QuickLook preview panel in a Cocoa application. It was easy to open once in a Cocoa application with the help of QLPreviewPanel class which was added to Mac OS X v10.6 and later. However, this method requires an Cocoa application with .xib file(s) while Cocoa support in Mozilla doesn’t use .nib (Mozilla UI is in XUL, and it is translated to Cocoa elements on Mac OS X through cocoa-widget). It was the reason I decided to work on a little experiment trying to open a QuickLook preview panel from a command-line application (which I believe is what Mac developers mean for “Tools”). This takes me a lot of time because a Cocoa application is not supposed to work the way you want without a decent .nib file (and also lacks of discussion on this matter). Eventually, I was able to make the panel appear, although the application went into an infinite loop soon after that, refusing to handle any key/mouse events. I will look more into this problem next week.

My small experiment takes me to Jeff’s “Working without a nib” series which gives insight about whether this approach is realistic and how it may be done correctly. I will go through his series next week because I think it may give me more clues on my problem.

Lastly, due to recent power loss, I have completely lost a few working days this week. Therefore, I will help to work extra time next week to catch up. Hope this situation improves soon!

Personal Details

• Name: Le Duc Khoi Nguyen (Daniel)
• Email: GreenRecycleBin@gmail.com
• IRC: Libras2909: on #nus, #maildev

Quick Look

Quick Look is an innovative technology shipped with Mac OSX that allows users to skim through the content of a file without actually opening it. Quick Look works even if you don’t have the application that created the document. Moreover, Quick Look is also capable of playing movies. Moreover, using Quick Look in Mail and iChat allows users to view multiple attached photos as a slideshow and add them to iPhoto library with ease.

We can find a lot of Quick Look plug-ins on http://www.qlplugins.com. Quick Look plug-ins enable Quick Look to generate preview for many different file types which are not supported by default.

Quick Look saves Mac OSX users time skimming through documents’ content. If we integrate Quick Look support successfully into Thunderbird, providing similar Quick Look’s features in Mail, more Mac OSX users might be willing to switch to using Thunderbird as their daily email client.

Proposed Idea

As mentioned above, we have already had a reasonable amount of support for Quick Look plugins on the Internet. What left to be done is to integrate Quick Look into Thunderbird.

The proposed idea is to implement Quick Look as a dynamic library (or a framework). Then the dynamic library can be loaded using ctypes feature. Following this approach, Quick Look support may be implemented in Firefox as well. For Camino, we can update the patch for bug 405358 to move from using undocumented API, which is available under Leopard only, to the new API available under Snow Leopard.

Apart from the need of portability, another reason I consider implementing Quick Look support as a dynamic library is the need of calling C-function in Javascript. Currently, the only way I know that enables calling C-compatible functions from Javascript is using ctypes. According to the ctypes API page, ctypes can handle Cocoa framework. Thus, there is a high chance that the proposed approach will work.

Detailed Implementation Approach

Showing preview of a particular attachment

Add a menu entry saying “Quick Look preview” to File → Attachments → [a specific attachment name] → Quick Look preview. The code resides in function addAttachmentToPopup()

http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1838

Also add support for preview when user presses “spacebar” after selecting an attachment

Showing multiple attachments as a slideshow

Add a menu entry saying “Quick Look slideshow” to File → Attachments → Quick Look slideshow. The code resides in function addAttachmentToPopup()

http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1838

Also add support for preview when user presses “spacebar” after selecting multiple attachments

Then from there, use ctypes to call C-function exported from the dynamic library.

The interface will look something like this:

AttachmentItem.h

#import <Cocoa/Cocoa.h>

@interface AttachmentItem: NSObject {

NSURL* onDiskURL;

// Other relevant attributes go here

}

–      (id) initWithURL: (NSURL*) onDiskURL; // this is exported

// Other relevant methods go here

@property(readonly) NSURL* onDiskURL;

@end

AttachmentList.h

#import <Cocoa/Cocoa.h>

@interface AttachmetList: NSObject {

NSMutableArray* attachmentList;

// Other relevant attributes go here

}

–      (id) addAttachmentItem: (AttachmentItem*) item; // this is exported

–      (id) deleteAttachmentItem: (AttachmentItem*) item; // this is exported

// Other relevant methods go here

@end

Quicklook.h

#import <Cocoa/Cocoa.h>

@interface Quicklook: NSObjectDelegate {

}

–      (IBAction) togglePreviewPanel: (id) previewPanel; // this is exported

–      (void) setAttachmentList: (AttachmentList*) list; // this is exported

–      (void) keyDown: (NSEvent*) theEvent; // this is exported to handle “spacebar”, will call tooglePreviewPanel()

Methods marked as exported will be available to the ctypes interface to be called from Javascript.

So whenever the user requests a preview by selecting from the menu, or by selecting attachment(s) and press “spacebar”, all the AttachmentItem objects are initialized and added into the list. The final result will be a pop-up Quick Look window having all the previews of all the attachments selected. When the user presses “spacebar” again, the Quick Look window is closed.

Skill set and Project Preparation

First of all, I possess the ability to read and understand foreign code in several languages. Doing research in security-related subjects, I have been reading code in many different languages (which is listed under my skill set) ranging from source code to assembly level. Therefore, I can understand code written by others well, and possibly re-use it in an effective manner.

Secondly, I have been working as a volunteer developer for Mozilla Foundation for one semester. The two products I’m working on are the famous web browser, Firefox; and Thunderbird – email client. This opportunity is offered as module CS3108 in my university, with Gary (nth10sd: on #nus, #maildev) being the instructor. Because of that, I am familiar with Mozilla development methods. I know how Mozilla community uses bug tracking system, mailing lists, wikis, IRC and blogging to collaborate. All these activities are introduced by Gary throughout the course, and they are also part of the course’s requirement. Thus, I am very much a participant in that.

Because the programming environment for this project is Mac OSX, I’ve read and tried all the examples from “The Objective-C Programming Language” book, which can be found on Apple Developers’ Network. Thanks to my exposure to many different programming languages, I have been able to pick up this new language during the last few weeks.

I have also spent a week to research about this project. I found a solution using private framework in Leopard. However, I realized that this approach doesn’t work on Snow Leopard. After discussing with Jeff (jeff: on #camino), I have started looking into the new Quick Look API which is officially supported by Apple in Snow Leopard. Taking into consideration the cross-platform design of Thunderbird (and Firefox), I decided to implement the solution as a dynamic library. I have been working on a demo of this, but due to time constraint (it is the end of the academic year here at my university), therefore I haven’t finished it yet.

Why do I want to join Mozillia community?

Mozilla is an icon and pioneer among open source organisations, and definitely an organisation I would be proud to be involved with. Having begun contributing to the community (although small) , I would like to contribute more and more to the community as time goes by. This may also serve as an example to spread more awareness about open-source spirit in my university, as CS3108 Mozilla project (and Gary) has been doing over the last 3 years. If you need any additional information, feel free to contact me at GreenRecycleBin@gmail.com or Libras2909: on #nus, #maildev.

Mentors

Blake Winton (bwinton) is my official mentor for this project. Besides, Gary (nth10sd) is my back-up mentor.

Note

The proposed idea and/or implementation details may change throughout the course of this project. Currently, I’m looking into developing a XPCOM module instead.