On 07/01/2011 11:46 AM, ext Kenneth Rohde Christiansen wrote:
We have been playing with the code, trying to break it in less monstruous
parts.
This is available here:
https://github.com/kling/webkit/tree/master/Source/WebKit2/UIProcess/API/qt
The goals:
-clarify the responsibilities of each class
-the view should not be aware of WebKit internals, QWebPageProxy is our door
to the internal APIs.
I guess this depends on what you call internals. The process
separation already limits this in many ways. So what you are trying is
to get rid of IntRect etc? Does it makes sense to wrap let's say
viewport meta in our own class just to accomplish this? Not that I am
against your suggestion, I just wanted to know if there is a real
advantage in this? If WebCore/WebKit2 api changes,
we will probably have to change our classes as well.
By internal I mean all the stuff in namespace WebCore, WebKit, WTF, etc.
I think there is no problems if classes like ViewportAttributes go to
the upper layer. I am only concerned of the view knowing everything
about the internals like QGraphicsWKView today.
-simplify APIs to something minimal: QMobileWebView (the viewport) +
QMobileWebPage (the view on the page) for mobile. QDesktopWebView as the
only view for mobile.
These names confuse me. The C++ api is for people knowing what they
are doing, everyone else should just be using our [future] QML view.
What about QMobileWebViewport and QWebPageContents or similar?
Would someone (C++ api user) ever need to access the api of the
QWebPageContents directly? Does it makes sence? or is it an
implementation detail?
The only thing exposed will be QML yes, the names are internal.
Let's not bikeshed too much on this before we need to expose the APIs...
We already had quite some of that yesterday on IRC :)
The one popular suggestion I have seen yesterday is to rename QMobileXXX
to QTouchXXX
When events come up from the WebKit internals to Qt, the path is:
-QWebPageProxy -> ViewInterface -> QDesktopWebPage /
(QMobileWebView|QMobileWebPage).
The view interface is an interface abstracting the fact that the mobile view
is not one but two views. It is also a way to not clutter the subclasses of
QWebPageProxy by making them the delegate of every function of the
PageClient.
ViewInterface seems pretty much what was the idea of PageClient,
except the part where you are "filtering" what we are not currently
needing. Why not just call it QtPageClient or so to not make this more
confusing than needs to be.
Nope it is not.
The implementation of the page client still exist. I think mixing
PageClient and the calls to the views would be even more confusing than
what is on trunk at the moment.
cheers,
Benjamin
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
