By Greg Robbins, Software Engineer

Software publisher Memeo recently released Memeo Connect?, an application that provides tight integration between documents on Google Apps and the Mac and Windows desktops. Over on the Google Apps Developer Blog, Memeo's Mac developer Matthew Tonkin describes some of their experiences of using the Google Data API client libraries. Please take a look.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/PCbTMcor8Ew/memeo-connect-for-google-docs.html

The last time we put on a show
was just over two months ago.
We polished our Chrome
for Mac! It's at home
on anyone's MacBook or Pro.

It's fast, and of course, we ensure
the browser will stay more secure.
But some wrote a letter?
they wanted it better!
So clearly it had to mature.

Today, we are happy to mention
on Mac, you can use that extension!
And bookmark sync too,
plus, there's more for you
and if I still have your attention:


Read more about our release on the Google Chrome blog. If you're as psyched as we are, you can download the new Google Chrome Beta for Mac, now with extensions, bookmark sync, cookie and bookmark managers, and more. Still not convinced? Maybe a cute foam arrow would be more persuasive:




Posted by Mark Mentovai, Software Engineer, Google Chrome

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/SHC5Z1Kulzo/google-chrome-beta-for-mac-updated-now.html

By Greg Robbins, Software Engineer

Several years ago, I began hosting the email for my personal domain with the free Standard Edition of Google Apps. At first I remained a curmudgeon, and set my email client to delete messages from the server after retrieving them, because I wanted my email stored just on my own computer. But Gmail's threading interface grew on me, as did the temptation of having access to all of my email from any web browser. So the cloud won me over, and soon my messages were living on the server. Since then, I've been able to search my email from home, from work, and from any computer on the Internet.

But my personal email archives stretch back to long before the advent of Google Apps and Gmail. Suddenly, the years of conversations I'd happily stored in Eudora files seemed awfully inconvenient. That inconvenience goaded me into developing Google Email Uploader for Mac. It's a free utility application that you can use to push your archives from Apple Mail, Eudora, and Thunderbird up to your Google Apps email account. If you are sometimes anxious to locate your very earliest e-commerce receipts or your threads of political discussions from bygone elections, the email uploader can make them as easy to find as last week's family letters.

The email uploader is built on our open source Google Data APIs Objective-C Client Library and the Email Migration API. There is also a Google Email Uploader for Windows, as well as online tools for migrating web-based email to Google email accounts. Unfortunately, the Mac and Windows email uploaders currently can upload only to Google Apps email accounts, not to gmail.com or googlemail.com accounts.

Google Email Uploader for Mac is available today as an open source application at the Google Mac Developer Playground, where our Mac and iPhone developers share our toys and experiments. If you have a Google Apps-hosted account and email archives that stretch back to the Dark Ages, I hope you will download and try it.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/t_r8m8Jxgn0/upload-your-email-to-google-apps.html

by Avi Drissman, Chromium Team

(Note: as regular readers know, we occasionally publish extra-geeky technical posts here on the Google Mac Blog. If this isn't your thing, don't worry; our usual non-technical stuff will be back soon.)

I'm part of the Chromium team working on Mac issues, and as I wrote on our blog, for Chromium we needed a way to provide modality to individual tabs of our web browser. Specifically, we needed to attach sheets to a Cocoa view rather than to just a Cocoa window. How would we accomplish this?

Like always, it's half following what's possible, and half sudden inspiration. What's possible? Putting a sheet on a window. That's done several ways. For an arbitrary sheet you can use
-[NSApplication beginSheet:modalForWindow:modalDelegate:didEndSelector:contextInfo:]. But nearly every class that can put up a sheet has its own -beginSheet: method. NSAlert has
-beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo:. IKPictureTaker has
-beginPictureTakerSheetForWindow:withDelegate:didEndSelector:contextInfo:.

So we know that we need to hang our sheet on a window. That's where the inspiration comes in. I was talking with a fellow Mac team member who offhandedly mentioned invisible windows. Of course! If you have an invisible window that has a sheet attached, then for all practical purposes you have an independent sheet. Plus, if you make the invisible window the child window of the window that hosts the view that appears to run the sheet, then you can size the invisible window to cover the view and eat all the clicks, achieving the desired modality as well.

That was the easy part. The first implementation was quick, but quickly uncovered issues.

First, how do you hide the sheet when the view is hidden? At first I tried hiding the invisible window, but when you -orderOut: a window you kill any sheets on it. That wouldn't do. Then I remembered the good old days of the Mac Toolbox (and Cocoa before 10.3 when NSView got -setHidden:), where you'd just move windows or views off to infinity (or (-15000,-15000), whichever was closer). Exposé quickly revealed the folly of that approach. Turning the sheet's opacity to 0% worked under Leopard, but under Snow Leopard the sheet blurring effect stayed present. And if I resized the window to NSZeroSize, resizing it back to the original size wrecked the layout.

Eventually I settled on a combination that worked. First I set autoresizesSubviews of the content view of the sheet to NO, and then I resized the sheet down to nothing. Then I set the opacity to 0%. Once I set the invisible window to stop eating clicks, it all worked.

The second problem was all the different classes that provided methods to show a sheet. Even if you could get the sheet window from them, if you ran it using the NSApplication sheet method, it didn't work. A little (actually a lot) of NSInvocation magic helped smooth that issue over.

That's basically it. The API is really simple and the implementation is, if nothing else, amusing to read.

Should you go ahead and use this in your app? Probably not. This is a very specific tool for solving a very specific modality problem that we had. But if you have a similar modality problem, perhaps this is right for you. Give it a try and let us know what you think.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/QQgIfSphyl4/cocoa-and-tab-modality.html

73,804 lines of Mac-specific code and 29 developer builds later, we're excited to finally release Google Chrome for Mac in beta. We took a hefty dose of goodness from the Windows version to build a fast, polished browser for Mac -- with features such as the Omnibox (where you can both search and type in addresses), themes from artists, and most importantly, speed. Try downloading Google Chrome for Mac and see what you think.

We also took great care to make Google Chrome a native application for Mac. For example, we integrated the Keychain into Google Chrome for Mac, and incorporated Mac-style animations when you open the Bookmarks bar.

For more details on today's beta release of Google Chrome for Mac, check out the video below.



