Congratulations and thank you so much for your amazing work! 
3 Likes
Now that’s what I call a GOOD screenie! +1 Congratulations on the work so far! 
be sure to save your work 
6 Likes
AWESOME WORK 
Congrats !
1 Like
Yeeeeeeeeaaaaaaaaaaaaah ! 
Great news !
I almost feel the breeze of strange, far sites … sailing there with the native Webpositive - fast and aesy - with like a teaclipper !..
Ahoy Webkit2 !
Welcome Minibrowser !
Excellent work - well done! TBH, I feel like these days a browser doesn’t need a whole lot more than you have there, maybe some history 
No need for tabs when the OS can do it
Well, pretty much all that works is displaying the web page
- You can’t interact with it
- Text doesn’t display properly
- Resizing doesn’t work
- etc.
So, there’s still a lot of work left
12 Likes
The changes have been merged!
Now, @PulkoMandy, I guess we’re in a good place to merge haiku-webkit2 into the main branch? I’m guessing it just needs a bit of cleanup? HaikuLauncher still works so it seems WebKitLegacy still works fine in the haiku-webkit2 branch.
9 Likes
A merge is not really needed. When WebKit2 is ready, the WebKit2 branch can simply become the default branch.
What would be more interesting is making a diff between the WebKit2 branch and upstream webkit (or the latest version if it we’re based on) and start converting that into patches suitable for upstreaming on WebKit side.
3 Likes
Ahoy @Zardshard !
Would you release the new, native MiniBrowser - if it applicable ?
Thanks in advance.
I dunno, you can’t do much with it so it isn’t very useful atm.
Okidoki -
ACK
What’s left to make Web+ use WK2 as its default engine?
As Zardshard already explained:
Don’t be fooled by a screenshot that was staged to look better than things really are
3 Likes
Ahoj @Zardshard !
Ok, so I went back to your introductory blog post understand better where we are on the roed (of course we just peekin’ from your shoulder, but we are there as you can see from our keep on hoping quesations ).
So, as you wrote there
…what is WebKit2, or even WebKit, for that matter? Well, WebPositive uses WebKit to render its web pages.
Yepp, as a web engine should work
Currently, we use the WebKitLegacy API to communicate with WebKit. It would be nice to switch to the newer version: WebKit2.
Ok, this way I understand better.
When you talk/write about Webkit2 … it is not just the engine version (The Webkit of Apple) , but rather the version or rather the method of interaction between browser and the whole webkit package - so the API - than the whole engine itself. The engine is the newest as we have, but we still use an older method we communicate with, as still contains that older method as a legacy way. I see now.
For us WebKitLegacy seemed an older engine only, from all of discussion … I mean who does not involved into browser development at all.
But now it is clear : the source code - even the newest one - the one and only WebKit engine, but with 2 available API, and it works as way as which API chosen to communicate with, and then such services would be available of it.
Okidoki, this way I also understand why you wrote to Adrien about WebKitLegacy still also works !..
However, our port of WebKit2 still needs work. At present, it has lost its ability to even render any webpage at all! So, getting WebKit2 to work will be the primary goal of my GSoC project.
You did so until now
f there’s time left, I might be able to integrate it into WebPositive.
No words needed
One of the first things I hope to get done is getting the current version of the WebKit2 port working as well as it did at the end of Rajagopalan’s GSoC 2019 project.
Follow the flow :
This would involve fixing inter-process communication
DONE
and making sure the software renderer works. With those fixed, webpages should display once again.
DONE
Once that’s done,
I can make the keyboard and mouse work,
improve the API exposed to Haiku applications,
and implement various other things, such as context menus and clipboard support.
So now these TODO - and those ones you enlisted above - items lays ahead.
Yepp. way more complex and complicated as I thought for first look.
I hope this post helps those members who was mislead by great news like me as well - to better understand where the WebKit2 API/engine implementation progress is actually.
(If I understood well 
)
1 Like
Yes, that’s a good summary. Here’s some details, if you’re interested 
WebKit is split into more or less three pieces:
- WebCore - Has almost all of the code to make web pages, render them on screen, process user interactions, etc. In theory, you could make a web browser use this directly, but that would likely be pretty difficult.
- WebKitLegacy - This is simply an easy-to-use API for WebCore. It runs everything in a single process so it’s relatively simple.
- WebKit2 (often simply called WebKit) - This is also meant to be an easy-to-use API for WebCore. It runs various parts of WebCore in different processes, which makes it more complex than WebKitLegacy.
WebKit2 using multiple processes has one large advantage: security (and also the fact that it’s more up-to-date will hopefully let us use more modern features that never got added to WebKitLegacy). But it also is where most of the work for this GSoC project comes from. The processes needed to communicate, so I had to implement IPC. To get stuff to draw to screen, I had to implement a bitmap that could be shared between processes.
Now with those done, hopefully all of the hard stuff is done!
You guessed correctly! I’m thinking of working on mouse support next. The blog post should be out soon. But first, I’ve got some code cleanup to push.
5 Likes