MacViews: Implement Force Touch/Mac dictionary lookup for Textfields.

ui/views/word_lookup_client.h

+// Copyright 2016 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_VIEWS_WORD_LOOKUP_CLIENT_H_
+#define UI_VIEWS_WORD_LOOKUP_CLIENT_H_
+
+#include "ui/views/views_export.h"
+
+namespace gfx {
+struct DecoratedText;
+class Point;
+}  // namespace gfx

[tapted, 2016/10/05 06:20:55]

nit: comments aren't usually put at the end of namespaces filled just with
forward declares

[karandeepb, 2016/10/06 01:07:05]

Done.

+
+namespace views {
+
+// An interface implemented by a view which supports word lookups.
+class VIEWS_EXPORT WordLookupClient {
+ public:
+  // Retrieves the word displayed at the given |point| along with its styling
+  // information. |point| is in the coordinate system of the view. If no word is
+  // displayed at the point, returns a nearby word. |baseline_point| should
+  // correspond to the baseline point of the leftmost glyph of the |word| in the
+  // view's coordinates. Returns false, if no word can be retrieved.
+  virtual bool GetDecoratedWordAtPoint(const gfx::Point& point,
+                                       gfx::DecoratedText* decorated_word,
+                                       gfx::Point* baseline_point) = 0;
+
+ protected:
+  ~WordLookupClient() {}

[tapted, 2016/10/05 06:20:55]

declare virtual? (or can it be omitted whilst there are no members?)

[sky, 2016/10/05 16:15:36]

Generally we declare the destructor in pure virtual interfaces, and you are
right it should be virtual.

[karandeepb, 2016/10/06 01:07:05]

Declared virtual. I think if we omit the destructor, it would be public and
non-virtual.

Also, just for my own understanding, is declaring it virtual wrong, if I don't
expect the instance to be deleted  through a base class pointer and if there is
no "delete this" in the base class implementation. 

[karandeepb, 2016/10/06 01:07:05]

Done.

[tapted, 2016/10/06 02:03:19]

Hypothetically, I think a future subclass we don't know about yet could still
invoke it incorrectly. But this is one of those often-debated things that don't
have a clear answer, so we defer to consistency -- "whatever most of Chrome
already does in this case".

(then I started looking around for some C++1?ish way to delete a destructor
implementation we know is going to be trivial [without breaking polymorphism]  -
i.e. if something *did* invoke the base class destructor external to the class
hierarchy then just crash - but that doesn't seem to be a thing).

[karandeepb, 2016/10/06 02:23:02]

Makes sense, thanks!

+};
+
+}  // namespace views
+
+#endif  // UI_VIEWS_WORD_LOOKUP_CLIENT_H_