To our early users who tried the weekly developer channel builds and provided excellent feedback, we thank you. In bringing the Mac version of Google Chrome from its developer stages to a beta standard, we returned to the core principles of the Chromium project and focused on delivering rock-solid depth in a few critical areas for the browser, rather than a breadth of features that are rough around the edges. This first beta release for Mac does not yet incorporate extensions, bookmark sync, bookmark manager, and cookie manager. However, we focused on features such as sandboxing our renderer process to help provide a safer web experience for our users. We look forward to future releases of Google Chrome for Mac, which will fill in the gaps and provide a fast, clean browser for your enjoyment on Mac OS X.

Can't wait for more info? Read our frequently-updated detailed status, or keep an eye on some Mac-specific sections of the source code. Don't forget to give Google Chrome for Mac a try, and let us know what you think.





Posted by John Grabowski and Mike Pinkerton, Software Engineers, Google Chrome

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/nhb0_9bq_rw/google-chrome-for-mac-goes-beta.html

By Scott Knaster, Google Mac Team

There's a nice update to Google Earth for iPhone and iPod touch available now. You can read all about it in the Google Mobile Blog and you can grab the update in the App Store.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/GxuzukvEoUY/google-earth-for-iphone-version-20.html

By Scott Knaster, Mac Team

Gmail for iPhone has a new feature: auto-expanding compose boxes. This means that when you're writing a new message and you reach the bottom of the compose box, the box now gets bigger automatically. And you can now scroll through the whole message just by flicking ? no need to use the magnifying glass any more.

For all the details, see this post on the Google Mobile Blog.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/bB3ePUfSCU0/new-auto-expanding-compose-boxes-in.html

By Todd Bogdan, Software Engineer

Today, I'm happy to announce that we're releasing Picasa 3.5, a new version of our free photo editing software. Since we launched it as a beta Labs product 9 months ago, we've been steadily improving Picasa for Mac. Now that it has almost all the same features as the PC version, we've decided it's time to remove the beta label once and for all.

If you haven't tried Picasa for Mac, the new version gives you the ability to add name tags to your photos so that you organize them by what matters most: people. Picasa groups similar faces and lets you easily add a name tag to dozens of photos at once. After you've tagged some photos with names, you can do creative things with your tagged photos, like quickly finding all the photos with the same two people in them, making a face collage for a friend, or simply uploading and sharing people albums.



In addition to name tags, Picasa 3.5 has integrated Google Maps so you can more easily geotag your photos. And using our redesigned import process, you can now import photos from your camera and upload selected photos to Picasa Web Albums in one easy step.

Of course, Picasa for Mac is also designed to "play nice" with iPhoto, taking a special read-only approach to editing photos stored in the iPhoto library. It duplicates instead of changing files as needed, so your iPhoto library isn't ever affected when you use Picasa.

Picasa 3.5 is available in English (for now; more languages to come). You can download and try it today at picasa.google.com.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/3rrK6GaS3JI/new-face-tagging-iphoto-compatibility.html

By Greg Robbins, Software Engineer

In May 2008, we told you how iPhone and iPod touch users could sync their Gmail contacts with Address Book in Mac OS X 10.5. Now with Mac OS X 10.6, syncing Gmail contacts is also available to users who do not have an iPhone or iPod touch. If your Mac is running Snow Leopard, you can turn on contact sync in the Address Book preferences.

The syncing is better, too: in Mac OS X 10.6, only contacts in Gmail's "My Contacts" group are synced, rather than all of Gmail's contact suggestions. And photos are now transferred as well, since sometimes you just need to put a face to a name.

Before turning on contact sync, it's a good idea to back up your Gmail and Address Book contacts. Our help page explains how to do that, and covers a bit more on how contact sync works.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/c1dAgqvDREM/improved-contact-sync-in-snow-leopard.html

by Mike Morton, Google Mac Team

Every year, Google engineer Mike Morton becomes intrepid reporter Mike Morton as he ventures to Apple's Worldwide Developer Conference. Apple doesn't allow attendees to disclose the technical bits of the conference, so Mike writes about other important observations and details: general survival tips for the week, how to figure out in advance when the conference will be held, and insight into how WWDC is like the Soviet Union. Once you've read part 1 of Mike's annual report, you can continue to the thrilling conclusion here in part 2.

Between the lines

Wednesday morning, I discovered the gym in the corporate apartments, and found that 20 minutes on the elliptical goes a lot faster when there?s no TV intruding.

Eating the minimalist breakfast provided at Moscone, I looked over a web page of WWDC-related parties. I think I?m probably too old to go to a club called ?Harlot?. In fact, I?m even too old for the music they play before sessions; there's nothing that was written before the turn of the millennium. Several other folks commented that they didn?t think much of the music either. I told them about my neighbor?s bumper sticker: ?It?s Not That I?m Old. Your Music Really Does Suck.?

Two guys at the breakfast table seemed to be forming a business on the spot. They weren?t too far along, though: one said to the other, ?Let me give you my card?, ripped a page from a notebook, and wrote his contact info on it.

The session rooms were the same size as last year, but with more people trying to crowd in. The poor Apple engineers, who don?t get to go in until all the paying customers have, must have been even more frustrated this year. I wonder how Apple will handle the growth next year. Some rumors claimed that this is the last year at Moscone, that Apple has met some contractual obligation.

Despite the larger crowds, there seemed to be more power outlets in the sessions. You can often spot clusters of them from a distance ? those seats are more densely filled. I went the whole week without having to pull the spare battery from my pack, a first.

Nerdvana!

For me this year, the most interesting part of the week was in the labs, not the sessions. Apple said that they brought in over 1,000 of their engineers, and I can believe it. Lots of attendees (n00bies and not) queue up for help from an Apple expert in the area they need help with. At one point, an iPhone performance engineer was helping one person, with four others (including me) in line with questions.

Attendees lined up for other things, too: to get good seats for sessions, for snack tables set up between sessions, for the fridges with Odwalla juice. It felt a little like the old Soviet economy: you see a line and you figure it must be worth waiting in. Of course, the Soviet strategy has its downside: you might find that the line turns out to be a bunch of Apple engineers waiting to see if a session has seats.

iPhones everywhere

