Pavel's diary

This will be unusually long blog entry, but I have so many things I'd like to save for future reference, that I have to type it all (please bear with my English and notify me about errors I have done during typing it all).

I'm without my family at the beginning of this week. I'm in Hamburg, Germany, visiting Sun' StarOffice team and other developers from Intel, Novell, Red Hat and Google (if you sort the names of companies in the right order, you get "OpenOffice.org GRINS", funny - we still need Apple, Toshiba, Mandriva, IBM, Corel, Rational, OKI, SAP, Oracle, Fujitsu, Telia and many other companies to join us...). Sun' offices are approximately 2 hours away from the place I live if you do not count the delays when switching the transport means (10 minutes to the airport, 70 minutes on the flight, 20 minutes down to the city) and 4 hours in total. The traveling is not very effective way to spend time.

Flight was OK, I was even able to read my daily batch of news papers there. Took taxi at the airport. The taxi driver was not able to speak English, so I had to switch my brain to $((today-10 years)) mode and asked him if I can type the street name into his navigating system. Good. After typing "Sachsenfeld", the display shown the distance and estimated arrival time (which was very optimistic, BTW ;-). Interesting point: taxi in Hamburg is a bit cheaper than it is in Prague. We arrived at 9:50, just in time to get a cup of something hot (BTW: thanks go to Sun, the availability of hot drinks saved voices and health for many of us!).

The weather here in Hamburg is not very good these days. A bit colder than it was in Prague and also daily batch of snow mixed with rain is not pleasant. But unfortunately no one can change it.

The first person I have seen from Sun was Matthias H. Guess why...

The first meeting was introductory one - many new faces. I first met Kai B. Great to see you on board, Kai. The group of Intel engineers is getting larger every time. D. K., B. S., M. L. and now Y. L., all using IBM notebooks. If I count correctly, they had 5 of them ;-) One spare build notebook. They were well prepared for developer sessions ;-) (OK, I started with notebooks - to continue: some more IBM notebooks, Dell: me and Caolan - none of them 64bit capable though..., some VAIOs, and Apple only "represented" by our ladies - Zaheda B. from Google and Danese C. from Intel - on the meeting).

I also met with Tino Rachui. We discussed the current status of Mac OS X (!X11) porting (I'll blog about the current status later when I'm back at home with working UI - why VNC doesn't work all the time on Mac OS X, BTW?) and our goals when working on the project. We agreed on almost everything from "political" point of view. We also agreed that we need more developers, mainly skilled ones. Many members of our team do not have deep knowledge of the programming on Mac OS X yet. Including me, unfortunately. But I'm learning pretty fast. We also discussed some technical stuff regarding events and non-bundled applications. Interesting...

The next meeting was with the help writers team. We (Frank, Uwe, Martina and me) discussed many helpcontent related issues. I was well prepared (thanks to Ain and Adam for helping me to collect issues) to discuss problematic issues we had in the past (#i38421#, #i48032#, #i48034#, #i40213# and #i47563# and of course an issue, I never forget to mention everywhere I can: slow HelpLinker). Frank has shown me tools they use for help development and for fixing issues internally. Very interesting stuff. Non-Sun community members are not yet involved in creating new documentation. We also discussed this particular problem and found an eventual solution that could make it easier for non-Sun community members to fix issues in original (English) help. We used very similar approach in the past with child workspaces for community developments (before child workspace tooling was made available outside the Sun environment) - one child workspace opened for community help content writers/proof readers. This could save a lot of issues and time. The problem of creating new help pages is a bit different, but I think we can solve it too in the not very distant future.

Just before I left for Hamburg, I read about Apple's Help Center in Mac OS X. It is using HTML based help thus I took the idea about HTML help for OpenOffice.org. We discussed it more and found out other good ideas why it could be useful for other people as well (think of proofreading the help, much easier spell checking, ...). It should be fairly easy to write XSLT transformation of the current web pages. Some problems that were brought during the meeting or which I have just thought about now (Tuesday, late evening): images could be problematic - we can extract/copy them from default_images anyway, no searching (you can't search static web pages from them anyway), index entries can be generated to one page per help module etc. This is actually worth a small project. Any volunteers?

Side-note: Just when I'm writing this, I realized we have allfiles.tree file in the helpcontent2 module. God, its useful! Why we haven't heard about it before!? It is so simple and so brilliant idea, that I'm ashamed of the whole QA process we have created for Czech translators and proof-readers (the only excuse is that this file was created only in December last year)! Just simply put this file into your installed OpenOffice.org, in the directory help/language where language is the ISO code of your language (e.g. cs for Czech) and launch the help browser in the OpenOffice.org, select the Contents tab and browse through "All Help Documents for Debug Purposes" section. Brilliant. We have to work more closer together to prevent such ineffective work on both sides! Only minor enhancements: it is not needed to show the full path of the help page because when you already are in the section sbasic/guide, there is no need to have the full path to the file (sbasic/guide/control_properties.xhp) there, the filename is enough. And of course this file should be generated during build time anyway to prevent manual maintenance in the future.

The next scheduled meeting was about general (not only OpenOffice.org) localization issues. I found out that were not very well prepared for this meeting. But it was interesting to hear about Pootle, Rosetta, Open Translation Editor etc. in one session ;-)

