WebKit weekly report #47 - Trapped in Locale Kit!

Hello world!

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 I started to work on the date and time input types for HTML5. There are several variants of those, to pick a date, time date-time, month or week. Our implementation will work similar to the color picker, with a popup window similar to the Time preferences panel. I started implementing this window, but ran into several issues in our APIs, which I’m now busy fixing.

First, if you look at the time preferences you will notice that the date and time are picked with a strange (and rather ugly) control. It’s a spinner with up/down arrows, which is common on other systems but was never available in BeOS nor Haiku. There are good reasons for this, the small arrows on a spinner to increase and decrease the values are too small to be easily clicked, which makes them useless and force people to reach for the keyboard and enter a value manually.

So I tried to design my time picker without using spinners. In most cases they can be replaced with either a BSlider (when the precise numeric value doesn’t matter much, for example sound volume control), a BMenuField (when the list of values is limited, for example the list of months), or even a plain BTextControl (when there are no restrictions on the value).

In the preflet I used a BMenuField for the list of month, and a BCalendarView for the day. I plan to add mouse wheel support to the month selection so you can easily go to the next or previous month with a spin of the mousewheel. The hours and minutes are also picked with BMenuFields, but a list with 60 entries is on the limit (or maybe already past the limit) of what’s reasonable for the standard popup menu. There will be mousewheel support there, and I will experiment with putting the 60 minutes in a matrix (10 columns and 6 rows) to make it more space efficient. There will also be an analog clock with draggable hands like in the Time preferences.

But the main problem is picking a year. It can’t be done as a BMenuField because there are no limits to the year you can pick, and we don’t want an infinite list of years popping up. My first idea was to use a BTextControl and restrict allowed keys to numbers. But further thinking shown it wasn’t enough: you could still enter things like -456-3245 or even just —. Both of these are made of allowed characters, still they are not valid numbers. This shows that a keystroke based solution isn’t workable. So I went with a different solution, which is to accept any input, but mark the control as “invalid” when the contents can’t be parsed as a number. The BTextControl API was extended with a MarkAsInvalid method, which makes the control draw with a red (B_FAILURE_COLOR) border. This also led to some interesting discussions on the development mailing list, and we will probably soon get a spinner control, which will have bigger buttons than what’s done on other platforms. It will probably be similar to the one used in the screen preferences to adjust the workspace count.

But all of the above was more easily done than said (yes, usually it’s the other way around). Despite all the thinking and discussion, the actual changes are very small, a dozen lines of code or so. And this is not what got me busy for the whole week. The next problem I faced was the need to format and parse dates and times. The values we exchange with WebKit are represented as strings. The input comes straight from the HTML page and the output must be in a well-defined format as Javascript on websites will make use of it directly. Our API for formatting dates was never really finished. I had started some of that back in 2009 during my “Locale Kit” GSoC project, but we had only a partial and suboptimal implementation. I needed some extra functionality here (mainly, formatting a BDate object as provided by BCalendarView). The lack of a way to easily format a BDate or a BDateTime into a string was something I already missed when I worked on cookies, so this time I decided to fix this for good. This led to a major rework of the Locale Kit APIs, and I also spent some time writing unit tests for it. While I was at it, I also applied the same changes to the duration, time unit, numbers, and monetary formats. All of these were extracted from the big universal BLocale class into smaller BDateFormat, BTimeFormat, BDurationFormat, etc classes. There were some other minor changes to the API (using references instead of pointer, marking arguments as const).

While I was working on the Locale Kit, I was reminded of two issues, one long-standing, and the other new, which are problems for our eastern european and russian users. the first is the lack of support for complex plural forms as used in russian and polish, for example. Where english has just two forms (singular and plural), some languages have four or five rules (for example “one”, “two”, “few”, “many”). Our translation system doesn’t handle this well yet. I started working on a BMessageFormat class which should help with that. However, I hit a problem in our ICU port that we didn’t notice before, which I had to fix.

The second problem is a planned change in time zones for Russia. This actually reverts a change done in 2011 which stopped daylight saving time in Russia. It turns out this was not a good idea and people don’t like the sun raising an hour later, leading to increased traffic accidents and some other problems. So they will reintroduce DST this month. You may be wondering how this is related to Haiku now. It’s related because we try to switch DST on and off automatically at the right time. To do this we rely on timezone data provided by the ICU library. To handle this change, we must update our data.

We are currently using ICU version 4.8.1.1. The latest release is version 53.1. We are 3 years behind, including a version numbering scheme change. So I started working on an ICU update. I wrote a recipe for ICU 53.1, porting our gcc2 compatibility fixes to it, adding the fix for the message format issue, and adding some extra fixes for new APIs in this version. I got Haiku to build using ICU 53, however, the resulting system doesn’t boot and deadlock before starting app_server. Since the ICU testsuite also deadlocks, I think I have a chance of debugging this and fixing the issue.

I almost forgot to mention two important news. Oliver did the required work to integrate our Mozilla Location Services API key into nightly images. So we can start making use of the BGeolocation API and get actual results out of it. And, one of the Mac Minis donated by Mozilla is being set up to be a WebKit build bot for Haiku. This means we can now think about upstreaming the Haiku port to the WebKit project. There is some work left to do to get the buildbot up and running, which I will take care of.