Brainstorming

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.
Anne-Marie would love to have this available to use in KVocTrain. KVocTrain works with files which contain vocabulary data, and it has an internal editor to create these data files. But it is a seperate fileformat, so you need use the built-in editor for creating data. Now an ODF library would make it relatively easy to use an ODF-based fileformat for this data, so you can use, for example, KSpread to enter the data, or use it to import from all kinds of datasets. Here you can clearly see the flexibility and power such a technology would bring to KDE. Reuse of code and co-operation on standards are important cornerstones of KDE, and this would bring them to a new level.

However, there are many pitfalls to overcome before this can be implemented. The first step will be to allow applications that can output documents (through saving or printing) to create ODF documents. The KOffice hackers will create a library which makes writing to ODF documents as easy as possible. Just like Qt currently makes it possible to output practically all content to SVG or PDF, the KODFlib (the name is still undecided) will make it possible for applications to output ODF files. Thomas Zander digested the results of the meeting in an email to the KOffice mailinglist, which makes for an interesting (though technical) read.

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!

Architecture

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.

In KOffice 1.x, the strategy was the chosen solution across the office industry: practically just load the other application within the current one so you have all the needed capabilities for the object. In KDE, we have the KParts technology for this. Both applications need to suport this, of course - the embedding app has to load the one to be embedded, which has to take care not to interfere with the embedding application. It works, but it is complex in terms of technology and user interface, and is very heavy on resources. The new Flake technology allows you to just use what you need - the basic display, load and storage technology and the primary manipulation tools. Flakes integrate in the application on a much lower level, allowing for less overhead and more flexibility. You're only embedding an object, not a full document. Now, as ODF supports having an object inside another object, a Flake must be able to load a Flake. And sometimes, data can be loaded by two Flakes, and you have to identify the right one. Everything had to be carefully designed to ensure there are no clashes. This technology is also needed for drag'n'drop and copy-and-paste, as those are essentially about loading 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.

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!

Klarälvdalens Datakonsult AB (KDAB), who provide consultancy, training and development on Qt and KDE-based applications, provided us with their office in Berlin. Several KDAB people joined us, and not just paid for, but also knew where to get the good food!

Further, Trolltech (the guys behind the Qt toolkit) are sponsoring the travel costs of the ODF Meeting through our own KDE e.V., so we owe much to them as well.

Links to the articles, blogs, pictures and other information is being aggregated on the Koffice ODF Sprint site in the Galleries. Have a look to see a more detailed and personal side of the meeting!

<  |  >