This week most of my time was spent on preparing the 1.4.3 release of HaikuWebkit. This fixes more bugs and removes the "tiled" rendering mode introduced in 1.4.0, which turned out to not work so well. Some old drawing issues will make a comeback, however, and I will need to dig into the app_server clipping code again to understnad what's happening there and actually fix them.
The coding period of Google Summer of Code 2014(as well as the program itself) ended on Monday August 18, 2014. Here’s an update on the status at the end of the program. I’ve been moving over the past week and thus the delay in the update.
Over the past few weeks, I’ve been working on improving support for ARM. I added a jam target to automatically create a bootable MMC image and fix bugs in the haiku loader and also in the kernel. My original objective was to boot the kernel completely but I didn’t succeed in the attempt - it fails after sometime of booting into the kernel(an ASSERT fails in paging related routines). Few patches I’d submitted are yet to be merged(eg: #11131) to reach this failure. Currently, it seems that some of the latest changes prevent building again. #11144 tracks this issue. I’ve not investigated the issue yet so I am unsure what is going wrong.
I learnt many things by working on this project as well as had quite a few instances where I wasn’t sure if I was doing the right thing. Fortunately, several people were around to help out during those times - PulkoMandy, jessicah, kallisti5, revol, ithamar, Ingo and zhuowei. I can’t thank them enough since without them, I would be completely lost. Sadly, I probably won’t be able to continue work on this since I start work on my master thesis soon and working on the ARM port along with the thesis and coursework would be difficult. I’ll be able to judge better only in a few months time at least. Thanks to everyone who followed the weekly updates on the blog-o-sphere and supported the project! Till next time!
During the last two weeks, I spent most of my time working on the WebKit2 port. As I already mentioned, WebKit2 is where current WebKit development happens, and the most important change is the split of the WebKit system into two processes, one for showing the window, and one for doing the actual work of rendering the pages. But the more interesting thing is the more up to date and full-featured API that lets WebKit handle, for example, HTTPS certificates, so we don't have to do it ourselves - just show the dialog to the user when told to.
Today is the firm 'pencils down' date for Google Summer of Code. I write this blog, summing over all the activities/tasks accomplished in the last three months and my journey with Haiku.
This year Haiku was all around at the Libre Software Meeting (RMLL). We had a booth for five days, a talk, and a workshop! Adrien, Olivier and I had many occasions to discuss Haiku with interested people. As for each edition, too much to see at once, lots of booths, talks and trolls. And a whole new theme for DIY as well this time.
So even though finding a room to sleep in was a bit tricky, the week was as always really filled and interesting!
Here's a quick update for week 16. I didn't have internet access over the past few days due to a technical issue with my ISP and hence the delayed report.
TL;DR – The patch to prevent the kernel from overwriting the loader was merged last week. The next issues that need to be tackled are the KDL faulting when printing the backtrace and fixing an assertion that fails when initializing virtual memory.
This week most of my time was spent working on getting WebKit2 compiling on Haiku. WebKit2 is the new multi-process model for WebKit. It replaces the old WebKit1 that our port uses currently. WebKit2 spawns a new process for each tab, and possibly more (for network access, etc.). The key features are:
- When a webpage crashes WebKit, only the tab showing this page is lost, not the whole browser
- The use of more processes makes the application feel more reactive. As you know, the threading model in WebKit is not a perfect fit with Haiku's one, but splitting things in a separate process allows us to have a standard Haiku application as the visible browser shell
- All the tricks of getting WebKit running (specific tweaks to BApplication and BWindows) are moved to the rendering process. This makes the BWebView API much simpler, as it will become just a plain subclass of BView, with no expectations on the BApplication or BWindow
- The WebKit2 API is where all current WebKit development happens. WebKit1 lacks support for some features