The next meeting was the most productive meeting I had here so far. We (JJ, Monica, Rafaella, Ivo, Ause, Vladimir and me) discussed various translation related topics and we agreed on several things. I described the processes how community translators work, what they expect to get and what various tools and formats they use for translation. We agreed that we can't provide the native format and environment for everyone (PO is good for many teams, but not for all, web based service is good for some people but not for all etc.). But we also agreed we will try to make it very easy for every team to get their work done their way and we will provide clean English-US master GSI file directly somewhere (so I'm again able to include UI related patches for testing in my build system). I'll continue to provide POT files for PO format based translators (who can use kbabel, poedit, po-mode in GNU Emacs or various web based PO translation tools) because we have many teams (in fact, almost all of them) using this method of translations. (On Tuesday, I also had an interesting brain session with Ivo which was related to translations, so please do not forget to read about it too).

We also discussed the current way of submitting translations for inclusion. It is not optimal. For both translators and also for people doing the actual merge. During the session we (Ause argues it was me, I think it was Ause ;-) have got a brilliant idea how to speed up the whole process of integrating translations back to the source code so that we will be able to do this several times during the development of every release and not only once per release which was not very optimal way for translators - imagine you have only one chance to merge your strings in the source code and you do not have a chance to fix errors there, typos, make them consistent etc. It will be much easier in the future. We even discussed a possibility to make it more automated to merge translations. The future is bright. These ideas were brilliant enough that we skipped our long awaited discussion "complete GSI in the source" (remember jj+ihi+hjs+vg speak much faster than me ;-). If the above mentioned process will be implemented sometimes this year, I can even remove large part of my build system (regularly updated translations directly in the source code mean that there is no longer the need for fetching updated GSI files and it is only one step away from having every milestone available in every "active" language which is my goal right now) and I can finally come back to things I *really* would like to work on.

We scheduled the second part of the meeting for Wednesday because we were not able to talk about all points we wanted to discuss. The one major thing is Damien's proposal for web based service for translators.

Another meeting was ESC (Engineering Steering Committee) team meeting, with complete team in one room and with Volker on the phone. I think Michael will blog about ESC meeting or we will have meeting minutes anyway, so I'll skip it.

Unfortunately Volker was not able to join us for the last "official" part of the day ;-) Visiting "brauhaus", brewery. Before we went there, Stefan T. invited me for a small round trip near the center of Hamburg and we eventually also found my hotel, Junges Hotel Hamburg ;-) BTW: quite good hotel, but the only real connectivity there is Hamburg Hotspot network available only in the ground floor and not available in hotel rooms. But better than nothing. I was so tired during the nights, that I haven't used it at all.

Those who know me well, can imagine how I was feeling while we were in the brewery :-) And Florian even tried to convince me that he has seen me drinking beer in Koper last year! But people who love beer (in fact almost everyone except me) were happy - large glass "tanks" (I never seen beer served in such large volumes ;-) with light and also dark beer... You can imagine. And what was worst, no P-C there. I had do drink C-C. But very good pepper steaks. Caolan still has the vegetables before him - I have never seen him so white as when they put the full plate of vegetables before him after he ordered the largest steak they had. But it was only supplement :-) Nice discussions with Caolan, Florian, Eike, Malte, Stefan, Heiner and Joost. Planning for tomorrow's meetings.

When we left the restaurant/brewery, I decided to walk around the center of the city. Hamburg is very nice after midnight ;-) Took some photos using my mobile phone, back to the hotel. Very tired.

The next OOoCon will be located in France, Lyon. Congratulations to French Native-Language team. You'll have lot of work now! ;-)

P.S. My vote was for Lyon, of course! But good advice for Vienna team: please visit OOoCon in Lyon to see what could be done and how and inspire yourself for the next year. You'll have my vote next year!

Today I found this style of replying in several mails I had to reply. I consider it the most troublesome and confusing way of quoting previous text (it is even worst than top-posting, IMO, because you can simply ignore it). Here is the example:

