Skip navigation.
KDE Developer's Journals

oever's blog

oever's picture

Working on KOffice

Today is the first day of my employment at a wonderful company called KO GmbH. KO GmbH provides services around software dealing with office documents, notably KOffice. I'm excited to have found such an inspiring job working in Free Software.

At the KOffice 2009 Sprint in Berlin last June, I got to meet many of the KOffice developers and was impressed by the productive atmosphere. In my job at KO, I'd like to help KOffice become enterprise-ready, by which I mean, that I want help the KOffice team make a reliable and flexible office suite.

My role in the company is software architect. The business cards Tobias Hintze, our CEO, sent me just say 'architect'. That inspired me to spend some time on this first workday to pose for a picture that goes well with a dEUS song about Buckminster Fuller, the architect after whom the buckyball was named.

The Architect

Listen to 'The Architect'.

oever's picture

CubeTest in SVG progress

The first episode of 'programming in SVG' led to some nice bling improvements in KDE. Aaron showed how to put an SVG program in a plasmoid and Ariya taught us the incantation to make the desktop shine through such a plasmoid. And last but not least Remco Bloemen mailed me with a working demo that hows how to include arbitrary data in an SVG application with data URIs.

Work in CubeTest 2.0 has progressed. The current version has nice animations that revert the cubes to a more ordered state by clicking the corners. The next steps will be to add the question generator and a style switcher and more styles.

Programming in javascript in SVG is rather different from programming C++. There is no need to implement a function for painting. This is similar to using QGraphicsView. There is also no type checking and no compiling. There is no way to print debug output to the console. I have not looked for a javascript debugger yet. I'm sure there is one that lets you set breakpoints and inspect data values.

A issue that I need to look into is internationalization. How does the SVG application know the current locale and how can user messages be switched accordingly.

A note on conformance and speed. I have found very little difference between the Firefox, the WebKit (Qt, Arora, Chromium) and the Opera SVG implementations. If the application works in one of the browsers, it will very likely work in all of them. CubeTest does not use fancy SVG features though.

An finally a request to look at performance. The latest version has a small counter that displays the number of frames that can be shown in one animation. The maximum is 10. Chromium scores 10. QtWebKit scores 2 (very slow). FireFox 3.5b4 and Opera score 4. The slow performance of QtWebKit 4.5 is not related to my graphics card; I tested on Intel and ATI.

What do your browsers score? Does your mobile browser display the svg properly?

Check out the new version.

cubetest screenshot

oever's picture

writing applications with SVG

Recently I received positive feedback on my program CubeTest. The program is being used in primary schools to help children to achieve better spatial insight. There is a teachers manual on-line.

CubeTest was originally written in Qt3 and ported to Qt4 later. Because some cube decorations are SVG images, the Qt4 version needed to use Q3Picture, a class for backwards compatibility with Qt3. The renewed interest prompted me to suggest to add CubeTest to KDE-Edu and clean up the code. Now I was faced with a chose: keep Q3Picture or move the cubes to a QGraphicsView.

I chose neither. Instead, I started an experiment with SVG. SVG is, in theory, well suited for this type of application. Since SVG was recommended by W3 in 2001, adoption was slow. Currently however, Firefox, WebKit and Opera support SVG rather well (as I found out and you will see).

So I started porting CubeTest to an SVG application. That's right, an SVG application. SVG, like HTML, supports embedding of javascript and for CubeTest purposes this more than suffices. The entire application can be one SVG file (unless you add raster graphics like png images).

An excellent advantage of writing an application in SVG is that you can use it as a widget in Qt easily but also allow people to run it from their web browser or as a KDE plasmoid. You can wrap an SVG application in a Qt program with 10 lines of code:

#include <QtGui/QApplication>
#include <QtWebKit/QWebView>
int
main(int argc, char** argv) {
    QApplication app(argc, argv);
    QWebView *view = new QWebView();
    view->load(QUrl("file:///tmp/cubetest.svg"));
    view->show();
    return app.exec();
}

This application will show a window with the SVG application running inside it. Resizing and mouse events are handled as you would expect they would.

