[Webkit-unassigned] [Bug 41616] [Chromium] DeviceOrientation plumbing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 28 13:35:26 PDT 2010


Dean Jackson <dino at apple.com> changed:

           What    |Removed                     |Added
                 CC|                            |dino at apple.com

--- Comment #22 from Dean Jackson <dino at apple.com>  2010-07-28 13:35:26 PST ---
I have some (probably stupid) questions about the design that will help me do the same for AccelerometerEvents. I expect I misunderstand the way WebKit approaches these things, so sorry in advance.

Why do you need the didChangeDeviceOrientation method on WebView? My thought was that your real implementation would be the ClientImpl (or an instance of it), and when the orientation actually changes it gets to the controller via the view -> page -> controller link. It seems weird (to me) that you have the ClientImpl called by WebView, and then have it go back to the view to call the controller. 

In other words, why doesn't your platform implementation of the client just call directly into the controller?

Here's what I was thinking of doing (for Accelerometer):

A WebAccelerometerClient class in WebKit/WebCoreSupport that implements the WebCore::AccelerometerClient interface. Then the real implementation is a WebAccelerometerClientCoreMotion object. This is instantiated in the WebView platform code, and passed in as you construct the Page (and thus given to the AccelerometerController). 

That way we don't need the start/stopDeviceOrientationUpdates methods on the WebView client either. The controller already tells the client when to start or stop updating. Or is there some reason you want WebView to be able to start/stop?

Again, sorry if these questions show my lack of understanding!

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list