AppleScripting Google Desktop

Thursday, June 28, 2007 at 5:49 PM

Posted by Dave MacLachlan, Mac Software Engineer

Most people aren't aware that Google Desktop has a simple, but powerful, AppleScript interface. You can use this interface to write scripts that search with Google Desktop. The most basic script allows you to quickly search for some text:

tell application "Google Desktop"

search for "happy"

end tell

This will return an array of search results. A search result is a record containing the title, snippet, and URL of the result, along with other details. So if you wanted to display just the title of the first result, you could do this:

tell application "Google Desktop"

set results to search for "We wish"

set a to title of item 1 of results

end tell

display dialog a

Or if you wanted to open the first result:

tell application "Google Desktop"

set results to search for "you a"

set a to URL of item 1 of results

end tell

open location a

The "search for" command has several more powerful options, some of which are exclusively available in the scripting interface. Suppose you want to search for results between two dates:

tell application "Google Desktop"

set startDate to date "Monday, July 17, 2006 00:00:00 "

set endDate to current date

search for "happy" after date startDate before date endDate

end tell

Or, let's say you want to find only email results:

tell application "Google Desktop"

search for "birthday" restrict to email

end tell

Or, finally, you'd like to do an exact search (as opposed to a prefix search, which is the default):

tell application "Google Desktop"

search for "hoff" without prefix match

end tell

Of course, you can use all of this directly from the command line using osascript.

There are several other options for "search for" and a few other simple commands hidden within the dictionary, so poke around and see what you can do.

Congratulations Amit, the Mac team is proud of you!

Thursday, June 07, 2007 at 5:31 PM

2007
http://www.mactech.com/articles/mactech/Vol.23/23.06/2007MacTech25/index-003.html

2006
http://www.mactech.com/articles/mactech/Vol.22/22.08/2006MacTech25/index.html

Picasa Web Albums meets Google data APIs

Tuesday, June 05, 2007 at 6:17 PM

Posted by Greg Robbins, Mac Software Engineer

My parents enjoy it when I bring them printouts of my favorite photos, but the rest of my family and friends are happier just to get links to the pictures. With the Mac uploaders for Picasa Web Albums, it's quick and easy to put my photos on Google's servers.

But there's a lot more to share besides snapshots. Maybe you've created an avatar for your online world and you'd like to show your creativity to friends who live "outside." Or consider this: security cameras and webcams can capture suspicious activity. Those could go into a Picasa Web Album, and be monitored like any other RSS feed. Almost every Mac application can extend its reach by sharing online. And with Google Data APIs, there's no need for a specialized server. Any application can let you share your data with your Google Account.

Now that Picasa Web Albums has a Google data API, I've updated the open-source Objective-C Client Library to make it easy for developers to share photos from their applications. Here's what it looks like for a programmer adding the picture SunsetPhoto.jpg to the album "My Best Photos":

GDataServiceGooglePicasaWeb* service =
 [[GDataServiceGooglePicasaWeb alloc] init];

[service setUserCredentialsWithUsername:@"my.account@gmail.com"
 password:@"mypasswd"];

// get the URL for the album
NSURL *albumURL = [GDataServiceGooglePicasaWeb
 picasaWebFeedURLForUserID:@"my.account" albumID:nil
 albumName:@"MyBestPhotos" photoID:nil kind:nil access:nil];

// set a title and description for the new photo
GDataTextConstruct *title, *desc;
title = [GDataTextConstruct textConstructWithString:@"Sunset Photo"];
desc = [GDataTextConstruct textConstructWithString:@"A nice day"];

GDataEntryPhoto *newPhoto = [GDataEntryPhoto photoEntry];
[newPhoto setTitle:title];
[newPhoto setPhotoDescription:desc];

// attach the photo data
NSData *data = [NSData dataWithContentsOfFile:@"/SunsetPhoto.jpg"];
[newPhoto setPhotoData:data];
[newPhoto setPhotoMIMEType:@"image/jpeg"];

// now upload it
GDataServiceTicket *ticket;
ticket = [service fetchPicasaWebEntryByInsertingEntry:newPhoto
 forFeedURL:albumURL
 delegate:self
 didFinishSelector:@selector(addPhotoTicket:finishedWithEntry:)
 didFailSelector:@selector(addPhotoTicket:failedWithError:)];

The new library includes sample code that shows developers how to browse albums, add tags, display upload progress, and take advantage of the full Picasa Web Albums API. So now you can encourage the developer of your favorite application to make it easy and free for you to share your work online, too.

Google Desktop for the Mac 1.0.3

Friday, June 01, 2007 at 9:11 AM

Posted by: Rose Yao, Mac Product Manager

Just wanted to let everyone know about a new update for Google Desktop for the Mac. We've been reading your emails, blogs, and comments, so we focused this update on making Google Desktop faster and fixing the bugs that we hear the most about. We have also updated Google Updater in this release with a lot of great bug fixes. You can check out our release notes for more details. If you have Google Desktop installed, you don't need to do anything to get the update, we'll deliver it to you automatically. If you want to try the latest version of Google Desktop, go to desktop.google.com/mac.

