What's new, based on identica notes:

• Thoughts on deploying SQLite turned out to be work in progress. Valuable input from our distro friends. A special wiki page has been created. See the last item of this entry
• KoReport, Kexi's rpt backend has undergone some refactoring to make it more generic.
• Fix number 1, charts working again in the designer.
  
• Working through the huge list of issues krazy has found with the kexi codebase, not glamorous, but necessary!
• Refactored the report renderers, and given better class name, to make the report library suitable for adoption over all of KOffice.
• Do you want well working MSAccess to Kexi converter? It's up to you - request it!
• KOffice now has a suite-wide reporting library! (placed in koffice/libs/koreports/)
• Kexi switched to "system" SQLite again. We want to play with distros well, but will check SQLite features at compilation to maintain high quality standards.

(brought to you by Adam and myself)

Rendering slides is a complicated business. Slides can contain tons of different features just like webpages can. People expect that presentations look the same in different programs. Perhaps not pixel-perfect but very similar nevertheless.

OpenOffice and KOffice (and the Maemo/Meego Office Viewer) both have ODF as their main file format. ODF is an open standard and this means exchanging data between these programs should be simple and lossless. To help the developers of these programs find differences in rendering of slides, I have written a program that loads a presentation and shows it as rendered by KOffice and OpenOffice.

As an added bonus, it also shows how these programs render PowerPoint files. PowerPoint files are converted to ODP first and then loaded into each of the two rendering engines. That gives four types of output:

• Converted by OpenOffice to ODP and rendered by OpenOffice
• Converted by KOffice to ODP and rendered by KOffice
• Converted by KOffice to ODP and rendered by OpenOffice
• Converted by OpenOffice to ODP and rendered by KOffice

You can see an example view in the screenshot and screencast below.

The code has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

"There's nothing easier" -- you say -- about packaging and deploying SQLite. "Just take the software with default settings and package as a shared lib plus SQLite shell".

It's not that simple.

With 2010 we've started to employ identica (then connected to Twitter and Facebook) as an channel for our live changelog at the {power}user level. Here's the dump for the past ~30 days (oh I should have used an XSLT).

• We're replacing serialized QFont attrs with ODF equivalents in Kexi Reports file format; e.g. fo:font-family; it's extension of OpenRPT
• Finally we're still embedding SQLite as many options are not set in distros, e.g. SECURE DELETE should be the default http://bit.ly/amZfJ3

Today, Nokia released the first public version of the office document viewer for the Nokia N900 phone. It was uploaded to the Maemo repositories. This version supports text files, spreadsheets and presentations in OpenDocument format (ODF) and Microsoft Office formats. The viewer requires the latest update (PR1.1) to the N900 software. You can install 'Office Viewer' by adding the maemo-devel repository to your N900 catalogues:

Catalog name:

Maemo Extras-devel

Web address:

http://repository.maemo.org/extras-devel

Distribution:

fremantle

Components:

free

Then the application 'freoffice' will be available in the category 'Office'. The install is 9 megabytes.

With the viewer, you can open multiple files at once, open office documents from your e-mail, search in office files and copy and paste from your documents. A very nice feature is the ability to give presentations with the phone. Here are some screen shots of the viewer running on the N900.

The code for this viewer is available in the KOffice repository. New releases of the viewer will be uploaded to the repository as KOffice progresses towards version 2.2.

The viewer has a simple user interface and responds quickly to user input such as page changing and scrolling.

One of the great things about KDE 4 is how powerful the APIs for the central components are. In particular, Akonadi and Nepomuk have become very easy to use in custom software and third party applications. I recently discovered another very powerful set of libraries: the plugin API for Koffice. Using those libraries, I recently wrote a little "docker" that lets you attach the documents you are currently working on in koffice to a new calendar event which can be used by any Akonadi-enabled application.

Recently a number of nice coincidences happened: I received my second-hand Intuos3 A5 tablet just day before the new shiny Qt 4.6 has landed with QTouchEvent (among many other features). Also I conducted my 3+ hours of trainings on APIs designing to my coworkers (based on Jasmin's document) just week before we had some essential KOffice APIs discussions based on the same material thanks to Olivier Goffart (QtDF).

Many small fixes are a building block of the Kexi porting effort - the goal is joining the KOffice 2.2. Many of the fixes and refactoring is related to forms. Much more left and we're scheduling works on crazy features even up to Kexi 2.6 already.