URL: http://dot.kde.org/118
3388210/
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/118
3385741/] 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.se
manticdesktop.org/] and Strigi
[http://strigi.sourcefo
rge.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/akonad
i/] 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.
_______________________________________________
dot-stories mailing list
dot-storieskde.org
htt
ps://mail.kde.org/mailman/listinfo/dot-stories
|