In conclusion, here is the CubeTest port as it currently stands. To view it, use Firefox >= 3, Arora >= 0.6 or Opera >= 9.6. Or use the 10-line program above with Qt 4.5.

CubeTest SVG

(you can rotate the cubes)

oever's picture

Qt Overload: twittering birds

I just added some content to the new cute Qt community website.

oever's picture

Portable Meta-Information continued

In a recent blog, David Nolden talks about transferring user-generated, file associated meta-data. His post was well written and the ensuing discussion interesting. I'd like to continue his line of thought here.

Anything the user creates on his machine should be easy to archive, synchronize, share, query and protect. Most data these days is stored as separate files. The idea of the semantic desktop is to make content depend less on files. The file is just the container of the content. The content consists of various concepts and relations between the concepts. Also, there are bigger data blobs, usually multimedia files, but also industrial data types like measurement results, logging files and databases.

As long as nuggets of data are separate entities, this is fine. But what do you do with small annotations to files such as ratings, tags, or source logs? The Nepomuk solution is to store this data in a central database. David promotes the use of companion files to the content files. This type of file is called a sidecar file. To speed up meta-data querying, a central index is required.

This is an interesting approach even though it is not a complete solution. I'd like to emphasize that the requirements for meta-data are the same as those for normal data. Both are data and both are valuable.

Let us look at an example of extensive meta-data use. We forget for a bit the details of how to store and manipulate data and simply imagine we have only data and storage media. On storage A, there is an audio track. The audio track was recorded at a certain time and place by a certain person. Recorded are sounds created by other persons. The owner of storage A, Mrs X, records her opinion about the track in a couple of paragraphs of English prose and as a collection of grades for some aspects of the track.

Mr Y is permitted to lend the storage of Mrs X. Mr Y records his opinion about and listening behavior of the track on his personal storage disk, B. He shares his opinion of the track with Mrs X, but keeps the information about where and when he listened to the track private. This follows the policy he has laid out on his personal devices with respect to audio tracks lent to him. His audio player enforces this policy for him. Mr Y also makes a link between the track of Mrs X and an audio track he once borrowed of Mr Z. In the link he stores a comment about certain similarities between the tracks.

In the meantime, Mrs X keeps listening to the track on her second mobile storage C. When Mr Y returns storage A, Mrs X synchronizes it with C and makes a backup of C to her media tank, D.

There are many technical issues that must be solved to enable a relatively simple scenario like the above.
- X and Y must both be able to handle the audio protocol in which the track is recorded
- X and Y must use a common ontology for the prose review, grade points and gradable categories
- X and Y must both use software that understands the way in which the data and meta-data is stored on storage A
- Y must be able to store meta-data about data that is no longer in his possession
- Y must be able to define a filter that influences the way meta-data is synchronized across different data storages
- Y must be able to store relations between two or more data items
- X must be able to synchronize and merge different meta-data items with meta-data specific rules.

Using sidecar files does not solve any of the above issues on its own. This does not mean that it is a bad idea. It just means that it is not a complete solution. There is still an awful lot of functionality required in addition. Sidecar files allow programs that know nothing of meta-data or ontologies to keep that data intact during copying of directories. But that is not nearly enough for handling meta data. Hence sidecar files will always be an incomplete solution.

Another interesting and also incomplete solution is a proposal on live.gnome.org. It is recommended reading.

It is clear that we need way of handling data that goes beyond what the current file systems can do. What alternatives are there? We could keep all data in a triple store which can also be exposed as and synchronized with traditional file systems and might even be a traditional file system underneath.

oever's picture

Browsing archive files with libstreams

ArchiveReader is a class in libstreams that allows you to open files embedded in zip, deb, rpm, jar, openoffice, and email files. It is used in the kio slave jstreams:/. This class works like this:

    /* create an ArchiveReader that reads files on the local filesystem */
    ArchiveReader reader;
    FileStreamOpener streamopener;
    reader.addStreamOpener(&streamopener);

    /* read an embedded file */
    InputStream* stream = reader.openStream("/home/james/archive.zip/package.deb/README.txt");
    doSomethingUseful(stream);
    reader.closeStream(stream);

    /* list embedded files */
    ArchiveReader::DirLister lister = reader.dirEntries("/home/james/archive.zip/package.deb");
    EntryInfo entryinfo;
    while (lister.nextEntry(entryinfo)) {
        doSomethingUseful(entryinfo.filename);
    }

