[webkit-reviews] review denied: [Bug 43258] Implement chromium WebDeviceOrientationClient wrapper and have WebViewImpl get it from WebViewClient. : [Attachment 63312] Patch
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Aug 3 03:23:54 PDT 2010
Jeremy Orlow <jorlow at chromium.org> has denied hans at chromium.org's request for
review:
Bug 43258: Implement chromium WebDeviceOrientationClient wrapper and have
WebViewImpl get it from WebViewClient.
https://bugs.webkit.org/show_bug.cgi?id=43258
Attachment 63312: Patch
https://bugs.webkit.org/attachment.cgi?id=63312&action=review
------- Additional Comments from Jeremy Orlow <jorlow at chromium.org>
WebKit/chromium/src/WebDeviceOrientationClientDummy.cpp:37
+ DeviceOrientationClientDummy() :
orientation(WebCore::DeviceOrientation::create()) { }
usually we split onto 2 lines right before the :
WebKit/chromium/public/WebDeviceOrientation.h:32
+ #include <wtf/PassRefPtr.h>
You can just do "namespace WTF { template <typename T> class PassRefPtr; }"
WebKit/chromium/public/WebDeviceOrientation.h:43
+ initialize(canProvideAlpha, alpha, canProvideBeta, beta,
canProvideGamma, gamma);
Darin, in the past you've been pretty adamant that constructors be inline. Do
you think that doing it this way is better than the alternative? I'm not so
sure.
WebKit/chromium/public/WebDeviceOrientation.h:48
+ operator PassRefPtr<WebCore::DeviceOrientation>() const;
add the other 2 operators we have in just about every other class like this
WebKit/chromium/public/WebDeviceOrientationClient.h:50
+ WebDeviceOrientationClient() { }
This works?? I'm pretty sure this will need to be public and virtual.
WebKit/chromium/src/WebViewImpl.cpp:267
+ ,
m_webDeviceOrientationClient(WebRuntimeFeatures::isDeviceOrientationEnabled() ?
(client ? client->createWebDeviceOrientationClient() :
WebDeviceOrientationClientDummy::create()) : 0)
What is the dummy for? I don't think client can ever be non-null. And, if it
can be, then we should just assume the device orientation client is null too
then.
I don't see any point to the dummy. I'd rather not add logic to WebKit to
handle the client and DOclient being null unless there's already precedent.
But even if so, I think that's better than having some dummy client.
Another option, if all else fails, you could just allocate the mock.
hmmm...lets just talk in person
More information about the webkit-reviews
mailing list