[webkit-qt] Qt5: Dependencies to private Qt APIs

[Alexis Menard]

Hi,

On Wed, Dec 14, 2011 at 10:10 AM, Simon Hausmann
<simon.hausmann at nokia.com> wrote:
> 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?

I'm fine with that in general as it is easier for us to support in the
meantime. Though knowing some history about that I'm not sure
Flickable will ever ever have a public C++ API. So we have to be *very
very very* cautious on which private APIs we use as it will get hell
otherwise. Private API is the last chance I'd say and the exception.

We also need to be able to have security releases faster than today.
At some point maybe we'll have a person taking care of security and we
need to be able to release security updates of QtWebKit without a huge
pain.

Globally I was not fan of decoupled releases because it was hard to
maintain for us. The only benefit was that Qt minor releases were so
slow to go out that you may want to get a newer WebKit version in
between. That will have to be solved later if 5.1 takes forever.

Now I'd say for 5.0 it is fine enough. We'll bring the topic back later.

>
>
> Simon
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil