> > The main thing missing is one or more tests that shows that the refactoring > solves problem(s). > The testcase for https://bugs.webkit.org/show_bug.cgi?id=35051 can easily > be turned into an autotest. >
Agreed! Will work on that. What will QWebPage::view() return after you've set a QGraphicsWidget as view > (0, since QGraphicsWidget is not a QWidget)? Shouldn't there be a > corresponding getter for it? > Yes, I thought about this and talked with Kenneth about it. My first patch returned the QGraphicsView parent of the QGraphicsWidget, but later we decided to return 0 for this use case... Any better ideas? > I recall Benjamin commenting that if we had thought about this use case > earlier (hindsight is always 20-20, right), there would be an interface you > could implement and pass to setView(), rather than hardcoding another type > (how long until we have to add another overload to setView()? :) ). But > that's too late... > > Yes, we had this same idea! Let's keep this in mind for the next generation QtWebKit... ;) Regards, jesus 2010/4/29 Kent Hansen <[email protected]> > ext Jesus Sanchez-Palencia wrote: > >> Hello there, QtWebKit hackers! >> > > Hi! > > > >> I've been working on a PageClient refactor for QtWebKit. >> The main motivation for this came from the fact that nowadays our API has >> QWebPage::setView(QWidget*) but has nothing to deal with QGraphicsWidgets. >> > > Cool! > > > I'd like some feedback from you in order to understand what do you think >> about this patch and if you consider this new setView API a valid use case >> or not. >> I'm aware that Plasma (from KDE) is using it and that it might be useful >> for the QML folks. >> > > The main thing missing is one or more tests that shows that the refactoring > solves problem(s). > The testcase for https://bugs.webkit.org/show_bug.cgi?id=35051 can easily > be turned into an autotest. > > What will QWebPage::view() return after you've set a QGraphicsWidget as > view (0, since QGraphicsWidget is not a QWidget)? Shouldn't there be a > corresponding getter for it? > > I recall Benjamin commenting that if we had thought about this use case > earlier (hindsight is always 20-20, right), there would be an interface you > could implement and pass to setView(), rather than hardcoding another type > (how long until we have to add another overload to setView()? :) ). But > that's too late... > > Regards, > Kent > > _______________________________________________ > webkit-qt mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt >
_______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