For the next Strigi release DirLister has been much improved. The old implementation contained a simple vector with EntryInfo objects. This implementation would read an entire archive before returning the first entry. Interactive applications like Dolphin would have to wait a long time before they could show something.

The new application has a pointer to a ListingInProgress object which reads entries on demand. So now interactive applications can update their view as more results come in.

When an entire archive is read, the entries in it are cached inside the ArchiveReader object. If the contents of an archive is listed twice there is no need for DirLister to read the archive again (unless it has changed).

Multiple concurrent DirListers can read from the same archive at the same time and they will share the (internal) ListingInProgress object.

The emphasis in the new ArchiveReader is on speed and ease of use. This means that implementing it was not easy. Nevertheless the implementation is quite clean and readable. ArchiveReader can be a convenient base for a KIO, FUSE or GVFS implementation.
By implementing a different StreamOpener and supplying it to ArchiveReader you can access remote sources.

oever's picture

Rejoice: A fresh Strigi

Another epic owl release! Granted, not as epic as Eigen 2.0, but still very nice.
Strigi 0.6.4 gives some nice index speed-ups and fixes a few annoying bugs. There is one new feature: LZMA support.

See the ChangeLog for more details.

The coming months will see more smaller Strigi releases. They will have emphasis on useful analyzers and improving KDE integration.

If you want to catch up with me to discuss desktop search, file formats or semantic technologies, I will be at FOSDEM this weekend.

oever's picture

supporting LZMA streams

LZMA is a relatively new compression algorithm. It is used in more and more places: 7-zip, the Linux kernel and deb and RPM packages. So adding LZMA to Strigi was a desirable step. The code for LZMA can be downloaded from the 7-zip website. It is in the public domain.

For decompression, only 3 c files are required. I've added these to the Strigi repository directly. The decompression interface of LZMA is similar to that of GZip and BZip2. It nevertheless cost me quite a bit of time to figure out how to use it exactly. The result is a Strigi::InputStream class that can be used in the same way as the other decompression classes.

Once the InputStream was written, adding LZMA support to .deb files, .rpm files and jstream:/ was simple.

This improvement, along with a better index, will be released in Strigi 0.6.4 this week.

oever's picture

Buy a telephone from Nokia

Do you need a new telephone? A mobile one without a wire? Please consider buying a Nokia telephone.
When you buy a Nokia telephone you support free software. Do not buy an iPhone, do not buy a Palm, buy a Nokia.
Were you considering buying a Motorola or an HTC telephone? Think again. Think Free Software. Buy a Nokia.
Avoid Windows Mobile. Avoid the iPhone. Avoid WebOS. Buy a Nokia with Free Software.

And use Qt and KDE.

oever's picture

Maemo Summit and Desktop Search Hackfest (part 1)

The first Maemo Summit was held in Berlin on the 19th and 20th of September. Nokia proposed to organise a "Desktop Search Hackfest" in collaboration with the GNOME foundation. This proposal was forwarded to all the participants in the discussions on a set of common standards for desktop search called Xesam. The list of attendees was very interesting and I had the impression that it would be hard to get the same group of people together soon. So I decided to skip a family day at my employer, PANalytical, and went to the hackfest.

On the way to Berlin, which is a single train from Hengelo, I joined Ben van Klinken, the author the the excellent CLucene library. He brought his girlfriend, Femke, and she brought a book, which was a very sensible idea. Ben and I talked nothing but indexes all the way to Berlin. Discussing ideas and browsing code in the dining car is an excellent way to travel.

The summit was held at C-base a non-for-profit for computer and network enthusiasts that is housed in a crashed space station which is merged with a school for acting. As a result, the halls were filled with a mix of free software programmers, Nokia employees and wanna-be actresses. The corridors were lines with pictures of drama performances and next to the main lecture room was a storage room for acting props and costumes.

