Once again I am out of catchy taglines to introduce the monthly report. To apologize for that, I updated the statistics about Haiku git repository, and also added a similar statistics page for haikuports.
This report convers hrevs 51064 to 51139.
Network A lot of activity on this side with no particular reason, with kallisti5 and waddlesplash working on the network preferences and underlying stack, towards support for VPNs and PPP connections.
The spring is comming, the GSoC applications closed just today, and it is time for a new monthly report!
This report covers hrevs 50989 to 51063
Drivers tqh is working on improving wifi performance. He identified some sub-optimal code in the FreeBSD compatibility layer which he replaced by much simpler and faster functions that the compiler can actually inline. This improved performance of all IO access to network devices, fixing some real time problems.
Let’s see what happened in Haiku this month. This report covers hrevs 50928 to 50988.
waddlsplash worked on enabling real subpixel rendering in Haiku. This used to be protected by Microsoft patents, but they are all expired or will expire really soon. So, it is time to start experimenting with this and getting ready for enabling it.
waddlesplash also reworked the JSON API, and fixed several bugs found by the “JSON Minefield” tests.
Let’s see how 2017 goes in Haiku. This report covers hrev50830-hrev50928 (almost 100 or about 3 pushes per day).
Happy new year everyone!
Here is the last report for commits in the year 2016. It covers hrev50718-hrev50829.
The autumn season is here, and the winter is coming soon. For Haiku this means
several things. In particular, this month there was the Capitole du Libre with
two talks about Haiku (you can read more about that in mmu_man’s short report),
and also the start of the Google Code-In, with the first students claiming their
Anyway, let’s have a look at what’s cooking in the source tree. This report covers
Life continues in Haiku, with bugfixes and slowly getting prepared for the beta release. Not much in terms of new and exciting features, but Haiku is getting more stable and the bugs slowly fade away.
In terms of Haiku commits, this report covers hrevs 50577 to 50664.
Hey there, time for a report! (I’m really out of ideas for taglines. Any suggestions?)
This report covers hrev50529-hrev50576
Hello there, it’s time for the monthly activity report again!
This report covers hrev50456-hrev50528
The work on the intel_extreme driver continues. In the previous month there was a large refactor, merging an old branch originally started by mmlr. kallisti5 updated it and tested it on the early intel models (everything up to SandyBridge).
Here comes the activity report for July of 2016. It covers hrev50388-hrev50455
Finally the reports are back to normal monthly schedule!
The summer is coming, which in my case means a little more free time for Haiku hacking. Anyway, on to the interesting facts. This report covers hrev50367-hrev50387 (yes, only 20 revisions this month, but some of them are large-ish with several commits from Barrett).
Hi there! Once again with about a month of delay, here comes the activity report.
This report covers the range hrev50117-hrev50336.
Command line apps
AGMS contributed some fixes to the "mail" command line app which can be now be used easily to send automated messages from a script. This is an useful tool to have in automated tasks to post status report, errors, etc.
Rudolfc fixed some issues with non-32 bit video modes. If you are still using Haiku in 256 colors, it is now possible to have video overlays on that.
Hello there, it’s time for a new report!
There was no report in January as the month was somewhat quiet, with several of
the devs putting most of their effort in mentoring GCI students. But everyone
has recovered now and we are back to normal schedule.
Hello everyone, welcome to 2016!
After a break in November because of BeGeistert, the monthly reports resume on
almost normal schedule (yes, I start with this one being two weeks late!).
Anyway, let’s see what happened during the last two months in Haiku.
This report covers the range hrev49750-hrev50011. We just passed the 50000
revisions range, which mmu_man celebrated with a birthday cake icon in hrev50000.
2016 will also be the year of Haiku 15th birthday, but this will happen a bit later,
Detailed statistics will be available soon.
Hello there! Time for a new monthly report!
This report covers the revision range hrev49663-hrev49748. No detailed statistics were generated yet.
Hi there, here comes the report for the month of September!
This report covers revisions hrev49453-hrev49663.
The summer is there and it seems some Haiku developers had more time to work on it this month. There were so much news that my article from last month isn't even on the homepage anymore! Statistics This report covers the commit range hrev49433-hrev49500. Help gathering useful statistics about a given commit range with git (modified lines, number of people contributing, etc) is appreciated. Meanwhile you can check the gitstats page, which I won't keep up to date every month because it takes too long to generate and doesn't look so nice: http://pulkomandy.
Hi there, it’s time for the monthly report!
Commit range scanned this month: hrev49209-hrev49344.
There are currently 38 tickets open in the beta 1 release. For the first time, we are below 40.
GCI winners trip 2014 report
Hi there! I’m reporting from San Francisco today. This week I was visiting Google, meeting with the two winner students from Google Code-In as well as the students and mentors from the 11 other organizations participating in GCI.
In case you missed it: GCI is a program run by Google for 13-17 year old children. The goal of the program is to introduce them to open source software and get them contributing there, and to get them interested in computer science in general.
A new month, a new report!
The commit range this month is hrev48952-hrev49106. I got bored of doing the statistics by hand, so I’ve run the repo through gitstats instead. This gives more information than what I could do manually, including a listing of the most active commiters this month. Be sure to have a look at the results!
Hello there, here comes the activity report for the month of march 2015.
This month there were 104 commits (hrev48848-hrev48952), 5 more than in the previous month.
My contract has ended, but for now I have some free time to write a report every month about the ongoing development efforts from the Haiku team. I think this is a nice way to better see the work done, more so than looking at the roadmap progress bars which tend to not move much.
This month there were 91 commits (hrev48757-hrev48848). Let’s see what’s inside those.
As you probably have noticed, there were no weekly report in the previous weeks. The reason for this is that my contract is currently stopped. There is currently not enough money in Haiku’s treasure chest to safely continue it. So, it’s time to me to get back to “real life” and a full-time job in a software development company.
First of all I want to thank everyone who made this long contract possible by donating money to Haiku. It was a great experience for me, and a lot of fun as well. I did my best to move Haiku forward towards the R1 release. Unfortunately the beta 1 still isn’t there, and we currently have 57 blocking tickets. It is a small number, but only the most complex or big issues are left.
As you may have noticed if you watch the commit list closely, my libbind work has not been merged yet. There are still some bugs to solve there, but I got sidetracked. I use BReferenceable in my DNS cache implementation to keep track of the cache entries. BReferenceable is a class used in Haiku to implement reference counted objects. In C++, the language only has very simple memory management, in the form of the new and delete operators. Objects can be allocated on the stack (they are temporary and only last as long as the function they are declared in is executing), or on the heap (for long lived objects). Objects allocated on the stack are deleted automatically when the function exits, while objects allocated on the heap must be deleted manually. This is one of the annoying parts of C++: managing the lifetime of these objects, making sure they are deleted only once, and that no one will try to use them after deletion.
Not much commits from me this week, as I’m still working on the libbind update, and I’m also doing some work for other customers. I got netresolv to build after implementing the missing getifaddrs function in Haiku - this is a non-POSIX function, but it is available in Linux and all major BSDs. It enumerates all network addresses for all network interfaces on the system, similar to our BNetworkRoster and BNetworkInterface classes.
I have not given any news from the Google Code-In for some time. It ends this week, and students have completed more than 400 tasks for Haiku. While this includes a lot of simple tasks (the simplest “getting started” ones involved just booting Haiku and running StyledEdit), it means the students at least got to see what Haiku is. We have a more complete set of recipes in haikuporter waiting to be packaged.
Hello there, welcome to the first contract report for 2015!
This report summarizes changes done since 19 of december as I was a bit away from keyboard for the winter break. But I’m back for another year of Haiku coding!
Hi! Work continues on putting Haiku in shape for the R1 release. This week I worked mostly on UI fixes to make our apps look a bit better. hrev48490: fix last week's changes to avoid truncating the translator settings hrev48492: fix BOptionPopUp not inheriting the parent background color hrev48501, hrev48502 (based once again on a patch from Laurent Chea): use BNotification for the media server restart notification hrev48503: fix a layouting problem in BBox where the box title width would not be taken into account to compute the box minimal size (with some help from stippi in understanding how this is supposed to work).
With the fixes done this week, we now have less than 2500 open tickets left before R1. I had crossed this bar last week already, but not for long as new tickets sometimes come faster than we can close old ones. I think now we are under that bar in a more durable way.
So, this week marks the start of the Google Code-In contest. I’ve spent some of my time preparing some tasks for it as well as reviewing the work from students. Our IRC channel is incredibly busy, and there have been 110 tasks completed by 65 students already. You can currently watch the leaderboard here for unofficial stats: http://ematirov.tk/org/haiku/
Work continue this week with a lot of long overdue UI enhancements. Not very technical work there, but finally closing all those tickets allows us to more easily find the important ones in the bugtracker. These changes also make Haiku more polished and easier to use, which is one of the project goals, after all.
After a great week-end at the Capitole du Libre showing Haiku to other people in the free software community (read François’ report for more details - video of my talk should be available “soon”), I’m back to work on the code.
This week I continued work on moving Beta1 forward, fixing some important and less important bugs. To make things clear about what to expect in the upcoming weeks, I will spend more time on Beta1 tasks, but I’ll also continue working on WebKit. However, my work there will focus on fixing bugs, rather than adding new features.
Hello there! I'm now back home after BeGeistert. As you may have noticed if you read the development mailing list, there is a general agreement from the development team for a beta 1 release "real soon now", and after that, it will be time for R1. I will be coordinator for these, which means I will spend a bit less time on WebKit to take care of some other tasks. But I'm not giving up on WebKit, which still needs a lot of changes to reach release-quality.
Hello world! As you probably know, I'm reporting from Düsseldorf this week, where the BeGeistert coding sprint is about to end. I won't cover the events of the weekend as Humdinger has already written a complete report for it, including videos of all the talks. So let's instead dive into the coding sprint event, and see what we hacked on during the week olta&js: bootstrap fixes Oliver and Jonathan worked together in getting the Haiku bootstrap process working again.
This week is a bit special, as it closes the first year of my contract with Haiku. I wish to thank everyone for their support through donations, bug reports, comments on these articles, and general support for my work. I hope this will continue into next year.
This was again a rather busy week, but there was not much work on WebKit itself. I’ll keep the breakdown I used last week (haiku/haikuports/webkit) as it seems to work well.
This has been a busy week with activity on all fronts.
Localekit and ICU migration Last week I wrote the report while I was debugging a deadlock in ICU 53.1. I spent some time debugging this and I found the issue. ICU calls native functions to handle some aspects of timezones (tzset, localtime, and a few others). However on Haiku we implement these functions using ICU. This didn’t work too well as ICU tried to lock a lock it was already holding during the initialization of timezone data.
So, one of the changes made last week (the XMLHTTPRequest timeout support) led to an API breakage in the network kit. This made WebKit crash on starting WebPositive, and I had to make an “emergency” release during the weekend to fix this. While you can enjoy the new shiny features and the bugfixes, you will also notice it is rather slow and uses a lot of CPU. This is a known issue related to the fixes with redrawing frames, which needed to remove some optimizations. I’ll try to reintroduce those in a way that doesn’t involve drawing problems.
This week most of my work went into improving our HTML5 support in WebKit. A lot of small issues and relatively simple features had piled up on my TODO list, and there weren’t too much new bug reports so I spent some time to fix those. Here is a quick review of the features I added support for this week.
As usual, after the 1.4.4 release there were some new bug reports for me to work on. So the first part of the week was spent investigating and fixing some of those.
- Several problems were fixed in the video code, which are leading to deadlocks and/or crashes of WebKit after a video is done playing.
- A problem with text not being drawn (seen for example on Trac) was fixed. This is apparently a new bug introduced on WebKit side, where small text with shadows ends up not being drawn at all. I’m not sure my fix is completely correct, but it seems to work.
Yesterday I released version 1.4.4 of HaikuWebKit. This version includes the latest fixes to the rendering code and should be completely useable again. There are still a few drawing issues but they shouldn’t prevent you to browse the web anymore.
This week most of my time was spent on debugging. My new machine is running fine, and now building WebKit takes a little more than an hour, which is much better than the 4 hours I was getting on the old laptop. With a 4 thread CPU machine some concurrency and locking issues became much easier to reproduce. This led to identifying and fixing a bug in our BSecureSocket class, which was not properly setting up SSL for thread-safe operation. I think this will fix most of the remaining memory corruption problems.
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.
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.
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
The quest to provide a better web browsing experience continues this week with some small fixes which result from hours of tracking down bugs.
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.
Few things to mention this week.
The 1.4.1 version of HaikuWebkit with the new drawing code is available in the nightlies. While it seems to work better in many cases, there will likely be a few regressions, please give it a test run and report any rendering problem you get.
With this released, I started the work on getting WebKit2 to build. Following the advise from one of the webkit-gtk developers in last week update comments, I’m starting with a port that will use UNIX Domain Sockets.
Things are rather quiet on the WebKit side this week. I’m reviewing and fixing the remaining bugs with the new drawing code, which is now working rather well. On the WebKit side, I have implemented a limited form of transform support for regions (only handling translation and scaling, not shear and rotations), which has very good results. As a consequence, we now have mostly correct drawing and quite good performance. Before I do a release (I know the version in current nightlies is quite outdated now), I want to fix one more bug, which is the lack of video display on youtube. This is probably a simple fix once I understand why the current code isn’t working anymore.
Hello world, another update!
Work on WebKit continued this week. In the previous report, I mentioned several issues with the new tiled rendering. Most of them turned out to be either problems in app_server or misuse of the APIs in the WebKit code. The most important part was that WebKit used region clipping and expected the region to be transformed when using SetTransform; however, with the current design, region clipping isn’t affected by the view transform.
Work on the new drawing code for WebKit continues this week. We have scrolling support again (this was a bug in app_server, which stippi helped to fix), the scrollbars are drawn in the view thread (we are still using the fake scrollbars from WebKit), and the screen is updating as it should, so we get animations to work much better (for example the 2048 game plays with animations now).
I spent most of the week working on the texture mapper drawing code. I spent a lot of time tweaking the options (each change requires a complete build of Web+, so this added up to a lot of time…), and today I got the texture mapper to display something in a BWindow.
Well, just got confirmation from Haiku, Inc. that I can continue working on this during May. Thanks to everyone who donated money to Haiku, Inc. for making this possible!
As mentioned last week, I’m working on fixing the flickering and missing rendering on some pages. I didn’t get very good results yet, but I can at least give you an overview of the different ways WebKit can render things on screen.
Not so much exciting things this week…
Well, good news first, on wednesday I uploaded HaikuWebkit 1.3.1 packages. It should be more stable than the previous releases, and includes work from the last 3 weeks including some more bugfixes for audio/video support, working web socket support, and many smaller fixes.
Work continues on the testsuite: I found one bug in the testsuite system that greatly improved the results. Things are now properly reset between each test, which avoids many of the issues I was having. The last test run breaks down as follows:
- 2 unexpected crashes
- 2300 unexected failures
- 400 unexpected successes
- 5000 tests have no reference
- And the remaining 30000 or so tests are now properly tagged
I will continue marking the failing tests as expected to fail, and review them in case I find one that’s easy to fix. The 5000 “no references” tests are easily fixed, we just need to generate a reference rendering of the page. This is because these tests have platform-specific results, so there is no common reference for all platforms, and we need a haiku-specific one.
Slow progress on the code this week…
I fixed two small issues in the video decoding code: a useless notification was sent, leading to very high cpu usage on jamendo.com (and possibly other places). And, the video drawing was not always using B_OP_COPY. This led to CPU waste as the mode used could be slower (B_OP_OVER has to scan each pixel to see if it is transparent), and created some drawing glitches on some videos.
Progress on WebKit this week happens in various areas.
On the testsuite first: I fixed several small issues that triggered asserts when WebKit was built with asserts enabled. This includes a problem with the sequencing of events when loading an invalid URL, and a double deletion of an object when iframes are involved. These two problems could have created some real-world issues, so WebKit should be a little bit more stable now. Another problem was the lack of “key up” events and mixup of keycodes vs characters in the testsuite keyboard simulator, which prevented us to test the editing code in an useful way. Another problem was some browser settings were modified by some tests (such as the text size, and page zoom factor), and not reset before running the following tests. This led to some unexpected errors which are now avoided. With these issues fixed, I can have a look at the remaining failing tests, knowing that they are more likely to uncover actual bugs.
The good news first: I’ll be working on WebKit for another month. Thanks to everyone who donated some money to make this possible. As said in the previous weeks, I’m now working part-time on another project to make this last longer.
And then, the very good news: HTML video is working!
Support for html5 audio makes slow progress, but progress nonetheless.
Last week I was struggling with the build system. These issues are solved now, and I have a WebKit build which recognizes the <audio> and <video> html5 tags. This is not quite enough to get the sound and video output going, however. I have started plugging some parts of it to the media kit. We now download the audio files, and try to decode them with Media Kit.
The report is going to be sort this week, for several reasons:
- I was not at home for the week-end, and didn’t get any Haiku work done,
- As announced last week, I’m currently working only part-time for Haiku,
- And, not much happened anyway. There are weeks like that.
The report is a bit early this week, because I will not be available tomorrow (in case you wonder, I will be at the Forever Party). So, here it is.
First of all, thanks to everyone who donated some money to make yet another month of contract work possible. This weekend I uploaded a release as announced in last week post. As expected, after this long overdue update, testers quickly found many small problems, so this week my work was mainly hunting these small bugs. Fortunately, none of them was too hard to fix. The fixes include:
Well, the good news first: for some time I had a bug with GMail, where the top part of the interface (with the search bar, trash button, identity and GMail logo would disappear after the page loaded. This is why I didn’t do any release in a while. Well, this bug is now mostly fixed. There is some flickering of the same area, but at least it doesn’t completely disappear. I’ll be researching the flickering, however it isn’t an usability problem anymore, so I can package a release with all the improvements done over the last weeks.
So, as advertised last week, I spent some time running the testsuite again. And as usual, it helped spot and even fix a few bugs.
This week I worked on stabilization and small improvements of WebKit. There are a few new features, as well.
The crash with cursors I mentionned last week is fixed. I had forgotten to copy an object in the copy constructor, leading to a double delete. I continued working on the clipping code, and fixed the issues with www.haiku-os.org and a few other websites. But, I can’t get it to work with haikuports, Trac, and now gmail is also broken.
Hi there! As you can read on the frontpage, I’ll continue working for Haiku in february.This will be the 5th month of this contract. Thanks to everyone who donated to Haiku, Inc for making this possible!
So, I’ve sorted out my filesystem issues over the week-end (no important data was lost), and I’m back to full-speed work. As I was saying last week, we had a problem with gcc4.7 not compiling the most recent WebKit code.
The work started last week on ClipToPicture made some progress this week. We discussed this further with Stippi and now have a solution that doesn’t involve rewriting half of app_server code, and is also a bit simpler and faster than what I tried to do first. I wrote a test application and some boilerplate code, then Stippi jumped in and implemented the missing bits. There are still some missing features like the ability to stack multiple clippings using PushState/PopState, and some problems when scaling and translating the view, as expected.
As I said last week, the remaining drawing glitches are because of BView limitations. Well, it’s time to solve those as well!
I’ll start with what is now known as the “border bleeding” bug. You have encountered it if you tried opening the Haiku website, or the bugtracker, in Web+. You will easily notice that some items are completely filled with the border color, instead of the expected background one. To understand what’s going on, let’s have a look at the way WebKit draws things.
No big new changes this week, but a lot of small fixes and improvements.
I reviewed the growing issues list for Web+ on the bug tracker, and fixed several of them. Most of these were small and rather easy to fix bugs (I kept all the harder ones for later). Here is a list with comments, not that the issues were hard to track, but this is also a way to learn a bit more about the WebKit codebase.
Well, somehow quiet and regular activty this week. Not too much exciting things, but progress is being made.
I updated WebKit to early december version. This is not the latest one, but the guys at WebKit started using even more C++11 as Visual Studio on Windows finally gets more support for it. So, enter std::chrono and some std::thread stuff. Unfortunately, our version of gcc4 seems to be missing some of these.
You probably already read the news on the homepage: I’m continuing to work on WebKit for January. Maybe you noticed there was no report last week, as I was visiting family and didn’t get much work done. I’m not counting that week as paid work for Haiku.
Most of the work I did during the last two week revolves around the testsuite stuff. The testsuite engine got support for tests that need some time before the reports are parsed.
I was a bit bored of messing with the testsuite so this week I looked into “real” issues. The merge of a new WebKit version to trunk last week led to a few more bugreports, and I also looked at some very old ones to see if I could do something. Turned out the answer is yes, and for some of them, the fixes were also rather simple. So let’s see what we have:
Some progress again this week.
First of all, I finally updated the haikuwebkit package, for both gcc2hybrid and gcc4. This means you can download things with WebPositive again, and all the bugfixes since the last release are in as well.
On the testsuite side, I got the crash-report feature to more or less work thanks to help from Rene and Ingo. There was one improvement to Debugger to allow extracting the stack trace when using the –save-report option on a thread that’s not (yet) crashed.
Hello world! You may have heard I’m in for another month!
So, this week I made some more progress with the testsuite system. The major improvements are finished support for the image comparison system I was talking about in last week report. The DumpRenderTree tool now dumps a PNG image of the webpage (this was quite easy to do thanks to the offscreen BView to BBitmap rendering and the translation kit) when requested (not all tests use the feature).
I’m adding some of the missing features to DumpRenderTree: alerts are now dumped to the standard output like other ports do, so they can be compared as part of the testing process.
So, this wasn’t a fun week. Last week I had finished merging all commits from WebKit main repo. I got Web+ to run fairly well with these changes and I wanted to merge this into Haiku. However, while this works for the gcc2-hybrid version, I was not able to build a package for gcc4 and gcc4h. As a result, there were no nightlies published (the script wants all the architectures to work for a given revision before it gets published).
This week I reached a major milestone in my work, as I’m done merging all WebKit commits all the way to november 2013. HaikuLauncher is still running fine, and I will make the small required changes in WebPositive so it works fine again. Expect an updated WebPositive in trunk very soon now.
This week merges were as boring as the previous week ones: addition of the NiX port, removal of the Qt one (next version of Qt will go with Blink), replacement of a lot of never-null pointers to use references instead, rename of the KURL class to URL, and some API changes.
Sorry for no report last week, I was not in front of the computer on Friday.
Anyway, I got the HTTP authentication working last week. This was the last missing feature in the Services Kit version of WebKit when compared to the current cURL one. The next step is to fix the new rendering bugs.
The rendering side of things is mostly built into WebKit, so I didn’t want to fix it on the old version we are still running.
Hello there !
Well, not so much progress on WebKit this week. I spent most of the time working on CMake code to get it to generate hpkg files. I got something that works well enough to link Web+ to it, so I can test things with the actual browser instead of HaikuLauncher. Today I added the cookie jar persistence, so Web+ remembers all the cookies when you exit and relaunch it.
Time for a report again !
So, over last week-end and monday morning I finally got Ninja working. I already said some words about it, Ninja is meant to replace Make for building projects. It has less features, because it is designed to run files that are generated, rather than hand-written. In my case, CMake generate the Ninja failes. I had problems building Ninja that turned out to be abug in our Python port.
Hello again, it’s time for another report !
I made pretty good progress this week.
The issues I had last week with POST data are fixed. I had removed a non-working piece of code but replaced it with another that was broken in a different way. The problem was the way POST data was added to the http request. Fixing this properly required some changes to the Services Kit API. I removed some classes to make things simpler and introduced a stub for the central BUrlProtocolHandler class, which takes an Url as a parameter and builds a request for it using the appropriate protocol.
It’s Friday again !
So, in my last blog post I told you I was converting our WebKit build files to CMake. This week I managed to get a working HaikuLauncher (the test browser that comes in the WebKit tree) and surf the web a bit with it.
Hey, it’s Friday already !
So, now that I’m (mostly) done moving and I have set up my workplace (including internet access, electricity, and everything required), I can finally start doing some actual work on WebKit. So, what’s hapenned this week ? Well, actually, not that much.
A quick reminder, you can follow the commits on the bnetapi branch of haiku-webkit repo at github.
I’ve also set up a Gist TODO list so you can see things I want to work on. Please send me comments about websites that don’t work well, I’ll add them to the list and see what can be done.
It’s been two weeks since the previous blog post, so here goes an update.
First of all, I wanted to make it clear that I haven’t started to work on my contract, so the few things that happened in the last two weeks were done on my free time. Said free time was short, as I’m in the process of moving to another city and I’ve been packing a lot of stuff and cleaning my flat. Note I will be offline starting next week, and I hope to get internet access back as soon as possible. I won’t start working on the contract before I’m back online, as testing a web browser without any internet access creates more problems than I’m willing to solve.
As you may know, I’m going to spend some time again as a full-time Haiku developer. This time, I’ll be working on improving WebPositive and the WebKit port to bring a better web browsing experience to Haiku users.
During the past weeks I’ve managed to spare some free time to get up to speed on the various pieces of code involved and how to work with them. This first blog post summarizes the current state of affairs and I’ll set some goals (with your help) for the next monthes.
Hi there ! This week was the BeGeistert coding sprint. I assume you already read the great report at IsComputerOn about the conferences for this week-end, so here’s just a summary of the work done durint the coding sprint.
ARM Port - Ithamar Adema, René Gollent, Adrien Destugues Ithamar was holding the keyboard on this one. He's working on low-level Android stuff as his paid job, so he has a good understanding of the hardware and the Linux kernel that serves as a reference.
I'm heading home from the BeGeistert event that just ended today.
For those who don't know, BeGeistert is the european meeting of all Haiku (and BeOS) developpers and enthusiasts. This year, Haiku has seen its third alpha release, and we feel that R1 shouldn't be too far.
So, what happened there ? Over the weekend we had multiple conferences. The first one on saturday morning was a discussion on Haiku's release process and roadmap for the future.
Once again, the idea that tracker should use single-window mode was raised as a trac ticket. This discussion was made multiple times on the mailing list, and each time the answer from the developper was no. However, users still seem to prefer the single window mode, and other OS are switching to it. Maybe we just need to explain how to efficiently use this mode, and why we think it’s better.
So, I’m still working on the locale kit. Here are some things I did since last time :
Hello readers !
Last week we were at the RMLL (Libre Software Meeting) in France, with François (mmu_man) and Olivier (oco). Haiku has beed holding a booth and giving some talks in this conference for some years now, and it’s nice to go and meet people again.
Hello readers !
As you know, I’m currently working on the locale kit to bring it to a more polished state. The work is going well, and it’s about time for a status update. I’ve been quite busy at school for the whole year and committed few time to Haiku, so I’m catching up with a lot of things.
As you know, I worked last year as a GSoC student on the Locale Kit. Unfortunately, I had to get back to school in september and had not much free time to spend on Haiku. I attended the coding sprint at BeGeistert, but my laptop fan died while I was there and forced me to run my cpu at 800MHz, which was quite painful for coding.
This blog post talks about the changes that have been hapenning in recent versions of others Operating Systems, and wether Haiku should copy them or not.
GSoC is now over. It was quite fun to work with Haiku this summer, I learnt a lot of things, I gained commit access, and soon I’ll have a new TShirt to wear :)
After the alpha release, the locale kit was merged back into the trunk. Of course, as soon as this was done I got flooded with bug reports, ranging from build breakage on freebsd to lack of grist in the jamfiles making the catalogs mix up between apps. As far as I know, both of these are now fixed, but there is still a problem when building from Dano and the bluetooth preflet doesn’t want to be localized.
The end of GSoC is in less than two weeks now, so it's time to clean things up and get what I started working. I spent the previous week reading ICU documentation to understand how it worked, and this week I used this information to build the locale preflet.
This is not as simple as it looks. First, I had no experience of programming with the Interface kit so I had to learn how things worked.
Locale Kit Interfacing with ICU
This week two important things happened for my GSoC project: I got commit access to Haiku and I finished working on the catalog part. This mean I can now work more efficiently without having to send my patches trough the GSoC mailing list (you may have noticed I still need my code to be reviewed, however :/).
The catalogs allow strings in an application to be translated. At a first glance you may think this is the only needed thing in a Locale Kit and my work is finished, but it is not the case. The first missing part is the preflet allowing you to select your favorite language. The locale kit will now always try French, if not found default to German, then finally to English. I think this is not the setup most of you want to use.
This week I was at the RMLL in Nantes, and I was busy showing Haiku to other people and explaining them why it was so much better than linux. I had little time for GSoC coding. Still, I made some cleanup and fixed some small bugs. The catalog part of the locale kit is now working fine and can be used to internationalize applications. Here is a small guide for those who want to get an application speaking in their own language.
This week i’ve been working on a big red post-it that was on last week’s picture. It was about wo things : make the catalog handling tools work as build tools, and test them in some special cases.
The first part took me almost the whole week. I started doing a full port of the locale kit, but noticed it would probably be too complex to do that. Instead, I started over with a simpler solution.
almost-UML diagram of the locale kit
This week, I finally got the plaintext catalog add on working. Then today, Oliver reviewed my work and we had a meeting on IRC. We agreed on some changes to the internal architecture of the locale kit, and also to the classes I added. Some classes in this kit have unappropriate names, and the kit was designed with zeta compatibility in mind, whereas in today’s Be-World it seems more important to focus on gettext.
Mid-term evaluations for GSoC are already coming…
I’m still working on the catalogs for translating applications. I got the system working and integrated it into Haiku, so now any application can be translated. However, there is still a lot of work to do. I’m now working on a plaintext catalog add on.
Catalogs are the files that store translated strings. There is a catalog add-on called “default” that is used in applications.
Today I have started to write a catalog add-on to save catalogs in plain text for easy translation. I’ve spent some time looking at the involved C++ classes, and here is what I found.
A catalog is a collection of strings, stored as pairs. It is used in the locale kit to translate the text in an application to the system language at runtime. When an application starts, it asks the locale roster to find its catalog and return it back.
These two weeks I’ve been quite busy with other things, so the project didn’t move as much as I wanted. However, I managed to get the catalog engine to internationalize an app for the first time. It’s not a big application, just a very simple Hello World test program. And the lack of a tool for translating catalogs means I had to edit them by hand to get the translation done.
The work on the Locale Kit as part of the Summer of Code has already started :) This week we have been working on proper integration of my work in the Haiku tree. So you can now checkout Haiku from svn and get the Locale Kit as part of it. Of course, some parts are still broken (or not yet written), but some of the tests seems to be already working.
Hello world ! As you know, I am one of the selected students for this year summer of code. In this post I will introduce myself and give some details about my project.
My name is Adrien Destugues, some of you may know me as PulkoMandy as i’ve been lurking on the irc channel and mailing lists for some time. I already applied for the Summer of Code and Haiku Code Drive last year but unfortunately I was not selected.