After a week of struggling with my friend the compiler, I finally managed to bring the port into a buildable state again. Porting the latest changes to libwebkit, the last of the four WebKit subcomponents (libwtf, libjavascriptcore, libwebcore, libwebkit), took me more time than I anticipated but to my great surprise, after I fixed the first runtime crash, HaikuLauncher and WebPositive would run and be almost usable. Yes, there are visual glitches, and it is quite easy to crash, but you can search google, use maps, facebook, haiku-os.
Hello fellow Haiku’ers, as promised I’m posting a quick update on my WebKit / WebPositive contract work. It’s been a little more than a week already, and a small report is due!
Welcome WebKit r115944 ! As you may know, WebKit is a really big project, in the last two years, 70000 revisions have passed and the file count has almost doubled. The approach I took was to start by checking out a recent WebKit revision and try building the components one by one, re-applying our changes. The idea was to add only the strict necessary for Haiku and at the same time try to include as many features as possible, ignoring assumptions and workarounds that aren’t needed anymore. As many things have changed in WebKit and as I needed to get familiar with this huge codebase anyway, I decided to dismantle our port and put it back together again, like one would have done with a complex piece of mechanics. Thus I did a Jamfile from scratch, based on other platforms buildsystems, and replayed our changes one by one, as the compiler asked. Each time trying to document my changes and research the reasons and implications of the changes.
During community bonding period, apart from reading specifications, I also analyzed other NFSv4 client implementations, looking for interesting ideas and solutions. One thing I noticed which may be worth using in my NFSv4 client implementation is caching of some parts of generated RPC request.
In addition to that I also got more familiar with what Haiku expects from file system modules. I have written a very simple dummy file system and check how things work.
As we all know, cpuidle can’t save any power if cpu is wakeup frequently during idle– cpu doesn’t have chance to go to deep sleep. So to get power savings, besides cpuidle support, we must remove those unnecessary wakeups.
During the bonding period, I added some code to dump system timer wakeup events and found the cpu wakeup during idle is too high, ~550 wakeup/s. Then with the help of KDL, I found one obvious wakeup source – the scheduler’s quantumTimer.
Over the community bonding period I’ve been researching the best approach to take for the AWT port, and over the past week or two I’ve been implementing a prototype.
AWT demands the implementation of a number of ‘peers’ for buttons, text boxes, etc. which have historically been implemented using the native widgets of the underlying platform. The time taken to implement and maintain these peers is quite large, especially considering that these AWT widgets have been superseded by Swing and are rarely used anymore.
An alternative implementation approach used by the Caciocavallo project involves providing native heavyweights for the windows and views and then calling on Swing to provide drawing and event handling for the various widgets. This eases the porting of AWT and reduces the amount of platform-specific code to maintain. This approach is also taken by the recent port of OpenJDK to Mac OS X.
Over the past week or two I’ve written a prototype implementation using the Caciocavallo Swing AWT peers. It’s very incomplete thus far, but I’ve got drawing working pretty reliably, as well as some event handling including mouse input. Screenshot below the fold.
Just saw on Haikuware that there is another GUI for setting a decorator. First, I’m happy that people are actually using this “hidden” functionality to write custom applications. However, after Alpha 3 I changed the decorator API which broke all other decorators.
The reason for that is that the stacking feature of Stack and Tile is now integrated into the decorator. In other words all decorators have to support Stack and Tile now!
Having started my PhD at the University of Auckland two years ago I think it’s time to provide a brief overview for the Haiku community about what I am doing here. Since a complete overview would result in a pretty big post I intend to split it into multiple smaller posts. Fingers crossed that I remain motivated enough to keep writing :).
The topic of my PhD is “User Interface Customization” and covers three aspects.
With one big push the work I did on ALM (Auckland Layout Model) while I was at the University of Auckland is now in the main Haiku repo. In short, I’ve brought the BALMLayout up to standard with the other layouts in Haiku, and added some new features as well.
I started to work on the xHCI driver in late 2011: I found the code provided during the Google Summer of Code 2011 was promising and didn’t get its full exposure. Another reason was Haiku Inc. provided me with hardware I needed to mentor the xHCI project by Jian Jiang.
The goal of this project is to create code for resizing a BFS volume in a safe manner, through the existing volume resizing interface. At first utilized with a command line tool, and toward the end of the summer hopefully integrated with DriveSetup if time allows.
During the community bonding period, I want to get my development environment set up, and gain some basic familiarity with writing to disk. To accomplish that, I’m going to write a small program that can read and write sectors to the hard drive.
