[dot] aKademy 2007: The Tracks

[Dot Stories]

URL: http://dot.kde.org/1183388210/

From: Jos Poortvliet and Danny Allen <>
Dept: on-the-right-track
Date: Monday 02/Jul/2007, @07:56

aKademy 2007: The Tracks
========================

   On Saturday, aKademy 2007 [http://conference2007.kde.org/] kicked off
with a keynote by Lars Knoll of Trolltech, with two further keynotes
[http://dot.kde.org/1183385741/] 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


  I. 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 [http://nepomuk.semanticdesktop.org/] and Strigi
[http://strigi.sourceforge.net/] were introduced. Nepomuk uses sematic
storage technology, following a new FreeDesktop.org
[http://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.


 II. FLAKE

     Boudewijn Rempt presented the new KOffice 2 tecnology, Flake
[http://wiki.koffice.org/index.php?title=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.


III. 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.


 IV. 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.


  V. AKONADI

     Akonadi [http://pim.kde.org/akonadi/] is a new framework for the
KDE-PIM [http://pim.kde.org/] 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.


 VI. 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.


VII. DECIBEL

     Tobias Hunger began his talk by explaining to us why he thought
Decibel [http://decibel.kde.org/] 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.


VIII. WEBKIT

     Lars Knoll held another talk on Saturday, this time about Webkit
within KDE. Lars started with a historic overview of KHTML
[http://www.khtml.info/]. 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.


 IX. 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.

 [http://static.kdenews.org/dannya/akademy_bindings.jpg]
     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!


  X. 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
[http://akademy2007.kde.org], 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 [http://akademy2007.kde.org], 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.