Walking to Moscone, I noticed just how many iPhones there are in the city, and not just near the conference. Maybe this platform really is as big a deal as Apple keeps telling us. I think I saw more iPhones than Zipcars, which are also plentiful.

Earlier, I mentioned the importance of the labs for one-on-one access to helpful Apple engineers, but I should say that most sessions were good, too. Sitting for that many hours was tiring ? when will they introduce premium seating? I?d pay more for Herman Miller ? but mostly worth it. The only time it?s not worth it is when the talk is too elementary or too advanced. Alas, that does happen. Apple has a difficult challenge because attendees have experience ranging from near-zero up to decades of Cocoa development. It?s a balancing act, and Apple did it fairly well. At least as an old-timer I thought they did. I wonder what newcomers think. All those folks focusing on their laptops in sessions: are they tuned out, or just trying the examples from the session?

Even though some sessions miss the mark, the week as a whole is useful. I think the importance of this conference is demonstrated by a Googler I know who doesn?t work with Apple products enough to justify Google sending him, so he took a week of vacation and paid his own conference fee and travel expenses just to go.

Show?s Over

I confess I blew off the last day of the conference to go to my godson?s college graduation. In the BART station, waiting for a train to the airport, I chatted with someone who was also skipping the last day of his conference, some non-Apple thing. We agreed that the last day is usually the most boring, and that we felt sorry for anyone who has to speak on the last day.

Sitting on the flight home, I had to focus on work because, again, I had no window. I tried to go through all my notes. It was a frantic week, and I had notes in my laptop, in my iPhone, in emails to my team, on scraps of paper big and small, and it was good that I made those notes, because the conference feeds me so much information, I for one have to write it down or lose it. Now it was time to look at all the cool new things in the OS and the hardware and figure out how and when we can take advantage of them!

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/WX0OWOLkulo/wwdc-2009-journal-part-2.html

by Mike Morton, Google Mac Team

Every year, Google engineer Mike Morton becomes intrepid reporter Mike Morton as he ventures to Apple's Worldwide Developer Conference. Apple doesn't allow attendees to disclose the technical bits of the conference, so he writes about other important observations and details: general survival tips for the week, how to figure out in advance when the conference will be held, and insight into how WWDC is like the Soviet Union. Here's part 1 of Mike's annual report.

When?s vacation?

For one week this past June, it was unusually hard to get your AT&T cell phone to work if you got too near San Francisco?s Moscone Center. Over five thousand Apple developers came from around the world to learn about Apple?s latest news at the Worldwide Developer Conference (WWDC). Most of them had iPhones, and to make up for the few who didn?t, some folks brought more than one. You could usually place a call, but most of my incoming calls never rang.

I had planned my summer carefully, scheduling vacations and other events to make sure I wouldn?t miss the conference. Advance planning is difficult, because Apple doesn?t announce the dates very far ahead of time. My partner works as a counselor in an elementary school, so summer months are precious. This year, I thought of a way to help me plan: I guessed that the conference would again be in Moscone West, and watched Moscone?s web site to see when it was booked. When I saw something like an orthodontists' convention at Moscone West, overlapping even part of the week, I knew we could consider that week for vacation, not WWDC.

Of course, Apple is smarter (and more secretive) than that. They booked Moscone West way in advance, but had Moscone list it as ?Corporate Event? until Apple announced the date. Luckily, I didn?t plan my vacation during that Corporate Event week. Now that I?ve spilled the beans, they?ll have to pick a new name to pre-book under. Probably ?Orthodontists' Convention?.

Having planned my summer perhaps more thoroughly than needed, I sat on the plane to California, thinking about the usual rumors that precede any Apple event. (I had to think about the rumors: my seat on the 757 had no window for watching the Rockies go by.) There was lots of speculation about both iPhone and desktop models, but I was mostly curious about something else: would Steve Jobs address the troops, even briefly, weeks before his medical leave was scheduled to end?

I checked into my corporate apartment (my first time in one; it was, well, corporate) and walked 20 minutes to Moscone to register. To my horror, I had forgotten that they would hand me tchotchkes. Nothing much, just the usual t-shirt and backpack. But I was traveling for 15 days with nothing but carry-on luggage, with not a cubic centimeter of room to spare. An Apple staffer saw my face fall. Perhaps she figured I was thinking ?yet another backpack?? She burbled, ?This one?s a Brenthaven!? It is indeed a very nice pack, and I quickly found a new home for it on the west coast. Perhaps next year they?ll give out iPhone cozies instead and I?ll have room to bring one home.

Lining up


On Monday I woke before my alarm, and got to Moscone a little after 5:30 a.m. I asked one of the first dozen people how early he had been there. ?Midnight!? Thinking of Keith Laumer?s short story In The Queue, about people spending their lives in line, I shuddered and joined the back of the line, which was only about a block long at this point. This is closer than I usually get to the front of the line, and I thought I was just earlier than I usually am, but I learned that others thought a Phil Schiller keynote was less of a draw than a Steve Jobs. (Would we show up earlier if Apple invented an RDF generator?) I chatted with strangers and old friends. Some colleagues joined me (cutting in line in this way is generally accepted). An Apple staffer came by, counting us. I was number 269.

Various people walked by offering freebies: tech magazines, brochures, pastries, and other goodies. The only thing most of us wanted was coffee; I?m surprised nobody was out selling that. I heard that later in the morning that a bunch of bikini-clad promotional models (AKA "booth babes") came by. Perhaps it was too cold for them when I arrived. And why were there no bikinied booth boys? This was open-minded San Francisco, after all.

The keynote was good. Phil is no Steve, but he and the other speakers had a lot of interesting products to hold our attention. They threw plenty of numbers at us, especially the number of apps available, and dissed various competitors. Plus we had to pay attention to the keynote, because most of us couldn?t get WiFi to work in a room that crowded. Perhaps it worked better in the overflow rooms (or ?coverflow rooms?, as my colleague Mark Dalrymple calls them).

Personally, I was most thrilled by the new iPhone?s video recording feature and the keyboard going landscape. Tethering sounds great, too, but the audience was very disappointed that Apple won?t say when it?ll work in the U.S., as you can observe when watching the keynote on the web.

Another thing that struck me: in the mobile world, hacking is going to be nastier than the desktop world. If Apple can Find Your iPhone, can a hacker find you? If you can unlock your Zipcar with your iPhone, how hard will it be for someone else to do the same? It's not that these two applications are any less secure than others, but the consequences of security problems will be different for mobile apps.

