[rekonq] Multiprocess Rekonq?

[Andrea Diamantini]

On 03/05/2012 01:45 AM, Alex Fiestas wrote:
> Hi there!
>
> First of all, excuse my ignorance on this topic, I'm pretty much sure
> that I'm going to say stupid things in this email so please, pardon
> me.
>
> A few days ago I was thinking on working in Rekonq adding support for
> Chrome extensions, the api doesn't look too difficult to implement but
> what worries me is how extensions will affect Rekonq. Chrome executes
> the extensions in a copy of the DOM  in a external process so they can
> control what extensions modify and of course chrome won't freeze if an
> extension die.
>
> This brought me to the topic of: How can we make Rekonq multiprocess?
>
> WARNING you may find stupid comments below this line
> - By porting to Chrome engine and stop using Qt (maybe it isn't possible at all)
> - Porting Rekonq to QtWebkit2 (can we modify the DOM with that version
> of QtWebkit?)
> - Doing our own Webkit
>
> The first sounds stupid to me, but hey I had to said it... The latter
> apart from a lot of work, I'm not sure that we want to create our own
> fork. So only QtWebkit2 seems a viable option, which brings me to the
> next question:
>
> Do we know if we will be able to use QtWebkit2 for creating a desktop
> Web Browser? If so, do you have plans for doing it?
>
> Thanks !
> _______________________________________________
> rekonq mailing list
> rekonq at kde.org
> https://mail.kde.org/mailman/listinfo/rekonq

Hi Alex,
and many thanks for your interest in this "hot topic" :)

Having a multiprocess browser really seems to be the next big task to 
fight with. Please, remember we have to work in two directions about 
because actually rekonq is a kuniqueapplication and just stopping it 
from being a singleton won't be enough: we want decouple UI process from 
the webkit one. This way everyone will be happy: users, devs, extensions 
devs...
To do it your first idea (move to Chrome engine) is really not an 
option, while the other two are to be evaluated.
Moving to (Qt)WebKit2 is for sure our first option. Remember that 
QtWebKit2 will provide just a QML API and that devs are working to 
provide a way to access the DOM in a similar way we can do with WebKit1. 
I don't know actually at what level is this task. I just know that a lot 
of people testing (Qt)WebKit2 code is complaining for this missing 
feature...

Doing our own WebKit (strongly based on the Qt port) will give us:
- having all C++ APIs available for... everything!
- integrate KIO in a "natural" way
- ... a lot of (difficult) work to do.
Just let me say that kde port of webkit2 is not mine or your idea, but 
it has been proposed months ago from rekonq people working on webkit 
(Pierre and Benjamin) as a possible solution to debate.

Last I wanna say that in my mind Qt5 is yet very far from here, so that 
I planned it from rekonq 0.12, being:
- rekonq 0.10 (early this summer): last "evolutionary" rekonq release 
from this codebase.
- rekonq 0.11 (when ready): completely reviewed rekonq browser, no more 
singleton, tabs up, able to easy integrate with kwin (the so called 
"Khrome" mode) and/or to use "without tabs" (for tablets use)
- rekonq 0.12 (after 0.11...) rekonq 0.11 improved and ported to Qt5/KDE5

If you'd like to start working NOW about extensions, I just can suggest 
to compile your own Qt5/QtWebKit2 copy and start playing with an easy 
qml browser. I know qtwebkit devs are playing with a test browser, based 
on qml and qtwebkit2, to speed up development, find bugs, clean up API 
and ... have fun!

Cheers,
Andrea.