Hi, In the past we had a strict rule to not use any private APIs from Qt (4), which allowed us to make separate releases and support building against multiple Qt versions at the same time without too much #ifdeffery.
With the builds against Qt 5 we are dealing with a platform that is vastly different to what Qt 4 was to WebKit: The features we rely on are young and subject to change. An example of this is our intent of using the QML flickable component for the WebView to allow for user interaction that is consistent with the rest of QML. The flickable as C++ component (the way we need to use it) however is only private API in Qt 5. Similarly there may be functionality from the Qt 5 scene graph that we need in order to implement proper rendering which may only be available to us as private APIs. (A third example is the use of Qt's copy of V8, which is also technically private API) So unlike with Qt 4, this time in order to achieve some of our goals we may have to resort to depending on functionality in Qt 5 that is private at the moment. A result of such a dependency is that we more or less loose the ability to release independently, at least not without risking major maintenance overhead when it comes to supporting multiple versions of Qt 5 at the same time. I suggest that we tie ourselves back to Qt 5 releases and allow the (controlled) use of private Qt 5 APIs for the time being, in order to achieve a perfect QML and scene graph integration. When these features stabilize and at some point become available through public APIs, then we should consider resorting to the old rule. What do you guys think? Simon _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
