aKademy 2007: The Tracks

On Saturday, aKademy 2007 kicked off with a keynote by Lars Knoll of Trolltech, with two further keynotes throughout the day by Mark Shuttleworth ('13 Lessons for the Free Desktop') and Aaron Seigo ('Beautiful Features'). After Lars' talk, two separate tracks started. Read on for coverage of these tracks.

KDE 4 Pillars

Strigi

Jos van den Oever gave an overview of the history of search in KDE. The original implementation began with KFind (1996), followed by KFileMetaInfo (2001) and Kat (in 2005). Last year, at aKademy 2006, Nepomuk and Strigi were introduced. Nepomuk uses sematic storage technology, following a new FreeDesktop.org technology (Xesam). Strigi consists of data extraction, indexing and search elements.

These two new KDE tecnologies form part of the Pillars of KDE 4. A problem with existing desktop search was the difficulty of managing many file formats, many tools and many interfaces. KIO (for KDE), and VFS (for GNOME), doesn't work in all cases (such as when 'chained' in recursive directories) and they are not a complete solution for desktop search.

Strigi uses one stream of information that is processed by a pipeline, producing different levels of analysis, with the result produced at the end. Testing has highlighted that Strigi appears to be much faster then Beagle, jindex, and Tracker (indexing 10,000 files, 168 MB in total). One of the KDE Summer of Code projects enables the indexing of 18 different chemical formats using Strigi.

Flake

Boudewijn Rempt presented the new KOffice 2 tecnology, Flake. This lets you compound documents. Flake composes your document from individual objects: text frames, images, vector graphics, tables, connectors. Boudewijn illustrated the controller, the model, and the view. The KoTool create a KoShape and the KoShape create the KoCanvas. Each application has a specific canvas. Shapes can be created by factories, from templates, can be nested, grouped and aligned. Shapes know how to draw themselves, and load/save other shapes. Colour is a problem because of the subtly-different results produced by different devices, such as scanners, cameras and displays. Flake is not complete for all shapes. It is currently missing a table shape, video shape and a map shape. One of the Summer of Code projects will see the creation of a music shape to author and represent sheet music.

ThreadWeaver

ThreadWeaver simplifies the life of the developer in the age of multi-core processors, and introduces new performance and functionality improvements. Mirko Boehm refers to ThreadWeaver as "walking and chewing gum at the same time". ThreadWeaver enables both complete utilisation of all available CPU resources, and also of the temporary suspension of tasks, for instance, indexing updates of Strigi. To take advantage of ThreadWeaver, an application only has to implement a job class, put it in the (singleton) queue and wait for the job to end. Illustrating the promise of ThreadWeaver in practise, Boudewijn Rempt revealed that Krita has implemented visual filter previews using ThreadWeaver, to prevent GUI lockups.

Sonnet

KSpell1 was the original attempt to solve the complex technical issue of spell checking in KDE. Completely tied to the ispell backend, significant problems were soon noted, often arising from incompatible changes in the backend. After several major releases, KSpell1 stopped working completely. Realising this terrible state of affairs and wanting to prevent a future repeat experience, Zack Rusin created KSpell2, a backend-independent solution for KDE 3.2 - ispell was immediately depreciated in favour of the aspell backend. Unfortunately, this second implementation features an extremely complicated and over-designed API.

Sonnet marks the third KDE approach at the spell checking problem. Developed with the twin aims of a simplified API (the previous solutions required 7 components to spell, Sonnet consists of a single element), performance (KSpell used separate backend processes even for concurrent checks) and wider language support. A primary issue for spell checking certain languages, such as Thai and Japanese, is boundary detection and determining meaning which changes based on context. Sonnet currently includes English, French, German and Polish. The much-requested correction suggestion menu will also make an appearance in the Sonnet implementation.

Akonadi

Akonadi is a new framework for the KDE-PIM Project. Akonadi is based on an asyncronous library, and has a KJob-based API, which lets you adjust monitoring tasks, including notification filters. This enables several new features, not least simpler mail support. Rather than write custom connectors for each PIM application, developers can now simply write a serialisation plugin and an agent, and retrieve data through this channel. Agents react on changes (like when an item is added or removed from the Akonadi storage structure). Till presented a simple Plasma applet showing notifications of new email and how the Akonadi console displays the messages.

Quasar

After the impromptu appearance of Zack in the Sonnet talk, the second talk from Zack introduced Quasar, a framework for graphic effects. Mathematically and graphically accurate, Quasar enables the developer to chain filters together to produce the desired effect without requiring any knowledge of the maths behind the scenes. The current focus within Quasar development includes improving the performance when processing large images (+30,000 x 30,000 pixels) and combining Phonon to allow real-time manipulation of video imagery.

Decibel

Tobias Hunger began his talk by explaining to us why he thought Decibel was needed. He showed us a sheet with a lot of different applications and protocols, each meant for communication, but rarely actually communicating with each other. This posed a problem for end-users, as they must use several different chat applications and tools to be able to communicate.

For developers, the situation isn't much different. Applications want to support as many protocols as possible, but this leads to a huge amount of work. Not just the protocols themselves (often proprietary and hard to get right), but you also need to work on UI, provide configuration tools and a lot of protocol-specific things.

Decibel separates the protocols (with a plugin structure), based on Telepathy, from the basic GUI and configuration. It manages, stores and retrieves presence, user management and contacts. The most interesting thing is that Decibel is based on a component manager. A component is an interface, using and/or presenting the Decibel functionality. Decibel supports profiles for these components, so you can, for example, ensure that during your working hours, a SIP call leads to the opening of a phone window, while when you are away, the 'out of office' profile ensures calls are answered by the component providing an answering machine.