The keynote ended with no Steve Jobs cameo. I wasn?t the only one hoping. The New York Times Bits blog was headlined ?New Software, New iPhone, New Steve??. Oh, well, we found out later that he was back at work by the end of June.

Oh, one more thing: my best laugh of the day came in one of the afternoon sessions. An Apple designer named Max Drukman stood up to show us Dashcode and greeted us with ?Good afternoon, developers ? developers ? developers?. His timing was perfect homage to Steve Ballmer?s famous greeting to another bunch of developers.

Everything?s digital

I don?t know how the show does it, but by Tuesday morning I feel like I?ve already been here all week. I?m struggling to recognize faces and remember names and, when I?m lucky, put them together. Why doesn?t Apple put the name badges in a bigger font?

One thing I don?t have to remember any more is which sessions I want to go to. It used to be that Apple would hand you a small paper schedule of the week, which was nearly useless because it had lots of To Be Announced sessions. This was because when they gave it to you on Sunday or early Monday, it couldn?t list sessions about technologies that were going to be introduced mid-Monday. This year they did something great: they gave us an iPhone app listing the sessions, including updates during the week! The app let you mark favorites, and even showed you where the sessions were in Moscone. It did almost everything I wanted, but perhaps next year?s version could help me coordinate with my colleagues, to help us decide who?s covering which sessions.

A highlight of the show was a huge wall display (20 large monitors) showing icons for 20,000 top iPhone apps. Each time an app got downloaded, its icon bounced a little and jostled its neighbors. The apps weren?t organized alphabetically, though. They were sorted by icon color, creating a big spectrum. A lot of developers spent a lot of time looking for their apps. Several of us agreed that Apple could have made money by charging a dollar to find your icon for you. I never did find the icon for Google Earth. Maybe it gets downloaded so often that Apple thought the constant bouncing would just be distracting. Yeah, that must have been it.



Strange sight for the day: An attendee walking around holding a Steve Jobs doll like this one. I doubt it's RDF-enabled.

Coming soon: part 2, featuring Nerdvana and more.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/urr-GDXH2lI/wwdc-2009-journal-part-1.html

If you're an iPhone user, you might have been waiting for Google Latitude, our service that lets you see where your friends are, which has not been available on iPhone. Well, today we're releasing Google Latitude for iPhone and iPod touch as a web application running on iPhone's Safari browser. Now you can share your location with your friends, as well as control who gets to see it, all from your iPhone.




To start using Latitude, go to google.com/latitude from the iPhone's browser. You can even add a bookmark to your home screen for one-touch access. Check out the Google Mobile Blog to learn more.

Posted by Scott Knaster, Google Mac Team

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/WTjn5HFq9C0/google-latitude-for-iphone.html

By Greg Robbins, Software Engineer

In December, the Picasa Web Albums Uploader added support for downloading a photo album to your Mac. We've recently updated the Uploader to include the ability to download all photos from all albums in your account. To start the download, sign in to your account with the Picasa Web Albums Uploader application and select the Existing Album tab. Holding down the Mac's Option key will change the title of the Download Album button to Download All. Then one click will bring all of your albums home.

This update also improves reliability of the uploader's iPhoto export plug-in. The uploader typically keeps itself up-to-date, but you can also get the latest version, 1.3.1, from the download page. Please let us know how it works for you in the Mac Uploader area of the Picasa Help forum.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/z4bSFlUckNo/upload-your-photos-download-your-albums.html

When most people think of Google, search comes to mind ? and rightly so! Hundreds of millions of people have come to know and love Google.com as their starting point for searching the Internet. About 2 years ago, we introduced Google Desktop to extend Google search capabilities to your Mac and, earlier this year, we launched a developer preview of the next evolution of search outside the browser. Today, we're officially releasing this technology to all users as the Google Quick Search Box (or QSB for short).


With Google Quick Search Box you can search for information from just about anywhere. As you type, suggestions will appear that match your query, ranging from applications and local files on your computer, to web search and navigational suggestions, to items from your browser history and contacts - and the types of results you can get will only grow over time! Check out the screenshot below for an example of the types of blended results you might see.


Once you've found the result you want, we wanted you to be able to DO something with it. To find out what you can do, select a result and press the tab key or the right arrow on the keyboard. Some examples of actions include instant messaging friends, playing a song, or emailing a URL. Just like the data you can search over, the list of actions you can perform will grow over time!

The quickest way to launch the Google Quick Search Box is by pushing Control + spacebar at the same time (Google Desktop devotees will still be able to press Command twice to summon the box). If you prefer another keyboard shortcut to summon the Google QSB, you can change it in the Preferences panel.

As you use the Google Quick Search Box more, it will learn which results you are likely to want. The goal here is that we get you to what you're looking for as quickly as possible. In the above example, if you chose Google Calendar, the next time you search for "cal", Google QSB will reorder the results so that you don't have to arrow down to your desired choice. Instead, you can just type "cal" and press enter.

Last, but definitely not least, the Google Quick Search Box is extensible. This means that anyone can create a plug-in that enables the QSB to search over additional data or perform more actions on results. As an example, we really enjoy the Twitter plug-in . After enabling that bad boy, we can send tweets right from the QSB and then do a Google search right after!

The Google QSB has allowed us to do our daily tasks faster. If you want to give it a try to see it speed up your day, visit www.google.com/quicksearchbox/.

If you're a Google Desktop user and you want to gain this functionality, you can learn more about Google QSB and see how to upgrade in this help center article.

And please, let us know what you think!

Posted by Ryan Tabone and Karen Grünberg, Product Managers

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/6Z5QIv0C06Q/introducing-google-quick-search-box.html

By Avi Drissman, Google Chrome Team

(Note: this is another of our occasional extra-geeky technical posts. If this isn't your thing, don't worry; our usual non-technical stuff will be back soon.)

Welcome back. In our last post we went through a simple function that made calls to other functions, and touched on stack frames and parameter passing. This time let's talk about a different function. We'll focus less on the things we've seen, and more on some more advanced actions that this function does.

UpdateDockTitle

PowerPC

