Skeleton for app_list on OSX, and refactoring for enable_app_list=1 on OS=="mac".

ui/app_list/cocoa/app_list_view.h

Index: ui/app_list/cocoa/app_list_view.h
diff --git a/ui/app_list/cocoa/app_list_view.h b/ui/app_list/cocoa/app_list_view.h
new file mode 100644
index 0000000000000000000000000000000000000000..241b5a56335c379909c6af3ea3738c0135835dbb
--- /dev/null
+++ b/ui/app_list/cocoa/app_list_view.h
@@ -0,0 +1,13 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#import <Cocoa/Cocoa.h>
+
+@interface AppListView : NSWindow {

[sail, 2013/01/08 07:25:27]

Would AppListWindow or AppListViewWindow be a better name?

[sail, 2013/01/08 07:41:12]

Also, where is this bubble being shown from (a browser toolbar, web page, OS X
dock, etc...)? If it's from the browser window you'll probably want a bunch of
standard stuff that the other browser window bubbles already have. To get this
you'll either have to refactor the bubble code from chrome/browser/ui/cocoa or
move this class.

[tapted, 2013/01/09 04:29:49]

It will be a bubble shown from the OSX Dock, possibly without any browser
windows visible. (And, on Windows, there is a flow where the user does not have
Chrome Browser visibly installed at all, but that might not be a priority for
the OSX app_list port). I did have an initial look at the various cocoa bubbles
under chrome/browser -- I will certainly be mining them for ideas, and mapping
out refactoring opportunities where I can. Although, there is not currently a
/ui/cocoa (like there is a /ui/views), so there are some logistics to tackle
there.

There's a tricky balance between how closely to mirror the toolkit-views
/ui/app_list and whether to lean on cocoa parts in /chrome/browser/ui. The
current plan is to keep the new app_list things out of /chrome/browser as much
as possible, to minimise coupling.

The rationale here for the name, "AppListView" was more on the "mirror
toolkit-views" side of the balance. At a high level, I think the existing
approach there is to populate the view and wrap it in a native window once we
know how big the view will be, and use the view as the main handle in the
controller. For the initial skeleton I wanted something basic, so it's just the
NSWindow with no views yet. However, you are right that it is confusing.

I've renamed this to AppListViewWindow (and updated filenames/gyp/etc.) so that
it's clearer that it's still the NSWindow at this point.

+ @private

[sail, 2013/01/08 07:25:27]

remove?

[tapted, 2013/01/09 04:29:49]

Done.

+}
+
+- (id)initAsBubble;
+
+@end