Currently, there still is quite some work to do on Decibel, but Tobias ensured us he would have been able to show a working phone connection if a component on his laptop correctly resumed after the time spent in suspend mode. Yet, he was able to present us with a compelling vision of easy communication in every application which requires it. Decibel communicates using D-BUS, and the Telepathy system supports making remote D-BUS connections between peers, thus allowing for inter-application communication over a network. Implementation of functionality such as real-time co-operation would be eased by Decibel.

WebKit

Lars Knoll held another talk on Saturday, this time about Webkit within KDE. Lars started with a historic overview of KHTML. KDE started with a simple filemanager, KFM, but quickly felt the need for a HTML engine. In time, demands grew, and the HTML engine went through several big refactorings, adding a DOM, CSS support and scripting. KHTML was most successful in the 2000-2003 period, when it was the first web browser supporting right-to-left languages, and enjoyed a majority marketshare on Linux/UNIX.

In the Summer of 2001, Apple silently forked KHTML, and after 2 years of work on it they announced Safari. Though the community was proud that Apple recognised the quality of KHTML, the developers were less happy. Apple initially didn't play well with the community, releasing source code by dropping huge monolithic tarballs at a time. The frustration grew, and came to a climax with a blog by Zack Rusin about the lack of co-operation from Apple. Apple responded, and started the Webkit project, slowly opening their development. Finally, in 2006 a research project was initiated by some KDE developers to bring Webkit back into the arms of KDE. KHTML's marketshare has diminished, while Webkit has a 5% marketshare through Safari, and even more with the help of the Nokia S60, which sold millions. Several companies are working on Webkit besides Apple and Nokia, such as Adobe and Trolltech.

Trolltech, searching for a cross-platfrom, high-quality HTML renderer, is working on integrating Webkit in Qt 4.4 as a widget. They are also committed to developing a KPart with full KIO and KWallet support, thus integrating it into KDE. Discussion about replacing KHTML with Webkit in KDE is still ongoing, but according to Lars, unifying Webkit and KHTML would be the best option. Despite his initial scepticism, he found Apple to be very supportive to Trolltech's efforts integrating Webkit in Qt product and in KDE, and Apple engineers have even contributed considerable amounts of code. Working together increases the marketshare and thus mindshare Webkit has, and could benefit all parties.

Bindings

Meanwhile, Simon Edwards kicked off the Bindings track (which ran alongside the KDE 4 Pillars track, often resulting in a difficult choice for attendees!), describing the process of creating KDE applications in Python. He started with Python and its features, but as many attending the talk were Python veterans, he quickly continued to talk about his own involvement. Simon worked with C++ for a long time, but never was too happy with it. When he discovered Python, he immediately fell in love. For him, the binding of Qt/KDE and Python is a 'match made in heaven'. He started developing system configuration tools for Kubuntu. He showed how similar the Python-Qt-code is to C++. The bindings form a glue between the typical C++ syntax and the Python one, yet preserving many of the cool Qt features. Yet it is very efficient to program, and the performance overhead is very small due to the use of the Qt and kdelibs for the heavy lifting. Painting is delegated to the Qt libs, yet it is possible to subclass a C++ routine, and modify it. The biggest disadvantage is the memory usage of the python interpreter, but this can be shared between all Python processes.

Next, Simon progressed to the 'cool stuff', showing how to embed a Python application in the C++ based KControl. He expects KDE 4 Python bindings to keep up with KDE development, releasing a beta alongside KDE. Then he talked about the nice side-effects the Python work brings, like faster development, better debugging information and a lower barrier to contribution. According to Simon, PyQT and PyKDE bindings bring the fun back into development.

After the talk by Simon, one our youngest members paired with one of our more seasoned hackers to give a talk about their work on the C# bindings. We will cover thisthis in a later article (an interview is planned) so you'll hear about it!

KJSEmbed and QtScript

After the coffee break, Richard Moore talked about KJSEmbed and QtScript. These scripting tools give several new possibilities to applications. First, you can have parts of applications in a higher-level, dynamic scripting language. Second, you can extend applications later on, by shipping the scripts separately. And lastly, your users can use scripts to automate tasks or extend the applications themselves. After an overview of scripting in user applications like emacs, Dreamweaver and Paintshop Pro, Richard continues discussing the features every scripting framework should offer. The ability to extend functionality early, at a high level, coupled with being able to stick components together and automate existing functionality are key components of a scripting framework. KJS was written for web browsers, while QtScript is specifically written to script Qt based applications.

Kent Hanson's talk had a strong focus on examples and really showed what was possible with QtScript. He showed how the scripting system used signals and slots and gave a quick overview of the API.

Further talks

There where other talks about okular, cryptography, Kexi, Krita and a series of short talks about the KDE Games (like 4 minutes each). Some of these talks where to technical, or we where unable to cover them due to a lack of manpower (it's just two of us...) so if you want to know more, you can have a look at the aKademy site, where slides and even video's will appear.

We heard many interesting talks, and enjoyed writing about them, so we hope you did enjoy reading about it. As said, video's and slides will appear on the aKademy site, and we're sure the authors of the talks will happily answer questions. And of course, Sunday brought another bunch of talks, which will be covered in the coming days, together with hopefully many of the BOF's and some interviews.