<+0>: mflr    r0               // save linkage
<+4>: stmw    r28,-16(r1)      // stash r28, r29, r30, r31
<+8>: mr      r30,r3           // save r3 (WindowData)
<+12>: bcl-    20,4*cr7+so,0x928d2bd4 <+16>
<+16>: mflr    r31            // get ip in r31

Whoa... what?

Short story: <+12> is an unconditional branch-and-link.

Long story: On the PowerPC, instructions like bge, etc. are just aliases to a more primitive branch instruction, bc (branch conditional). In this case, the first parameter is 20 (0b10100), which indicates ?branch always?. Since it's always going to branch, the second parameter doesn't matter, so it was set to all 1 bits (which translates to 4*cr7+so).

Why do this? Because we're going to need to access some PC-relative data, and the PowerPC chip has no PC-relative addressing mode. And the register move instructions can't access the PC register. Therefore we cheat in a way by taking an unconditional jump to the next address. Since it's a branch and link, the link register is filled with the next address (in this case, that equals the address just jumped to) which can be moved to a normal register.

Why branch-conditional with a condition ?branch always?? The b opcode only provides absolute addressing. Only bc has relative addressing.

<+20>: stw     r0,8(r1)
<+24>: stwu    r1,-80(r1)     // make stack frame
<+28>: addis   r28,r31,3533
<+32>: bl      0x928d2c50 <_Z15GetTitleForDockP10WindowData>
<+36>: lbz     r0,-3364(r28)  // haul initialization boolean into r0

This is where intuition comes in. We're hauling in some random byte from a PC-relative address. (lbz is load byte and zero, which loads one byte from memory and clears the high bits.) What's byte sized? A Boolean (the Carbon type; GCC makes C++ bools 4 bytes). Why a Boolean? Probably a flag. And with the value of the byte gating the call to RegisterAsDockClientPriv, it's a safe bet that it's an initialization flag.

<+40>: mr      r29,r3         // stash new title into r29
<+44>: cmpwi   cr7,r0,0       // was initialized?
<+48>: bne-    cr7,0x928d2c04 <+64> // if so, skip
<+52>: bl      0x9287f864 <_Z24RegisterAsDockClientPrivv> // else initialize
<+56>: li      r0,1           // and set flag
<+60>: stb     r0,-3364(r28)  //   as being intialized
<+64>: mr      r3,r30
<+68>: mr      r4,r29
<+72>: bl      0x928d2c68  // call with (WindowData, new title)
<+76>: lwz     r0,344(r30)    // pull (WindowData + 344)
<+80>: andis.  r2,r0,64       // and pull a flag bit out of it (minimized?)

