app_list: Add search box and search result view for v2.

ui/app_list/search_result.h

Index: ui/app_list/search_result.h
diff --git a/ui/app_list/search_result.h b/ui/app_list/search_result.h
new file mode 100644
index 0000000000000000000000000000000000000000..ac74f08570b0433380706d5488235f86a5e34935
--- /dev/null
+++ b/ui/app_list/search_result.h
@@ -0,0 +1,78 @@
+// Copyright (c) 2012 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.
+
+#ifndef UI_APP_LIST_SEARCH_RESULT_H_
+#define UI_APP_LIST_SEARCH_RESULT_H_
+#pragma once
+
+#include <vector>
+
+#include "base/basictypes.h"
+#include "base/string16.h"
+#include "third_party/skia/include/core/SkBitmap.h"
+#include "ui/app_list/app_list_export.h"
+#include "ui/base/models/list_model.h"
+#include "ui/base/range/range.h"
+
+namespace app_list {
+
+// SearchResult consists of an icon, a title text and a details text. Title and

[sky, 2012/05/22 22:16:06]

'SearchResult consists of an icon, a title text and a details text' ->
SearchResult consists of an icon, title text and details text.

[xiyuan, 2012/05/23 21:25:22]

Done.

+// details text could have tagged ranges that are displayed differently from

[sky, 2012/05/22 22:16:06]

could -> can

[xiyuan, 2012/05/23 21:25:22]

Done.

+// default style.
+class APP_LIST_EXPORT SearchResult {
+ public:
+  // A tagged range in search result text.
+  struct Tag {
+    // Similar to ACMatchClassification::Style, the style values are not
+    // mutually exclusive.
+    enum Style {
+      NONE  = 0,
+      URL   = 1 << 0,
+      MATCH = 1 << 1,
+      DIM   = 1 << 2,
+    };
+
+    Tag(int styles, size_t start, size_t end)
+        : styles(styles),
+          range(start, end) {
+    }
+
+    int styles;
+    ui::Range range;
+  };
+  typedef std::vector<Tag> Tags;
+
+  SearchResult();
+  virtual ~SearchResult();

[sky, 2012/05/22 22:16:06]

Why did you make it so that folks subclass this? Since they can't really
override any behavior wouldn't a method to configure a SearchResult for a
particular use be better?

[xiyuan, 2012/05/23 21:25:22]

Subclass is allowed here because SeachResult is really a simple model that only
carries data needed for UI. AppListDelegate would have problem to OpenResult
with just this amount of data. If we don't allow subclass, then we need to
provide an ID or something so that AppListDelegate could know how to OpenResult.
Using subclass, we could carry extra information with a SearchResult and make it
easy for the delegate to implement open.

In the current CL, both chrome search and ash_shell search is doing it this way.
Chrome search embeds an AutocompleteMatch and ash_shell search embeds a window
launch type. And the delegate could figure out how to do "open" directly from
this extra data in the SearchResult passed back.

+
+  const SkBitmap& icon() const { return icon_; }
+  void set_icon(const SkBitmap& icon) { icon_ = icon; }
+
+  const string16& title() const { return title_; }
+  void set_title(const string16& title) { title_ = title;}
+
+  const Tags& title_tags() const { return title_tags_; }
+  void set_title_tags(const Tags& tags) { title_tags_ = tags; }
+
+  const string16& details() const { return details_; }
+  void set_details(const string16& details) { details_ = details; }
+
+  const Tags& details_tags() const { return details_tags_; }
+  void set_details_tags(const Tags& tags) { details_tags_ = tags; }
+
+ private:
+  SkBitmap icon_;

[sky, 2012/05/22 22:16:06]

ImageSkia

[xiyuan, 2012/05/23 21:25:22]

Done.

+
+  string16 title_;
+  Tags title_tags_;
+
+  string16 details_;
+  Tags details_tags_;
+
+  DISALLOW_COPY_AND_ASSIGN(SearchResult);
+};
+
+}  // namespace app_list
+
+#endif  // UI_APP_LIST_SEARCH_RESULT_H_