P.S. For all the Mac developers out there, we've also added a new XML based query API that is supported on the PC and the Mac. Learn more about it!

Google Gears for WebKit

Thursday, May 31, 2007 at 10:06 AM

Posted by Dan Waylonis, Mac Software Engineer

Have you heard about Google Gears? It's an extension to your favorite web browser and a new open source project from Google. It adds support for local data storage and helps web application developers manage resources so you can make your web application work offline. It is currently available for Linux, Windows, and Macintosh platforms and you can learn more at http://gears.google.com. I got a chance to work on this product for WebKit, which is the render engine Safari is based on, and we're happy to announce that the source code is available to all Mac developers today.

Since Google Gears is leveraging the latest technology from WebKit, it is currently not compatible with the shipping versions of Safari (Mac OS X 10.4.x and 419.x). So, if you want to play with Google Gears for WebKit, you'll have to download a recent WebKit build from http://nightly.webkit.org.

How it works

Google Gears for WebKit is made up of an Internet plugin for Webkit or Safari (Gears.plugin) that's installed into /Library/Internet Plug-Ins and an InputManager (GoogleGearsEnabler) that's installed into /Library/InputManagers. The GoogleGearsEnabler ensures that Google Gears can provide resources to web applications. It registers a NSURLProtocol class only if the OS X Application is a supported version of Safari or WebKit. Once installed, the registered class will check any URL requests to see if Google Gears can provide the content. If so, it will intercept the call and provide the data. Otherwise, the URL will be processed normally. This is how Google Gears is able to work when you're not connected to the Internet.

Google Gears is an open source project and we're working with partners like Adobe, Mozilla, Opera, and others to make sure this is the right solution for users. So come check it out for yourself at http://code.google.com/p/google-gears/ and help us make it even better for WebKit and Safari.

Google Developer Day

Wednesday, May 30, 2007 at 12:02 PM

posted by Scott Knaster, Technical Writer

Seasoned Mac developers and fans know that Apple's upcoming Worldwide Developer Conference (better known as WWDC) is a highlight of every year. And for the first time this year, we are getting into the developer conference act too -- with tomorrow's Google Developer Day. It's not strictly a Mac event, but I'm looking forward to it because GDD is going to showcase all sorts of cool web-based cross-platform goodies, including Google data APIs, developing with Google Maps, AJAX development, and lots of fun with mashups (I got to help out with that topic).

Google Developer Day is a tough ticket, but I'm happy to report that we're webcasting the whole thing live and then posting the videos to YouTube, so you can virtually be there without having to travel. And if you are actually there, maybe we'll run into each other -- or if not, then maybe at WWDC.

Measuring performance of distributed notifications

Thursday, May 10, 2007 at 4:16 PM

Posted by Mike Morton, Software Engineer

On April 4th, we announced Google Updater. It uses several pieces of software that run in the background, but we knew early on it was important for the one user-visible application to be able to show you what those background pieces were up to.

We looked briefly at using Apple's Distributed Objects technology, but it can take a fair amount of work to make DO work well. We also need multiple copies of the user interface to listen to a single background process, so the logical way to implement it was NSNotificationCenter, a class in Apple's Foundation framework that broadcasts notifications across processes. It can even broadcast to applications run by other users logged into the same computer.

We did have one worry, though. Apple’s doc warns that “Posting a distributed notification is an expensive operation. The notification gets sent to a system-wide server that distributes it to all the tasks that have objects registered for distributed notifications…”. This left me wondering two things:

(1) Just how expensive is it? How many notifications can you broadcast per second? As with all Google client products, we want to be good citizens and not bog down the client machine.

(2) Does subscribing to any distributed notification really mean that the server sends you every notification, and not just the ones you asked to receive? Could we assume that the server keeps track of the “names” you ask to hear about, and filters before distributing?

One of my favorite riddles is “How many empiricists does it take to change a light bulb?”. So I wrote a command-line tool that broadcasts NSDistributedNotifications and another that listens. I ran ten copies of the listener and one broadcaster on a 2GHz Intel Core Duo.

The first interesting result was that the broadcaster can consistently push out a notification about every 2.64 milliseconds, no matter whether the listening processes are listening for the same name-and-object.

The second finding was that nothing burns much CPU except Apple’s distnoted process, which is the bottleneck through which all notifications get sent. When the listeners did listen for the name the broadcaster was sending, distnoted used about 30% of the CPU. Shark showed distnoted was spending time in memory management involving simple data structures.

So we can conclude two things:

• We can easily send several messages per second to a dozen or so listeners without impairing a client machine.

• Registering to get only the name/object you want can help performance.

We designed our background processes to limit the number of notifications they broadcast, and distributed notifications have been a great base on which to build this part of the Updater system.


P.S. The answer to the riddle: “I don’t know, either. Want to find out?” ;-)