[webkit-qt] Qt 4 port of WebKit (was Re: kde-qt-webkit)

[Simon Hausmann]

On Wednesday, May 02, 2012 09:52:50 AM ext Girish Ramakrishnan wrote:
> Hi,
> 
> On Wed, May 2, 2012 at 5:53 AM, Simon Hausmann <simon.hausmann at nokia.com> 
wrote:
> > On Wednesday, April 25, 2012 02:09:27 AM ext Andrea Diamantini wrote:
> >> Hi all,
> >> I'm here to announce the will to work on an unofficial branch of
> >> qtwebkit, living on gitorious as
> >> https://gitorious.org/~adjam/webkit/kde-qt-webkit.
> >> 
> >> Given qtwebkit devs intention to no more develop the WebKit1 bits of the
> >> qt port and considering the needs of kde webkit browsers (you may know
> >> I'm just developing one), I decided to try working a bit on it with some
> >> minimal targets.
> >> In my idea, kde-qt-webkit releases should be drop-in replacement for the
> >> qtwebkit lib provided with qt 4.x, so that we can i.e. compile kdewebkit
> >> against this new library without problems. In fact, no real kde
> >> integration will be provided (that is, kio and k- classes will continue
> >> living outside webkit code). At least for the qt4/kde4 release cycle.
> >> 
> >> Targets for this port are:
> >> 
> >> - let the branch synced with svn webkit master.
> >> 
> >> - merge Lindsay Mathieson work about spellcheck support
> >> 
> >> - let html5 audio/video work as best as possible, eventually switching
> >> back to the phonon implementation (and that's because I cc'ed in this
> >> mail Harald Sitter, actual phonon maintainer)
> >> 
> >> - (eventually) let (kde-)-qt-webkit compile with cmake
> >> 
> >> - fix some of the kdewebkit integration known issues pending like (and
> >> here is adawit cc):
> >> 
> >> * [QtWebKit] Form completion like the one available in native Qt widgets
> >> such
> >>    as QLineEdit is missing due to lack of access to form elements.
> >>    See http://webkit.org/b/36668.
> >> 
> >> and so on
> >> 
> >> - do some bugfixing and gain some webkit development experience.
> >> 
> >> - backport at least one fix :)
> >> 
> >> 
> >> The idea is just to work on this until kde5 (whose release data is
> >> probably comparable with that of qt 5.1) and then decide again what to
> >> do (basically dropping out WebKit1 support and moving to qt5/webkit2 or
> >> continue this experience becoming a "more official" full kde webkit port.
> >> 
> >> Hints and comments are welcome.
> > 
> > I think this is a good move. I suggest to take this even further and think
> > of it as the continuation of the Qt 4 port of WebKit that _follows_ trunk
> > but is maintained outside of trunk.
> > 
> > Are you open to the idea of making it a little bit more generic? I'm
> > reasonably optimistic that other parties might be interesting in joining.
> > (I wouldn't worry about things like Symbian support, btw)
> > 
> > If this succeeds, then the Qt 4 port can live on a while longer and you
> > guys can gain some experience hacking on WebKit.
> > 
> > In the meantime we can reduce the maintenance on trunk.
> 
> I also like the idea of having QtWebKit 1 based on Qt4 outside trunk.
> Many companies still rely on Qt4/QtWebKit and would like to see a 2.3
> release. It would be greatly helpful, if you guys can make releases
> non-KDE specific.

Much agreed. A new 2.3 release could be the result for example.

> Also, do I understand correctly that QtWebKit1 on Qt5 will still be
> supported in trunk for the lifetime of Qt5? 

Yes. Or let's put it this way: The lifetime of that API should be tied to the 
lifetime of QtWidgets :)

> Is anyone actively
> maintaining it (by which I mean adding new API, new developments etc)
> ?

I would say it's in the "Done" state currently.

> If not, I will be happy to pick this up. I have a few things on my
> plate right now, so not immediately, but give me a month's time.

One particular item that would be most a most-welcome contribution would be 
towards allowing a library split that tears out QWebView/QGraphicsWebView into 
a QtWebKitWidgets library and connects to libQtWebKit.so using a thin private 
API. The former depends on QtWidgets, the latter doesn't.


Simon