The hackfest would to start on day two of the conference, so we could spend day one by attending various lectures. There were about 300 people at the conference which I thought was a large amount. Nokia has really done their best to invite many members from all over the free software community.

The schedule had a lot of good talks. Here are some highlights:

Ari Jaaksi
The VP of maemo software is mostly know in the community for his statements about patents and DRM. He has a tough job because he is leading the most free software project within Nokia and thereby leading a revolution within Nokia: The N810 is not locked down at all in contrast to most other mobile devices. The N810 is not a phone, but the next version of the internet tablet will have support for HSDPA so you use a mobile connection if no wifi is available.
Maemo UI Vision
Harri Kiljander, director of user experience, gave a look into the way UI designers work and listed a number of rules to follow when designing application for small devices. 30 milliseconds are the maximal lag any application can have at any time. If feedback to a user action is slower, the user will not perceive his action as successful and will attempt to repeat it or will be annoyed by the slow application. A UI element that requires finger input must be at least 9x9 millimeter, which is equal to 80x80 pixels on the N810. When listing the target audience of the internet tablet, he mentioned that two thirds of the current Maemo users are developers.
What users want
Reggie Suplido maintains a community website for the Nokia internet tablets. He mentioned that competition in the high end devices market is currently very high and he envisions Plasma-like (not his exact words Eye-wink user interfaces.
What can we get out of Fremantle
Peter Schneider gave this interesting talk. Fremantle will be the next software release of the Maemo platform. Many big changes have been planned for it. Not all details of the next generation hardware can be revealed yet, but HSDPA and access to the 3D acceleration of the device are already announced. He talked about the search hackfest and Tracker. Nokia has chosen Tracker for search on the Maemo platform and the hackfest should help ensure that it will be compatible with the other search solutions out there. He did not mention Xesam, but I'm sure that's what he meant. Peter said that Clutter will be available on Maemo. This is an interesting choice considering that, in contrast to QEdje, Clutter has little to show for so far (although, I may have missed where the cool clutter stuff is). It also makes Nokia depend on OpenHanded, an Intel company.Users are encouraged to write applications using the gecko rendering engine. Firefox extensions and Greasemonkey extensions are also encouraged.An important remark was that Nokia is not choosing between GNOME and KDE. But are supported. This makes sense, I think: by keeping the platform really open and allowing multiple options they give the user real freedom. Supporting both does not mean they will provide both or either on the vanilla device.You can publish you code on garage.maemo.org. The best code will be endorsed on maemo.nokia.org. Nokia will provide search engine sponsoring (whatever that is), early devices (that must be returned), and free UI consulting to free software developers.The roadmap to Fremantle plans an alpha in November and a beta somewhere between March and May. It will contain a theme maker and Qt 4.4. (let's hope we have a fast KDE4 version for it by then).In conclusion, Peter said that big decisions about Maemo will be made on the summit and not at the Nokia headquarters. This is how seriously they take the community.
Lightning talks
Among the many lightning talks there were a few great ones. The best talk was from a university project that wrote an application for the N810 that can help analyze cow milk in remote areas. Elisator takes a photo from an Elisa well plate and analyses it by looking at the colors in the different wells. This makes it possible to take a complete lab to the bedouins.
QEdje gave an impressive demo of how to easily develop fancy GUIs that allow easy embedding of Qt widgets. The presentation was written in QEdje and embedded a QWebkit component in a cover flow. The last talk I saw was a demonstration of a usb2svg adapter. This presentation was given from an N810 and controlled from a mobile phone.

So what about the Hackfest? You will have to wait for my next blog post. I can tell you though, that I predicted that whatever would come of it, it would be a very interesting social experience, considering the Xesam standardization process so far. This prediction came true.

I will leave you with a great video impression of the conference courtesy of Karoliina Salminen.

Maemo Summit 2008 from Karoliina Salminen on Vimeo.

PS Almost forgot to mention that Marijn gave a stunning demo of running a complete KDE4 on the N810.

Syndicate content