gsoc2009

Locale kit : building a preflet

Blog post by PulkoMandy on Sun, 2009-08-09 22:15

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. I also had to modify some of the Locale Kit API to be able to actually change some things that were read-only. Finally, the preflet is also the first application using the date and time formatting part of the locale kit, which was not written yet. I had to both make the API work and make it configurable.

To do that I decided to call ICU directly in the preference panel, bypassing the usual API provided by the locale kit. This will be cleaned up later.

I'm still messing with the layout manager to get things looking right. Designing and coding UIs is not my favorite activity, I prefer messing with the internal of the system.

To design this panel I took inspiration from other OS, most notably Geoworks Ensemble (an old GUI from the ms-dos times) and Mac Os X.

International settings of some other OS

These use roughly the same system, a mix of dropdown menus and text fields, to allow the user to do almost anything with the date format, while still being readable. Windows allow only to enter a string using special chars such as Y for year. While this would have been simpler to code (ICU use such strings internally), I find it much less useable. My preflet also provide a realtime updated example of the current settings. The code is far from complete, for now it's only possible to select one of the default settings in the listview. The dropdowns are not filled in with the format info. The examples are working fine.

The other tab of the preflet is fully finished however. It allows you to select the preferred languages for localisation of texts. It's very simple, with only two lists and you can drag and drop languages between them to enable or disable them. You can also drag languages up and down to sort them by order of preference.

Locale preflet prototypeLocale preflet prototype

I'm tired of messing with scrollviews, tabviews and grouplayoutbuilders, so I will focus on the string parsing part and let the interface cleanup for later. I'd like to at least finish GSoC with something useable, even if not perfect, than a good-looking window that is useless.

Locale Kit : ICU integration on the way

Blog post by PulkoMandy on Sat, 2009-07-25 14:46

Locale Kit Interfacing with ICULocale 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.

ZeroConf Support Progress

Blog post by majie on Mon, 2009-07-20 16:33

Hi guys.

Sorry for no update in the previous weeks.

I'v made some progress. mDNSResponder, which provides the underlying ZeroConf functionalities, has been ported to Haiku. It runs on Haiku correctly. In order to make it run, minor updates in our network stack were also applied.

I'm currently working on the service browser. It is almost finished. I'm also trying to write some wrapper classes so developers who need ZeroConf features can easily use them. And my mentor Axel is working on an update to our DNS resolver. After the update we will write some code that can resolve ".local" domains. So in the future you can directly type "http://webserver.local/" in your Web browser. Without any configuration it will resolve it and take you there.

OK. Stop here. Thank you. :-)

Locale kit: quick developer guide

Blog post by PulkoMandy on Thu, 2009-07-16 16:36
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);

Locale kit: cross tools, messing with jamfiles

Blog post by PulkoMandy on Sun, 2009-07-05 21:29

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 second part of the post-it was about checking if collectcatkeys could extract strings correctly from sourcecode if they contained escape characters (\", \n, \t). Of course, that did not work at all. The problem is that we have to remove these escaped characters at some point and replace \t by tab, \n by newline. gcc will do that when compiling something, so if the program asks us to translate a string, we have to have it in unescaped form. This is currently done in collectcatkeys. But the change I made to collectcatkeys make it save the extracted string in a simple text file, and worse, I use tabs as delimiters. So this unescaping work will have to be done in linkcatkeys instead. This way, it is possible to translate the string easily, and then it is converted so the program will still find it back after compilation.

So, work for next week will start with a cleanup of my jam rules if I manage to do it (I'm still not very skilled at Jam), and fix of this quite important bug. But, next week I will be at the RMLL with some other Haiku developpers, so I'm not sure I will have much free time for coding. Well, there will be at least the hours I will spent in the train to go there.

Also, Oliver has made good progress on the wchar_t fixes. So I'm getting ready for messing with ICU and integrating it in the API. First step will be to build it with the new wchar-fixed gcc, then to make sure the tests are working ok before I do any integration work.

Finally, I also plan on making the Locale Preflet the first fully localized application in Haiku. This will allow me to test the catalog part and some other features such as the broadcast BMessage sent to all applications when the user change the default system language. The locale preflet will serve as a reference implementation of what to do when localizing an application.

CIFS client update

Blog post by Obaro Ogbo on Sat, 2009-07-04 16:03

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.

Back to coding

Locale Kit: the big picture

Blog post by PulkoMandy on Sat, 2009-06-27 19:14

almost-UML diagram of the locale kitalmost-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 :)

Syndicate content