[webkit-qt] Qt 4 port of WebKit (was Re: kde-qt-webkit)
simon.hausmann at nokia.com
Wed May 2 05:53:06 PDT 2012
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
> 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
> 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.
More information about the webkit-qt