WebPositive needs to be ported to the new APIs. And a lot more testing. For example we have never tried opening two websites in different tabs, since MiniBrowser doesn’t support that.
I would say we can start considering it after releasing beta 6? The beta is already delayed enough to not start this now.
The next step is to have MiniBrowser using TabView, so don’t except yet to have WebPositive using webkit2 (in my next todo for the TabView)
I will be looking if it’s possible and easy to propose a kind of alpha package with MiniBrowser / Webkit2 so that people can play a little bit with it and see by themselves how stable/ unstable it is.
That sounds a sensible course of action. Will the browser be upgraded to WebKit 2 as a normal update during the course of Beta6 lifecycle or is it too integrated with the OS and so need to wait for another major release?
We only backport bugfixes, not big functionality.
I did make some improvements to webpositive recently, but nothing related to webkit2.
What would be the point of that? I don’t see the benefit of having a testing bet of MiniBrowser just so people can tell us it is broken 
I’d think our time would be better server improving the WebPositive architecture and slowly starting to tie stuff into it there. I have been thinking about starting a patch soonish to start and integrate webkit2 into WebPositive, but we will take quite some time to get there, stuff like cookiestore, proxy settings, history.. button state etc etc all need to be tied in, and potentially re-implemented for webkit2 if the implementation cannot be reused
It will have to wait for the next release, but we can probably make preview packages of WebPositive 2.0 until then.
That’s meant for after most of the obvious crashes are fixed. It would be nice to have more people test it on a lot of websites and compare with WebPositive to see what problems are specific to WebKit2, for example. When we don’t have such problems anymore, we can switch WebPositive to WebKit2 and be sure that we don’t break more things than before.
It may be easier to start from MiniBrowser and integrate UI code from WebPositive into it. But I didn’t try either, so that decision will be up to whoever decides to attempt this.
For now my goal with WebKit is still to upstream our port to reduce my work on doing merges and rebases. This means continuing to send them patches, and also probably setting up a buildbot to check that they don’t break our build by changes in other platforms (or at least that we’re warned when that happens).
8 posts were split to a new topic: Haikuwebkit minibrowser preview
I have started looking at Source/WebKitLegacy/haiku/WebCoreSupport/ because this part could be migrated on a “per file” basis into WebKit2. I first have a look at ColorPicker for the moment (working OK, I need to test more).
Once all these files are migrated, would be something remaining before being able to disable set(ENABLE_WEBKIT_LEGACY ON) in the build options ?
I’m talking about the minimum path to cut the link, ie all features might not be there in a first step.
I’ve build with that before, seemed to work fine. Removing code that is wk1 specific may be a different story though 
Thinking about this more, perhaps we should instead be merging the wk2 branch into wk1, trying not to break it in the process. we seem to be on a good pathway here for improvements, and already have had improvements that improve wk1 (i.e where people used your webkit2 build and just used the webkitlegacy from that).
Having one branch instead of two would mean there is only one branch pulkomandy has to rebase.
@PulkoMandy Does that make sense to you?
If so I would try and tackle it this or next weekend.
I already move the changes to the WebKit1 branch when they affect both.
No, I prefer to keep the WebKit2 branch separate, it eases my work for keeping track of what needs to be upstreamed. Otherwise I would have done this long ago myself already.