client-side wheel mouse support

remoting/client/input_handler.cc

Index: remoting/client/input_handler.cc
diff --git a/remoting/client/input_handler.cc b/remoting/client/input_handler.cc
index c203f54fb4962830e8b014a01d54280a4aaece3f..fe120d0250df7f78abdb0f9a45f83e6f5088ad94 100644
--- a/remoting/client/input_handler.cc
+++ b/remoting/client/input_handler.cc
@@ -55,4 +55,19 @@ void InputHandler::SendMouseButtonEvent(bool button_down,
   }
 }
 
+void InputHandler::SendMouseWheelEvent(int dx, int dy,
+                                       int clicks_x, int clicks_y, bool page) {
+  protocol::InputStub* stub = connection_->input_stub();
+  if (stub) {
+    MouseEvent* event = new MouseEvent();
+    event->set_wheel_offset_x(dx);
+    event->set_wheel_offset_y(dy);
+    event->set_wheel_clicks_x(clicks_x);
+    event->set_wheel_clicks_y(clicks_y);
+    event->set_wheel_by_page(page);
+
+    stub->InjectMouseEvent(event, new DeleteTask<MouseEvent>(event));

[Wez, 2011/03/16 11:40:40]

Niggle:  I'm not keen on "InjectXXX" as client-side functions - conventionally
it's the Host that "injects" events into the host system.

[garykac, 2011/03/16 20:43:43]

This is a side-effect of having a common stub interface that used on both sides:
host and client.

Advantage: only one interface file to update
Disadvantage: goofy names that are inappropriate for one side or the other

Albert was the big proponent of this. Since he's there in London, he can
probably give you a coherent argument in person. ^_^

+  }
+}
+
 }  // namespace remoting