WebKit weekly report #40

Blog post by PulkoMandy on Fri, 2014-08-08 07:13

Hello world!

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

[GSoC 2014 : ARM Port] Week #15

Blog post by dnivra on Sun, 2014-08-03 10:53
Hello everyone!
TL;DR - It was decided that reserving space for the kernel instead of moving the entire memory map to a higher location. I’ve been working on that for most of last week and I think it would take a good part of this week to complete it since I seem to be running into many issues.

WebKit weekly report #39

Blog post by PulkoMandy on Fri, 2014-08-01 08:13

The quest to provide a better web browsing experience continues this week with some small fixes which result from hours of tracking down bugs.

[GSoC 2014 : ARM Port] Week #14

Blog post by dnivra on Sun, 2014-07-27 05:49
Hello everyone!
Here’s the update for week 14 of work on the Haiku ARM port. I was travelling for a good part of week 13 and thus couldn’t get much work done during the time.

TL;DR - The problems of kernel overwriting the loader code and the exceptions when setting up framebuffer have been temporarily solved. The framebuffer related code has been disabled for now and the entire memory map moved to a higher address(when FDT support is implemented, a lot of these problems probably won’t arise). Currently, a fault is raised when the kernel attempts to obtain the same lock twice, which drops to KDL.

WebKit weekly report #38

Blog post by PulkoMandy on Fri, 2014-07-25 07:37

Hello there,

As mentioned in the previous report, two weeks ago I attended the RMLL conference. As usual this was quite interesting, and an occasion to show Haiku to more people in the free software community. We got only about 10 persons attending our conference and 4 attending our workshop on making Haiku packages. However, the main event was the "Libre Village" where we got to meet people and try to get as much of them as possible to try Haiku. I played Critical Mass with some people there, and also helped porting PyTouhou to Haiku.

[GSoC 2014 : ARM Port] Week #12

Blog post by dnivra on Sat, 2014-07-12 09:41
Hey everyone!
Here’s a quick update for week #12.

TL;DR - The decompression process fails because the archive is present in a location that isn’t mapped by the MMU and subsequently allocated for the zlib output stream. No solutions have been discussed yet. It shouldn’t be long till the kernel is running hopefully :).

Libusb Port : Post Mid Term

Blog post by akshay1994 on Sat, 2014-07-12 08:35
Hello Everyone! I am working on porting Libusb to Haiku as part of Google Summer of Code, and here is a progress report on the work done till now.