The two days of the KOffice ODF sprint were very productive. Most time was spent on group discussions, and designing specific parts of KOffice in smaller groups. Of course, code was written as well, and for an overview of what happened, read on!
The first real KOffice ODF day kicked off at 9am with a presentation by David Faure, who talked about the technical side of the Open Document standard. He explained how the format works, and how to read and write it. He also talked about the way the standard came into existence, and the process of improving it. David urged developers with valuable input to join the OASIS committee, which is responsible for ODF. Philip Rodrigues, who spent the weekend working on documentation, condensed all this information on the KOffice wiki. And not only a basic ODF-architecture overview, but also a lot of deeper, more technical information for those who need it.
Then it was time for lunch. It took some time to get the developers on their feet, as the talk by David sprung off a lively discussion. Finally, we decided to get the food to them. During and after lunch the discussions continued with further detailed talks about ODF, the underlying XML structure and its implementation in KOffice. Okular wants to use KOffice technology for displaying ODF files, thus Tobias' input here ensures that the KOffice architecture supports this implementation need.
After the ODF discussions, Inge Wallin started a brainstorm about the vision he has for the future of ODF: every KDE application should be able to work with it. The developers talked about this for hours, as it is new and uncharted territory. What use cases are there for ODF on the common desktop? How would they consolidate the rich ODF functionality available in KOffice within a library, to be used by applications? Till Adam (from Kmail and Akonadi fame) started daydreaming about VCards and loading and saving emails to ODF.
In time, this "KODF" technology might make KDE the preferred platform for everyone who values open communication and the sharing of knowledge. Governments and companies alike can enjoy the advantages of this integration in the Free Desktop. Now there's an imporant question for the developer- and user community: the KOffice people, and specifically those designing this library, are looking for use cases for this technology. Having those would enable them to make a more generic solution, and thus advance faster. So think about where you can use it, and how you would like to use it. If you have a concrete example, report this to the KOffice developers. You can use the KOffice developer mailinglist or add comments to this article. It will be appreciated!
Next, a small group of core developers gathered in a seperate room. A talk to David made clear what they had been working on: working out the details of loading data in Flake shapes. Loading data might sound simple (it does to me) but David explained how hard it can be. If an application loads a document, objects (parts of other documents, like a picture, spreadsheet, vector graphic) can be embedded in it. So the application has to identify the right Flake shape for each of those embedded objects.
While these developers were discussing loading in Flake, the other hackers were hacking away, talking and discussing architectural issues, or trying to work out some details. It proved to be very difficult to get them out for dinner, but we managed to convince them it would be healthy to stop working for a few hours. As it was raining heavilly, we were lucky dinner was planned at a Turkish restaurant almost next to the office.
Implementing the new ideas
After dinner, the developers continued implementing the ideas they have. The office was full of hacking people until after 2am. And the next day, you could hear keyboards being abused at 9am already, so I'm pretty sure most hackers will need to catch up on their sleep. But they clearly wanted to get as much out of this meeting as possible. It proved to be very useful to be in the same room, as much new technology was being integrated into KOffice. This resulted in a lot of questions, and having the person who wrote a certain piece of library you need just sitting next to you is very efficient.
Alfredo and Martin got the KFormula flake loading and rendering, and Jan has hopes to get Karbon at the same level before he leaves. The discussion about loading ODF also paid dividends on Sunday, when the hackers were slowly getting the infrastructure to pass testcase after testcase. Tobias went to work on an Okular tutorial for writing plugins, to ease the process of writing an ODF reader in the future. Pierre Ducroquet and Sebastian Sauer where working on the basics of KWord, and finally were able to get it to display background colors and some other testcases from the OpenDocument testsuite.
So people were both talking and hacking, and working on both creating and implementing new things all day. Overall, it was clear what the greatest benefit of this meeting was: the design and other results of the discussions. Though there has been hacking, most time was spent talking to each other, and trying to flesh out the details of the KOffice infrastructure. This meeting will ensure the architecture is sane, powerful and usable. And of course, we had fun. There was good food (thank you, KDAB!) and some beer as well. It's always nice to meet your fellow hackers, and see what faces belong to the nicknames you see so often.
We want to thank the sponsors for their support, as it is really a big boost to KOffice!