Development:Summer of Code 2007:AppleScript:Proposal

Synopsis

This project will make Camino a good scriptable citizen of the Mac OS. It will improve scriptability in Camino and provide a new way to extend the browser using AppleScript.

Benefits to Community

Camino's stated goal is to deliver the power and flexibility of the Gecko rendering engine in a native Mac OS X application. Unlike the cross-platform Firefox, Camino is able to leverage OS X technologies, such as the Keychain for password storage and Address Book for filling out forms. One of the Macintosh's strongest technologies is AppleScript, but at the moment Camino provides very little AppleScript support.

This project will bring AppleScript support up to the level of the rest of the Camino application, staying abreast of other Mac browsers' support. In particular, OmniWeb's scripting dictionary provides substantially more capability to scripts, allowing access to individual tabs (not just to windows) and to bookmarks. This project will bring similar capability to the Camino dictionary, opening the door to more sophisticated uses of Camino.

Deliverables

At the end of the project, Camino's scriptability will provide scripts with access to windows, tabs, bookmarks, and possibly other Camino features based on community discussions. Camino will also allow users to run scripts from the toolbar using new toolbar items.

Details

At the moment, the Camino suite of the dictionary is very limited, and some parts of it (such as "application's windows") yield unexpected behavior (such as returning nonexistent windows). The current suite's classes look like this:

 Class: application [inh. application (Standard Suite)] 
     Contains: 
         documents 
         windows 
 Class: browser window [inh. window (Standard Suite) > item (Standard Suite)] 
     Properties: 
         URL (Unicode text, r/o) : Current URL 

I would like to re-implement the suite with the following classes:

 Class: application [inh. application (Standard Suite)] 
     Contains: 
         windows                -- excluding nonexistent windows 
         browser windows 
 Class: browser window [inh. window (Standard Suite) > item (Standard Suite)]
     Contains: 
         tabs 
     Properties: 
         visible tab (tab, r/o) : The tab currently visible in the window 
         URL (Unicode text) : Current URL 
         source (Unicode text, r/o) : Source of the window's current page 
 Class: tab [inh. item (Standard Suite)] 
     Properties: 
         URL (Unicode text) : Current URL 
         name (Unicode text, r/o) : Tab's displayed title 
         source (Unicode text, r/o) : Source of the tab's current page 

This gives us access to either all the windows or specifically to the browser windows. Browser windows now expose tabs, which have a URL and a name and also provide the source of the page. Browser windows also provide a reference to the currently visible tab. Its URL and source are conveniences for "visible tab's URL" and "visible tab's source", respectively, for the sake of users who do not use tabs. (For more on this part of the proposal, see Bug 314061).

Furthermore, I would like to expose the bookmark catalog through AppleScript. This would be done in the obvious way: by mapping the Cocoa bookmark classes to AppleScript classes. This was implicitly requested by a user and relayed by Simon Fraser in Bug 156078, Comment 4.

Finally, to make this support more useful, I would like to implement script toolbar items as OmniOutliner does. For every script in Library/Script/Applications/Camino, Camino would generate a toolbar item to run that script. This has proved immensely useful in OmniOutliner; an entire application (Kinkless GTD, http://www.kinkless.com/) has been implemented this way. This idea has not been discussed with the community as of this writing, but a bug has been filed, and future discussion will be found at Bug 375123.

Schedule

I will not have other commitments over the summer, so I will be free to dedicate myself to the project. Here is an outline of the schedule I envision:

Weeks 1-3 - Windows and Tabs

I will begin by implementing the improved window/tab support outlined in the first two paragraphs of the Details section. I estimate that this will take approximately half a week to design, one week to write, and one and a half weeks to debug and polish to a high gloss. The design will consist of marrying the dictionary outlined above with the actual code. The basic implementation of this is straightforward. Therefore, the difficult part will be working out the kinks which experience tells me will make themselves known.

Weeks 4-6 - Bookmarks

Bookmark support should take a similar course: half week for design, one for implementation, one and a half to make it perfect.

Weeks 7-10 - Script Toolbar Items

The toolbar feature has the possibility of running longer, so I've given it a fourth week. I've implemented NSToolbars and their items before, and I know it can be tricky. (I'm thinking specifically of issues such as validation.) I plan to spend a half week designing, a week and a half writing, and two weeks debugging and cleaning.

Weeks 11-12 - Reserved

I anticipate there will be changes and additions to the proposed features. I also know from experience that a project will tend to take longer than one plans. This time is to allow the project to expand a bit, if necessary. If I reach Week 11 and find I have completed what I proposed, I am sure the community will help me find more work to do regarding AppleScript support. In fact, I expect they will have already.

Biography

I've been a Mac geek all my life. I found AppleScript in my father's PowerBook almost ten years ago, and we've been friends ever since. He can act a little strange sometimes, but once you get to know him you realize he's pretty nice, and he's very helpful. He claims English is his first language, but I think he's lying. I don't hold it against him, though, because he's always been a good friend.

Then, a little over four years ago, I upgraded from OS 9 to OS X. That's when I met Cocoa. Cocoa was a little more grown up than AppleScript, and he could do really impressive things. This one time, he built a text editor for me, and all I had to do was tell him where to put everything. I was worried that AppleScript would get jealous now that I was spending so much time with Cocoa, but it turned out they were good friends!

So, for the past four years, I've been spending a lot of my free time working with Cocoa and working with AppleScript and working with the two together. Unfortunately, most of my projects disappeared when my faithful PowerBook G4 died last summer. Included in that number was one of my proudest creations: a Dashboard widget which used JavaScript to call on a Cocoa plug-in to run an AppleScript to retrieve rows from an OmniOutliner document.

Last summer was also when I discovered the Camino community. I spent much of my summer doing bug triage for Camino, but I was living on borrowed cycles (from my girlfriend's iBook) and I couldn't build trunk or do actual development. I've kept in touch with the Camino project, and began writing patches over winter break on my new machine, but while school is in session time is hard to come by. I look forward to having the opportunity this summer to contribute to Camino again.