Initial views touchui GestureRecognizer support

views/widget/root_view.cc

Index: views/widget/root_view.cc
diff --git a/views/widget/root_view.cc b/views/widget/root_view.cc
index b4467f490ca0c41a88cd4b179ea8db0066e88a84..5672e7a7b00364c2b8168819b3d03ac18fdbdfde 100644
--- a/views/widget/root_view.cc
+++ b/views/widget/root_view.cc
@@ -6,8 +6,10 @@
 
 #include <algorithm>
 
+#include "base/command_line.h"
 #include "base/logging.h"
 #include "base/message_loop.h"
+#include "chrome/common/chrome_switches.h"
 #include "ui/base/accessibility/accessible_view_state.h"
 #include "ui/base/dragdrop/drag_drop_types.h"
 #include "ui/base/keycodes/keyboard_codes.h"
@@ -38,11 +40,16 @@ RootView::RootView(Widget* widget)
       last_mouse_event_flags_(0),
       last_mouse_event_x_(-1),
       last_mouse_event_y_(-1),
-      gesture_manager_(GestureManager::GetInstance()),
+      gesture_manager_(NULL),
       touch_pressed_handler_(NULL),
+      gesture_handler_(NULL),
       ALLOW_THIS_IN_INITIALIZER_LIST(focus_search_(this, false, false)),
       focus_traversable_parent_(NULL),
       focus_traversable_parent_view_(NULL) {
+  if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kEnableGesture))

[rjkroege, 2011/11/01 18:42:22]

I don't think you want to do it this way. 

My preference would be to proceed as follows: interpose the gesture recognizer
between the current gesture manager and the new gr so that touch events first
enter the new gr, the gestures get dispatched, if no views want the new
gestures, then let the existing gm create mouse events and dispatch that.

This way, you don't need to have special command line switches.

If you do want to proceed this way, I'd make an abstract factory that creates
gesture_manager_ instances.

[Gajen, 2011/11/02 12:59:35]

  Currently is it done same way in GR's PTEFG, where 1st gestures are recognized
and passed to view's hierarchy by calling ForwardGestureEvents(), and if 1)
gestures are not recognized, OR any of the recognized gesture is not handled by
view' hierarchy, then mouse events are simulated by calling parent's PTEFG i.e
GestureManger::PTEFG.
 I guess switch would be better till we fully integrate all kinda Gestures
(single/multi),at least provides us to switch back to old way.
I can go either of way.
1.Interposing GR: Below is my understanding of your suggestion: 
    1.1 GR won't be derived from GM, and GM would hold instance of GR.
    1.2, inside GM's PTEFG() call GR's PTEFG()(or some renamed funct, as not 
being derived from GR), would recognize the Gestures and forwards them to
RootView.
    1.3 if no Gestures are recognized or handled by above process then simulate
mouse events as per GM's PTEFG.


2.switch+ABS factory: Almost all is done except below:
    2.1 Add a new file gesture_manager_factory.h declare interface for ABS
factory.
    2.2 Add new file gesture_manager_factory.cc, define
       ABS GestureManagerFactoy, DefaultGestureManagerFactory to cerate GM, and
GestureRecognizerFactory to create GR

Option 1 needs less code size than option 2, I'm open for any approach, please
do let me know which one to choose and correction in above understanding.

[rjkroege, 2011/11/04 17:19:28]

Currently, we have the following: RootView::OnTouchEvent gets touch events. All
of them are dropped into GM::PTEFG. It dispatches synthetic mouse events into
the RootView directly.

As evolved in the WebKit version of the GestureRecognizer, this is a bad design
because it makes the GestureManager dependent on RootView. The GestureManager
does not need to depend on RootView. It only needs to know about events. Events
are separate from views thanks to the ongoing aura effort. Instead, as with the
WebKit GestureRecognizer, the Chrome GestureManager could return an array of
events to the RootView. The RootView could then dispatch these events.