More intuition here. r30 contains a pointer to the WindowData class instance, and we're accessing some word 344 bytes in. We don't care about the destination register (we don't touch r2 again this function) but don't miss the name of the opcode: ?andis.? Remember that the period means to update cr0.

Once again, this is obviously a flag (bit-sized this time). But what does it mean? Context tells us that we only call CoreDockSetItemTitle when it's set. Thus, it's a safe guess that this is the is-minimized flag.

<+84>: beq-    0x928d2c38 <+116> // if not minimized, skip this step
<+88>: addi    r1,r1,80
<+92>: lwz     r3,196(r30) // load WID

How do I know that WindowData+196 is the CoreGraphics WID (CGWindowID; see CGWindow.h)? I used Quartz Debug to look at the window list for a sample app. The app only had one window, and the listed WID matched.

<+96>: mr      r4,r29 // load new title
<+100>: lwz     r0,8(r1)
<+104>: lmw     r28,-16(r1) // tear down stack frame
<+108>: mtlr    r0
<+112>: b       0x92b58ce4 

Note that we're tearing down the stack frame twice. In this case we're tail calling CoreDockSetItemTitle so that it's as if our caller called them directly. This is equivalent to the code return CoreDockSetItemTitle(wid, newTitle). Note from the setup of r3 and r4 that we can deduce the parameter types. Can we figure out the return type, though? Not really. The calling code ignores it, so we can ignore it too.

<+116>: addi    r1,r1,80
<+120>: li      r3,0
<+124>: lwz     r0,8(r1)
<+128>: lmw     r28,-16(r1)
<+132>: mtlr    r0
<+136>: blr

x86

<+0>: push   %ebp                   // make stack frame
<+1>: mov    %esp,%ebp
<+3>: sub    $0x28,%esp
<+6>: mov    %ebx,-0xc(%ebp)        // save %ebx
<+9>: call   0x92e4bbe4 <+14>
<+14>: pop    %ebx                 // IP > %ebx

We're doing the same trick here to get the PC into a register and I'm a bit stumped as to why. From what I know, the x86 has PC-relative addressing, and surely there's got to be a better way to get the PC into a normal register. Right?

<+15>: mov    %esi,-0x8(%ebp)      // save %esi
<+18>: mov    0x8(%ebp),%esi       // WindowData > %esi
<+21>: mov    %edi,-0x4(%ebp)      // save %edi

This almost looks like it was compiled by a different compiler. In the previous function, edi and esi are pushed, and then the stack pointer dropped. Here, we create the stack space and then move the contents of three registers (edi, esi, and ebx). I suspect that things change once we also have to save ebx, though I don't know why.

<+24>: mov    %esi,%eax            // %esi (WindowData) > %eax
<+26>: call   0x92e4bc40 <_Z15GetTitleForDockP10WindowData>

Whoa. If we're calling a function we need to set the parameter via stack-relative addressing off esp. What's going on here?

The point of an ABI is that it's a documented way for functions to call each other. But if a function, say GetTitleForDock(WindowData*), is a short one that's not public and is only used under controlled circumstances, why worry about setting up the stack? In this particular case, GetTitleForDock happens to be a nine-instruction routine. Not worth the hassle of a stack frame, so it's reasonable to pass in the one parameter in eax.

<+31>: cmpb   $0x0,0xd51a36c(%ebx) // test initialization boolean
<+38>: mov    %eax,%edi            // window title > %edi
<+40>: jne    0x92e4bc0c <+54> // if initialized, skip
<+42>: call   0x92df9fe0 <_Z24RegisterAsDockClientPrivv> // else initialize
<+47>: movb   $0x1,0xd51a36c(%ebx) // and set flag as being initialized
<+54>: mov    %edi,0x4(%esp)       // new title (param 2)
<+58>: mov    %esi,(%esp)          // WindowData (param 1)
<+61>: call   0x92e4bc52 
<+66>: xor    %eax,%eax            // clear %eax (noErr?)
<+68>: testb  $0x2,0x159(%esi)     // test flag (WindowData + 0x159) (minimized?)
<+75>: je     0x92e4bc35 <+95> // if not minimized, skip this step
<+77>: mov    %edi,0x4(%esp)       // new title (param 2)
<+81>: mov    0xc4(%esi),%eax      // (WindowData + 0xC4) WID
<+87>: mov    %eax,(%esp)          // (param 1)
<+90>: call   0xa0a52ad1 
<+95>: mov    -0xc(%ebp),%ebx
<+98>: mov    -0x8(%ebp),%esi
<+101>: mov    -0x4(%ebp),%edi
<+104>: leave
<+105>: ret

Conclusion

Poking around in assembly isn't usually something you do every day. But whether you need it for debugging your own code or exploring someone else's, it's a skill that is definitely worth learning. PowerPC and x86 processors might have had a bit of a different history, but the code that's generated for either is certainly not as intractable as some suggest.

Where to go from here? Look around some more. Use otool -tV to dump binaries and see what they do. Use nm to see which symbols are exported from frameworks and watch how they work.

Go exploring, and have fun.

(Thanks to my editor, Scott Knaster, and to David Shayer, whose introductory session on PowerPC assembly at the legendary MacHack conference started me on this path.)

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/v78GY_ohRus/mac-os-x-spelunking-in-powerpc-and-x86.html

By Scott Knaster, Google Mac Team

Interested in news about Google Chrome for Mac OS X? Google Chrome for the Mac is coming along fine, and for the technically inclined, Jeremy Moskovich of the Google Chrome team has written a blog post explaining how the developers implemented sandboxing, an important Google Chrome feature. To find out more, please check out Jeremy's post.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/AMLWz_82Ty0/google-chrome-sandboxing-and-mac-os-x.html

By Avi Drissman, Google Chrome Team

(Note: this is one of our occasional extra-geeky technical posts. If this isn't your thing, don't worry; our usual non-technical stuff will be back soon.)

If you're a programmer, there are many reasons why you might want to go exploring the inner workings of Mac OS X. You might want to learn how how Apple achieves interesting effects. Or perhaps you're just curious about how things work. (We're all adults here, so I won't lecture you about the dangers of using private or undocumented interfaces in your apps.)

In any case, though, you need to know how to read assembly, either PowerPC (if you have an older Mac) or x86 (if you have anything recent). While there are good resources available to learn about reading PowerPC assembly for exploration, there are fewer about x86. Despite the present and future of the Mac being x86, it seems like people have lots of anxiety about having to work with it.

I think the problem is not a lack of documentation on x86 assembly, but a surfeit of it. Most of it is Windows- or DOS-centric, usually with syntax that doesn't apply (Intel syntax vs the AT&T syntax that GCC uses), and with the aim of teaching how to write it. But reading x86 assembly really isn't that hard. If all you want to do is learn how to read the code generated by GCC, it's probably just as easy as PowerPC.

The other day I was investigating how window minimization and window titles work. While exploring, I took notes of my discoveries. Let's touch on two functions, in both PowerPC and x86 flavors.

Before we begin, I'm going to assume that you're comfortable with assembly in general (though not necessarily with any particular one). If you have the latest developer tools, launch Shark (in /Developer/Applications/Performance Tools) and in the Help menu you can access various ISA references. In addition, Apple has ABI documentation for both the PowerPC and x86. I'm going to go over each function twice (once for PowerPC and once for x86); feel free to skim the PowerPC version if you're accustomed to it. And finally, this is only for the 32-bit version of each platform; things change even more with 64 bits.

SetWindowTitleWithCFString

The trail always begins with a public call that uses the SPI that you want to figure out. In this case, I chose SetWindowTitleWithCFString because it has to somehow set the title of a window even if it's minimized. I went with Carbon because sometimes the dynamic nature of Objective-C with Cocoa makes tracing code harder.

PowerPC

<+0>: mflr    r0          // save linkage
<+4>: stmw    r30,-8(r1)  // stash r30, r31
<+8>: mr      r30,r4      // save r4 (new title)
<+12>: stw     r0,8(r1)    // make stack frame
<+16>: stwu    r1,-80(r1)  // make stack frame

This is the prologue of the function. The PowerPC doesn't have a dedicated stack pointer (convention is to use r1 for that), so the common way of implementing branches by pushing the PC onto the stack doesn't work. Instead, the PowerPC has a link register and a command bl to branch and put the old PC value into the link register. Thus, almost every function starts with mflr r0, to pull the old PC into a usable register. Then in <+4> we save off some registers that we're going to smash. Every function needs scratch registers to hold local variables, and usually the high-numbered registers are used. The stmw (store multiple words) instruction is useful for ditching many high registers on the stack. Then in <+12> we drop the old PC onto the stack and allocate 80 bytes on the stack.

A note on parameter passing. Integer-sized parameters (the only kind we'll be dealing with today) are passed into a function starting with r3 and going up through the registers. Return values are returned in r3. So we see that in <+8> we stick away the pointer to the new name in r30 (whose previous value was stored on the stack earlier).

<+20>: bl      0x92881384 <_Z13GetWindowDataP15OpaqueWindowPtr>
<+24>: li      r0,-5600    // errInvalidWindowRef
<+28>: cmpwi   cr7,r3,0    // if no window data, bail
<+32>: beq-    cr7,0x928d2ae0 <+60>
<+36>: cmpwi   cr7,r30,0   // if no string to set, bail
<+40>: li      r0,-50      // paramErr
<+44>: beq-    cr7,0x928d2ae0 <+60>
<+48>: mr      r4,r30

This is where we must start making inferences as to what the code is doing. Fortunately, we have the symbols so it's not too hard. We see that we use the WindowRef as a parameter to a C++ function GetWindowData(OpaqueWindowPtr), as the WindowRef was passed in as r3 and r3 wasn't altered before the call. In addition, note that the function return value, being in r3, will overwrite the WindowRef value which wasn't saved in a high register. That's fine, as the WindowRef was just an index into a table and won't be needed further.

At this point we run some checks. We compare both r3 and r30 to zero, and if either are zero we jump to the end with r0 set to the appropriate error code. (The end of the function will move r0 into r3 for return.)

The PowerPC condition register has eight condition sets. Why are we using cr7 here? Probably because cr7 is volatile and we can get away with not saving/restoring it.

<+52>: bl      0x928d2af8 <_ZN10WindowData14SetTitleCommonEPK10__CFString>
<+56>: li      r0,0        // return noErr
<+60>: addi    r1,r1,80    // tear down stack frame and return
<+64>: mr      r3,r0
<+68>: lwz     r0,8(r1)
<+72>: lmw     r30,-8(r1)
<+76>: mtlr    r0
<+80>: blr

The rest is pretty simple. We call a member function WindowData::SetTitleCommon(CFString*), and then do common tear down. We restore the stack pointer, put the return value into r3, restore the registers, move the old PC back into the link register, and branch to the link register (blr), returning us to our caller.

x86

The PowerPC register file is really easy: r0, r1, r2 ... r31. x86 has fewer registers and they've historically had different roles (accumulator, base, source index, destination index, and so on). Seriously, forget about that. There are eight registers you care about. eax, ebx, ecx, edx, esi, and edi are all general-purpose registers. esp is the stack pointer. ebp is the frame pointer. That's it.

PowerPC assembly reads right-to-left (except for stores). x86 AT&T syntax in general reads left-to-right.

<+0>: push   %ebp             // make stack frame
<+1>: mov    %esp,%ebp        // make stack frame
<+3>: push   %esi             // stash %esi
<+4>: sub    $0x14,%esp       // make stack frame

x86 is stack-based. Parameters to a function are put at the top of the stack, and the rightmost parameters have the highest addresses. To execute the function, the call instruction was used. This instruction pushes the PC onto the stack, so even before we hit <+0> the parameters are four bytes above the stack pointer. In <+0> we save off the old stack frame value and in <+1> we establish our stack frame. At this point ebp is fixed for the entire function. In <+3> we save the old values of registers we're going to use, and in <+4> we allocate space on the stack.

This is a perfect example of an ideal stack frame. ebp is the frame pointer. It points (to the stack) at the old frame pointer. ebp+4 is the PC of the function that called us. ebp+8 is the first parameter passed in, ebp+12 is the second, etc. Immediately below ebp are the values saved from the registers, which will be restored before the return. And below that is a bunch of stack space used for either register spillage or calling subsequent functions. One interesting note is that rarely are parameters pushed onto the stack for a call. The stack pointer doesn't move once we make it past the prologue. We just set the memory right above esp (the stack pointer) and make the call.

<+7>: mov    0x8(%ebp),%eax   // get WindowRef in %eax
<+10>: mov    0xc(%ebp),%esi   // get new title in %esi

The parameters are passed on the stack. Since fiddling in memory is slow, we pull the values into registers. It's actually pretty analogous to how things go in PowerPC. There, lower registers like r3 are reused for parameter passing so important values are kept in the high registers. On x86 the parameters go on the stack and values are kept in registers when possible. Why eax and esi? Why not?

<+13>: mov    %eax,(%esp)      // put WindowRef on the stack
<+16>: call   0x92dfb8f6 <_Z13GetWindowDataP15OpaqueWindowPtr>

With the PowerPC, you can tell how many parameters a function has by seeing how many registers starting with r3 are loaded. Here, we just look at the register indirect addressing with esp.

<+21>: mov    %eax,%edx        // stick WindowData into %edx
<+23>: mov    $0xffffea20,%eax // errInvalidWindowRef
<+28>: test   %edx,%edx        // if no window data, bail
<+30>: je     0x92e4bb04 <+54>
<+32>: test   %esi,%esi        // if no string to set, bail
<+34>: mov    $0xffce,%ax      // paramErr
<+38>: je     0x92e4bb04 <+54>

Return values come back from functions in eax, but otherwise this is pretty much the same. The only thing of interest to note is the clever use of the peculiar register structure. In <+23> the constant 0xffffea20 is loaded into eax. But on <+34> the constant 0xffce is loaded in ax. But since ax is just an alias for the lower 16 bits of eax, the upper half of the word is left as 0xffff and we get the full constant 0xffffffce in eax. Why do this? Because loading a 32 bit constant takes 5 bytes while loading a 16 bit constant only takes 4.

<+40>: mov    %esi,0x4(%esp)   // load new title as param 2
<+44>: mov    %edx,(%esp)      // load WindowData as param 1
<+47>: call   0x92e4bb0c <_ZN10WindowData14SetTitleCommonEPK10__CFString>
<+52>: xor    %eax,%eax        // return noErr

Same stuff as before. The one note is the zeroing of eax with an xor. Just a fancy trick as the generated code is faster and smaller than the equivalent mov $0x0,%eax.

<+54>: add    $0x14,%esp       // tear down stack frame and return
<+57>: pop    %esi
<+58>: leave
<+59>: ret
<+60>: nop
<+61>: nop

The mirror image of the stack frame creation.

That's one function down and one left to go. Next time, we'll take a look at a function that behaves a little differently than this one did.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/W_nvhKYCizM/mac-os-x-spelunking-in-powerpc-and-x86.html

Guest post by Mike MacDonald, Founder and CTO, gWhiz LLC

gFlashPro, the first offering in the iPhone App Store from our company, gWhiz, is a popular mobile flashcards application used by students of all ages to study on the go. Google Spreadsheets provide a key element of the gFlashPro architecture.

To create a gFlashPro flashcard set, students or teachers open up a new Google Spreadsheet and put questions in the first column, and answers (including multiple choice) in the adjacent columns. Meta-data (set description, search tags, runtime options, and so on) isn't required, but can be entered into a separate worksheet as simple key-value pairs. Then, on the iPhone or iPod touch, from within gFlashPro, users are given a list of the available flashcard sets (i.e., spreadsheets) for easy download. Alternatively, they can select flashcard sets from our catalog: a searchable repository of thousands of shared flashcard sets covering virtually any subject.



Once selected, the card set (spreadsheet) is downloaded into gFlashPro and presented to the user for mobile study and quizzing.


A few reasons we chose to use Google Spreadsheets:

• We didn't want to have to write our own server-side flashcard creation code. If we "rolled our own", it would have been code that we'd need to maintain going forward. Using Google Spreadsheets allowed us to leverage the strength of Google's development team, the many built-in functions (e.g., importing .xls), and in the future, Google Gadgets.
• Google's server infrastructure reliability is far better than anything we could possibly afford.
• User authentication is handled by Google. While this is not a huge problem, it's just one more thing that our small development team doesn't need to deal with.

And a few lessons learned:

• There are document limits for each account. In our case, the number and storage of documents is distributed across many thousands of users. Having a shared document in your account doesn't count against that limit.
• While the Objective-C libraries for connecting to Google Docs are incredibly powerful, they are also fairly heavyweight for content-heavy apps like ours. We found that flashcard sets with more than 300 rows would blow out memory on the iPhone because of the substantial number of objects being created for each spreadsheet cell. One alternative we're considering in another application is to write our own XML parser to exclusively process spreadsheet data coming from Google.
  

Any questions? Just email us at info@gwhizmobile.com.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/9KMX9dH7LIY/google-spreadsheets-power-gflashpro.html

Today I'm happy to announce that we've updated Gmail and Calendar for the iPhone. We've completely re-architected the code so you get more consistent performance, refreshed the user interface so it's easier to perform batch actions, and most importantly, laid the foundation which will allow us to iterate quickly and provide you with performance improvements and new features in the future.



To find out more about how you can get all the Gmail goodies, like threaded conversations, search, starring and labels, all on your iPhone, head on over to the Google Mobile Blog. Or, if you're convinced and want to try it out now, go to gmail.com on your iPhone. Click the Calendar link at the top to access Google Calendar. Please note that only iPhone OS 2.2.1 or higher is supported. We're rolling out this release over the next few days, so if you don't see the updated user interface, check back soon.



Posted by Deng-Kai Chen, Google Mobile

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/8K0F-hxBjj4/updated-gmail-and-calendar-for-iphone.html

Guest post by Tom Saxton, Idle Loop Software Design

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/H2zAD3HTXKU/using-google-apis-in-iphone-app.html

Posted by Greg Robbins, Software Engineer

If there's a hole in my memory, it's right where the date of my last tetanus shot should be stored. Luckily, Google Health promises to help us keep track of the many medical details in our lives that would otherwise be lost. But stored information only matters if it's accessible when and where we need it. Independent developer Ford Parsons' application Health Cloud provides access to health profiles quickly and conveniently, for iPhone owners anywhere.

Health Cloud is the first released app to use the Google Data APIs Objective-C Client Library's new support for the Google Health Data API. The recent version 1.7 release of the library also offers a variety of performance and memory improvements for iPhone and Mac developers. It still provides easy access to Google Docs, Picasa Web Albums, YouTube, and many other Google services.

If you have an iPhone or an iPod Touch, you can download Health Cloud today to keep your Google Health account handy. Or if you're a Mac or iPhone developer, check out the Google Data APIs Objective-C Client Library open-source project page for an introduction to adding Google services to your products.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/SsPMp_QVI90/health-and-vigor-in-google-data-apis.html

Over the past few weeks, a number of enhancements have been made to Google's offerings for the iPhone.  We wanted to highlight some of those improvements here.

Google Sync Beta
Google Sync allows you to get your Gmail Contacts and Google Calendar events to your phone.  Once you set up Sync on your phone, it will automatically begin synchronizing your address book and calendar in the background, over-the-air, so you can attend to other tasks. Sync uses push technology so any changes or additions to your calendar or contacts are reflected on your device in minutes.

Learn more on the Google Mobile blog or try Sync at m.google.com/sync.


Tasks
Tasks lets you easily create and manage to-do lists in Gmail and on your iPhone.  While on the go, you can view tasks, add tasks, and mark them as completed. These changes are automatically reflected in Gmail. Using your iPhone, you can also add, edit, and delete entire lists.

Learn more on the Gmail blog or get started with tasks at gmail.com/tasks.


Google Book Search
Over 1.5 million public domain books in the US (and over half a million outside the US) are now available for perusing on your iPhone.  You can search for a title, author, or subject. Or you can browse the list of "Featured books" and various categories like business, the classics, travel, and more.

Learn more on the Google Book Search blog or start reading at http://books.google.com/m.

Edit Docs
Last week, we launched new capabilities to Google Docs for your iPhone that allow you to add new rows, edit existing cells, sort by columns, and filter by terms. Now you don't have to wait until you get to your computer to update a spreadsheet.

Learn more on the Google Docs blog or start editing at m.google.com/docs.


Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/H7GSdqBnyyE/whats-new-for-iphone.html

By Nicholas Jitkoff and Dave MacLachlan, Google Mac Team

One of our goals at Google is to make your search experience as fluid as possible. While much of our work is focused on Google.com, we're trying to make it just as easy to search outside your browser.

For the last year, we have been working on a new, open-source quick search box. Today, we are releasing our first developer preview for the Mac.



This Mac version is much more experimental than its iPhone sibling, Google Mobile App, and through it you will be able to see many of the areas we are exploring: contextual search, actions, and extensibility. It is by no means feature-complete, but is a very good indication of things to come.

If you are interested in participating in our experiment, head over to the Google Code site and give it a try. We are eager to involve users in the development process and will be posting new builds frequently. Over the coming months we'll be posting a few articles about the architecture and interaction we are exploring, and we look forward to your feedback.

Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/LrV6hgt_r1I/search-without-effort-quick-search-box.html

In addition to the Earth Surfer application, our Macworld booth also features a YouTube Upload Booth this year.  Several famed YouTubers stopped in the booth and used Quick Capture to upload their videos to the web.  For instance...

Ijustine jumped in the moment she saw it.

Chris Pirillo had some..ahem..difficulties at first but was able to make it work.

And there were many more excited people ready to try it out!  Check out the video below to hear more about the YouTube booth:


Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/ynFaQdvof-E/youtube-upload-booth.html

By Jason Toff, Google Mac Team

This year for Macworld a Google engineer, David Phillip Oster, wrote a fun application that allows you to surf through Google earth.  Watch the video below and read more about it on the Google Lat Long blog.



Fonte: http://feedproxy.google.com/~r/OfficialGoogleMacBlog/~3/ptR-rmMA57w/surf-through-google-earth.html