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.
Sourcecode changes
You have to alter your source code to get it working. We've tried to make this need as little changes as possible. First, you have to #include two files : Catalog.h and Locale.h. They are system headers from the locale kit. Now you have to tell the locale kit to initialize a catalog for you. A catalog is a class that you will use to map strings to their translated equivalents. The locale kit will automatically find the right data files for you, depending on the system-wide language preferences, you application mime signature, and some other magic (see the part of this post about the build system changes). So, you only have to add two lines of code:
BCatalog cat;
be_locale->GetAppCatalog(&cat);
The next step towards the finishline (described by the WiFi-bounty on haikuware, Technical Information tab), will be the design of a native Haiku WiFi-stack.The picture below shows a coarse view of how the stack will fit into the networking system.
.thumbnail.png "WiFi stack - coarse design overview")
WiFi stack - coarse design overview
As you can see there are two distinguished areas, one is colored green the other blue. Green shows already existing infrastructure, blue shows the infrastructure I'm going to provide. The arrows should be read as “depends on, uses features of”.
So the blue ellipse encapsulates the blueprint of the WiFi-stack. The inner structure of the yellow box, saying “WiFi-Stack” will be my next task. The main reasons for designing a Haiku-specific WiFi-stack (in contrast to modify/port the FreeBSD one) are to utilize Haiku's strengths (multithreading, object orientation, ...) and to get smaller driver code (due to lack of all the FreeBSD compatibility code).
After accomplishing the yellow one, I'll pay my attention to the yellow-red gradiented box saying “FreeBSD-Adapter”. This adapter will allow to use FreeBSD's WiFi driver and use them in Haiku with just recompiling them. As you can see this is the same idea as realized for LAN driver's by Hugo Santos.
Screenshot of working WiFi prototype
Today I fiddled out the last hurdle on getting my WiFi-card up and running. It only connects to unprotected open wireless LANs, because there is no configuring mechanism implemented yet. Though it is far away from completeness.
On the screenshot, you see Firefox surfing www.haiku-os.org and downloading a 100 MiB file from my ftp server in parallel. The terminal is showing the result of the ifconfig command for my WiFi-card.
I managed to port the FreeBSD WiFi-stack, utilizing Haiku's FreeBSD compatibility layer. Thus I could use the WiFi-card driver for my atheros chipset from FreeBSD without any major changes to its codebase (I had to move some interrupt handler code into driver-specific glue code).
The driver-binary has a size of 500 KiB, due to compiling the WiFi-stack into a static library and statically linking it and the FreeBSD compat layer with the driver. Update: The sources are up in the haiku-wifi repository on www.osdrawer.net (read "For the bravery" down the line for more info on how to get it).
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. I only compiled the tools I needed, statically including the catalog add-ons inside them. It is now possible to extract the keys (original string) from a BeOS program, translate them to a new language, and integrate them in the Haiku Image. I did not have much problems with C++, but Jam caused me some difficulties, as I had never worked with it before except copypasting things around to integrate my code to the haiku image. This time I had to build up a new part of th toolchain, creating two rules and two actions. Ingo helped me a lot on that and now I have a better understanding of the whole Jam system. The rules I wrote are still not perfect, there are already some plans to make them simpler to use.
The journey so far.
I have implemented basic file system interface functionality including mount and unmount, and can load it directly as a kernel addon and via userlandfs. At present the client expects just the server ip address and the share name in the format :. I have begun implementing protocol negotiation, and hope to complete the setup of a session using LANMAN in the next few days. I had hoped to have begun implementing file actions by now but unfortunately I’m quite a way from that.
After more than a week of thinking, "Today is the day I'll write that blog post", here I am with a status update on my HCD2009 project. I have only a few more points to add to what Matt has already posted here.
First of all, the previously unnamed full text indexing and search tool now has a name: Beacon. The indexing daemon currently in the works is called beacond. This is what beacond can do right now:
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. I summarized our meeting in this somewhat-UML diagram. It’s not really an UML object diagram as I added informations about the workflow and the tools to use when working on a localized application, and a lot of notes and remarks. I think it shows well the status of the kit: a clearly designed API, but some missing code and a lot of TODO notes. I did not fully reported the parameters of the methods and the attributes of all the classes, look at the headers if you need some information on that. This diagram is not meant as a technical reference, but as a colourful and efficient way of cleaning up my personal notes. I think I’m better at organizing my tought in a spacial way than laying them down linearly in a text. Click on the image to enjoy it at full size :)
Well another week has passed. I cannot say that to many eventful things have happened with my project. I have been working on getting all of the logic in DriveSetup to work the way I think that it should. I finally connected my development computer up to the network today though and thought I would post a screen shot. The two partitions were created with DriveSetup! Not a whole lot to look at but I pictures are always fun :)
After a month of work, it’s time to take a break and a step back to check on our progress.
And after a month what we have is a prototype of a multi-process browser.
Haiku Native Browser
Ryan and I had a dilemma:
Where to start? In fact, there is a lot to do on this project.
So we decided to start with a multi-process browser prototype.
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. The problem is that the files for this add on are stored in binary form (as archived BMessages), so it’s not easy to translate them.
.png "WiFi stack - coarse design overview")