...
This is
> the original sentence written by previous author.
This is the reply from the author.
...

The original sentence is broken in two lines and not only that, but also the first part is not marked as part of reply. The second part is though. Thus the reader must spend some unnecessary time parsing it - first his brain parses it as a reply from the author, but after reading it, it looks like it was written by the previous author, so your brain has to slow down and parse it again. This is very inefficient.

Very similar (less confusing though) is this:

...
                                                        This is
> the original sentence written by previous author.
This is the reply from the author.
...

People from Mactel-Linux were able to boot GNU/Linux on iMac Core Duo 17. They have some screenshots on their page and also lspci and dmesg output.

Update: developers published HOWTO.

Community builds are available here (some languages are still being uploaded though).

The server MůjMac (MyMac in Czech) published interesting article with various comparisons of iMac G5 and iMac with Core Duo.

Interesting comparison of MacBook Pro with DELL's notebooks was published by Macworld.

Looks like Apple is going to live hard year. Their users starts to compare prices to competitors (it was not the case in the past).

GNU/Linux build fails in final stage in module instsetoo_native because it can't find non-existent file in directory that also doesn't exist (#i62020#).

Windows build fails because it can't include assert.h in npsdk module (#i62021#)

Not ready for RC1 yet...

The next community build will be OOB680_m1. We will have lot of work though... First not available GSI files (404): mk, ne, af, xh, zu, nr, ns, st, tn, ts. Forbidden (403): cy. lt GSI file still does contain millions of empty lines.

You can see the results of downloading all GSI files here. I use older versions for unavailable files, but after 2.0.2 is released, I'll remove languages with wrong or inaccessible GSI files again to make space for new languages.

I have also uploaded gsicheck files - only nb and nn languages contained errors.

I did new re-split of my build system. DEVEL is now based on SRC680 (m156 now) and stable is OOB680 (m1 now).

This entry is a followup to my previous Stop everything, sell hardware! blog entry.

The end-user price of the low-end MacBook Pro in our country is set to 2500 EUR. So the difference between official price at Apple US store and our local price is ~850 EUR. Estimated delivery in March. I'll probably book some flight to New York in March to buy one. It will be much cheaper ;-)

I'd like to thank Florian and his coworkers for doing the work on aquavcl01 child workspace.

In the past days, I tried to integrate it into my build system and today, I have seen my first non-X11 window from svdem demo from vcl. This was the reason to announce Pavel's beer motivation for Mac OS X Aqua porters :-) You can join me!

I again had fun (a lot of fun, in fact!) with pam_unix2 module, with the changes between previous version we used and the current one. Using 'x' in the password field of all users with UID 0 was the culprit. New version also doesn't call additional modules (call_modules) if the UID of the user is 0. It has its logic in general, but unfortunately it is not the case for us ;-) But at the end: it works now again. Good.

As a bonus I debugged one gcc-3.x/gcc4.x C++ template issue with protected member functions. Quite easy this time :-)

And at the end, some fun with NumLock in X.org and switching between text mode and X (already reported in X.org Bugzilla). My son would be confused!

The release of 2.0.2 is getting closer and we still have 109 issues with target 2.0.2. Please have a look at your issues and process them now. Thanks.

Hint for QA team: what about bug weekend concentrated on these bugs? ;-)

... is not simple. I know that. But this is not an apology. I'm writing this blog entry to make it clear why I communicate the way I communicate. I'm working on *many* things (yes, everyone does, of course). To be able to work effectively (and deliver results) on so many things I apply very strict rules to my communication. These rules may look impolite and unmannered. But I do not mean them as such. Believe me.

E.g. I never send "thank you" e-mails, "me too" e-mails etc. And I do not expect such e-mails. Of course it is nice if people sometimes tell you "Thank you". It helps and motivates you for your work. But it also slows you down. Very often I'd like to thank people who work with me or on the projects I work on. But I prefer to say "Thank you" face-to-face, not via mail.

My e-mails are very short. Maybe too short sometimes. If I feel I have to describe something in more details, I spend very long time on writing it and thus some of my mails are maybe longer than they should be. But sometimes it is better to spend half an hour describing it properly and completely than write ten other mails...

I have heard several people have problems with this style of communication. Do not take it wrong, but I do not care. If you have something against my style of communication, tell me so. If you hide your problems, I do not care about you. There are millions of people who have their problems and are not trying to solve them. E.g. if you feel insulted by simple "No." without explanation in my mail (I never write *so* short letters ;-), feel free to ask why I answered in short. I will explain it more clearly. The worst thing you can do is to hide the problem inside you.

If you finished reading here, thanks and sorry. I hope you understand why I have to work this way.