Add a skeleton Start Page to the experimental app list.

ui/app_list/views/start_page_view.cc

+// Copyright 2014 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.
+
+#include "ui/app_list/views/start_page_view.h"
+
+#include "content/public/browser/web_contents.h"
+#include "ui/app_list/app_list_constants.h"
+#include "ui/app_list/views/app_list_main_view.h"
+#include "ui/app_list/views/search_box_view.h"
+#include "ui/gfx/canvas.h"
+#include "ui/views/controls/button/custom_button.h"
+#include "ui/views/controls/webview/webview.h"
+#include "ui/views/layout/box_layout.h"
+
+namespace app_list {
+
+namespace {
+
+const int kTopMargin = 20;
+
+const int kWebViewWidth = 200;
+const int kWebViewHeight = 95;
+
+const int kInstantContainerSpacing = 15;
+const int kFakeBarWidth = 350;
+const int kFakeBarHeight = 30;
+
+class FakeBarButton : public views::CustomButton {

[tapted, 2014/05/07 08:19:17]

needs a class comment. Also FakeFoo sounds odd outside of a test. If the comment
would be along the lines of ~this is a placeholder until we get assets - maybe
better to just to pick an appropriately sized constant image from
ui_resources.grd

[calamity, 2014/05/08 07:46:32]

Ok. This was named after the NTP's UI element which has been referred to has the
fakebar.

+ public:
+  explicit FakeBarButton(views::ButtonListener* listener)
+      : views::CustomButton(listener) {}
+
+  virtual ~FakeBarButton() {}
+
+  // Overridden from views::View:
+  virtual gfx::Size GetPreferredSize() OVERRIDE {
+    return gfx::Size(kFakeBarWidth, kFakeBarHeight);
+  }
+
+  virtual void OnPaint(gfx::Canvas* canvas) OVERRIDE {
+    PaintButton(
+        canvas,
+        state() == STATE_HOVERED ? kPagerHoverColor : kPagerNormalColor);
+  }
+
+ private:
+  // Paints a rectangular button.
+  void PaintButton(gfx::Canvas* canvas, SkColor base_color) {
+    gfx::Rect rect(GetContentsBounds());
+    rect.ClampToCenteredSize(gfx::Size(kFakeBarWidth, kFakeBarHeight));
+
+    SkPaint paint;
+    paint.setAntiAlias(true);
+    paint.setStyle(SkPaint::kFill_Style);
+    paint.setColor(base_color);
+    canvas->DrawRect(rect, paint);
+  }
+
+  DISALLOW_COPY_AND_ASSIGN(FakeBarButton);
+};
+
+}  // namespace
+
+StartPageView::StartPageView(AppListMainView* app_list_main_view,
+                             content::WebContents* start_page_web_contents)
+    : app_list_main_view_(app_list_main_view),
+      instant_container_(new views::View) {
+  AddChildView(instant_container_);
+  instant_container_->SetLayoutManager(new views::BoxLayout(

[xiyuan, 2014/05/07 17:32:16]

Why do we need |instant_container_|? Since app list is fixed size, we can use
constant padding. And BoxLayout's spacing args and/or adding EmptyBorder to
StartPageView are probably sufficient. If setting them right, we can get rid of
Layout.

[calamity, 2014/05/08 07:46:32]

This is mostly in preparation for adding the app tiles below the halfway point
and the search results in the top half. We will need to replace the instant
container with the search results when the search box button is clicked while
keeping the tiles visible. Having the instant_container is a useful way to group
the instant elements.

+      views::BoxLayout::kVertical, 0, kTopMargin, kInstantContainerSpacing));
+
+  views::WebView* web_view =
+      new views::WebView(start_page_web_contents->GetBrowserContext());
+  web_view->SetPreferredSize(gfx::Size(kWebViewWidth, kWebViewHeight));
+  web_view->SetWebContents(start_page_web_contents);
+
+  instant_container_->AddChildView(web_view);
+  instant_container_->AddChildView(new FakeBarButton(this));

[xiyuan, 2014/05/07 17:32:16]

Looks like we are using FakeBarButton as the placeholder searchbox that triggers
the real searchbox? If so, why do it this way instead of doing it in webui? What
if we need later to add some contents below the bar?

[calamity, 2014/05/08 07:46:32]

We will be adding app tiles below the bar. It's unclear whether we want to do
this via views or the webui. The current approach seems to be to use views where
possible since webui is often slow.

+}
+
+StartPageView::~StartPageView() {
+}
+
+void StartPageView::Layout() {
+  gfx::Rect rect(GetContentsBounds());
+
+  // Makes |instant_container_| horizontally center and vertically fill.
+  gfx::Size instant_container_size(instant_container_->GetPreferredSize());
+  gfx::Rect top_half_bounds(
+      rect.CenterPoint().x() - instant_container_size.width() / 2,
+      rect.y(),

[tapted, 2014/05/07 08:19:17]

this looks out of place - I think only the width/height of GetContentsBounds
matter -- x/y should always be zero unless borders are involved. Maybe just a
literal 0 here?

[xiyuan, 2014/05/07 17:32:16]

x/y might not be zero when a view has padding around it's content area, i.e.
GetInsets() returns non-empty Insets. rect.y() is good here.

+      instant_container_size.width(),
+      rect.height() / 2);

[tapted, 2014/05/07 08:19:17]

Why /2 here? (doesn't seem to match the comment - to fill)

[calamity, 2014/05/08 07:46:32]

Deleted this whole thing.

+  instant_container_->SetBoundsRect(top_half_bounds);
+}
+
+void StartPageView::ButtonPressed(views::Button* sender,
+                                  const ui::Event& event) {
+  app_list_main_view_->search_box_view()->SetVisible(true);
+  app_list_main_view_->search_box_view()->RequestFocus();

[xiyuan, 2014/05/07 17:32:16]

This feels strange that when user clicks on place A, focus goes to place B.

Another concern is whether user is able to restore the UI and get the real
search-box hidden again?

[calamity, 2014/05/08 07:46:32]

This is the behavior specified by the mocks. The mocks have a nice animation for
the bar which masks the focus shift.
Not at present. The view will need to change for the search box's behavior but I
think that's beyond the scope of this CL.

+}
+
+}  // namespace app_list