At present, we need to convert touch events into mouse events so that existing
views code continues to work properly. I want gesture delivery and synthetic
mouse event delivery to co-exist so that we can incrementally develop new views
components that respond to gestures while retaining touch navigation of the
chrome touchui build. This means that we need code that can deliver both gesture
events *and* synthetic mouses at runtime.

We want to be able to write views controls that respond to mouse or gesture
events and treats them differently. This means that we need to code up gesture
recognition so that we don't generate synthetic mouse events *if* gesture events
have been handled.

I think that we can accomplish as follows:

1. RootView::OnTouchEvent looks mostly like now. Except that it uses a
GestureRecognizer instance. This returns an array of gestures. Which OTE
dispatches to RootView::OnGestureEvent.

2. RootView::OnGestureEvent calls gesture_manager_ the way that OTE currently
does *if* there is no consumer of the event. This will require assorted TODOs to
indicate that it will be removed.

3. GestureRecognizer does not need to be subclass of GestureManager. Instead, we
simply transition to the newer/better GR.

[Gajen, 2011/11/08 08:11:44]

Look promising and Great.
Can we push current implementation and then take up this Design/Refactoring
activity in next immediate high priority CL,  As I have Verified current
approach and tested GR mouse conversion and Gesture events(Tap, Tap down)
through view_unittest

Added a TODO for same.

+    gesture_manager_ = GestureRecognizer::GetInstance();
+  else
+    gesture_manager_ = GestureManager::GetInstance();
 }
 
 RootView::~RootView() {
@@ -400,6 +407,52 @@ void RootView::GetAccessibleState(ui::AccessibleViewState* state) {
   state->role = ui::AccessibilityTypes::ROLE_APPLICATION;
 }
 
+bool RootView::ForwardGestureEvents(GestureRecognizer::Gestures* gestures) {
+  scoped_ptr<GestureRecognizer::Gestures> events;
+  events.reset(gestures);
+  bool return_value = false;
+  for (unsigned int i = 0; i < events->size(); i++) {
+    GestureEvent* event = gestures->at(i).GetGestureEvent();
+    GestureEvent e(*event, this);
+
+    ui::GestureStatus status = ui::GESTURE_STATUS_UNKNOWN;
+
+    // Walk up the tree until we find a view that wants the gesture event.
+    for (gesture_handler_ = GetEventHandlerForPoint(e.location());
+         gesture_handler_ && (gesture_handler_ != this);
+         gesture_handler_ = gesture_handler_->parent()) {
+      if (!gesture_handler_->IsEnabled()) {
+        // Disabled views eat events but are treated as not handled by the
+        // the GestureManager.
+        status = ui::GESTURE_STATUS_UNKNOWN;
+        break;
+      }
+
+      // See if this view wants to handle the Gesture.
+      GestureEvent gesture_event(e, this, gesture_handler_);
+      status = gesture_handler_->ProcessGestureEvent(gesture_event);

[rjkroege, 2011/11/01 18:42:22]

see comment about gesture_handler_ -- please rename.

[Gajen, 2011/11/08 08:11:44]

Done.

+
+      // The view could have removed itself from the tree when handling
+      // OnGestureEvent(). So handle as per OnMousePressed. NB: we
+      // assume that the RootView itself cannot be so removed.
+      if (!gesture_handler_)
+        break;
+
+      // The gesture event wasn't processed. Go up the view hierarchy and
+      // dispatch the gesture event.
+      if (status == ui::GESTURE_STATUS_UNKNOWN) {
+        continue;
+      } else if (status == ui::GESTURE_STATUS_CONSUMED) {
+        return_value = true;
+      } else {
+        return_value = false;
+      }
+    }
+    if (!return_value) return false;
+  }
+  return return_value;
+}
+
 ////////////////////////////////////////////////////////////////////////////////
 // RootView, protected:
 
@@ -413,6 +466,8 @@ void RootView::ViewHierarchyChanged(bool is_add, View* parent, View* child) {
       mouse_move_handler_ = NULL;
     if (touch_pressed_handler_ == child)
       touch_pressed_handler_ = NULL;
+    if (gesture_handler_ == child)
+      gesture_handler_ = NULL;
   }
 }