prev
Issue 21
27th August 2006
by Danny Allen
next


This Week...
As the Summer Of Code draws to a close, a mass code import in the Physiks project, and other notable commits for several of the other affiliated projects. Work begins on a Kexi importer for KSpread. Numerous improvements for displaying data in Forms and Table View in Kexi, including support for default values and tooltips for large content. Lots of work on the Kross scripting framework. Improved functionality in Konversation and KFTPGrabber. Speed and memory optimisations in KDevelop and Filelight. An experimintal project begins to integrate the Orca Screen Reader into KDE 4 using D-Bus.

This week saw the conclusion of the Summer Of Code initiative - I chased down some of the projects to catch up on their progress.

Allan Sandfeld Jensen briefly covered his project, avKode, a backend utilising FFMPEG for the Phonon multimedia framework:
The basic idea of avKode was to get a good basic media backend for phonon. I originally looked at Xinelib and GStreamer, but I didn't like either of them.

The problem is that big libraries like GStreamer or Xine reimplement a lot of stuff we already handle in Qt or KDE, object management, IO-slaves, threading etc.

My hope with avKode was that when combining a powerfull decoding library like FFMPEG with the powers of KDE and Qt there wouldn't be much code missing to get a good decent media backend. I've implemented a QWidget for XVideo output, an audio-video synchronization class, a KIO stream wrapper and a FFMPEG decoder wrapper. This is really all that was needed. But there have been some ugly things as well.

The hardest part has been fixing and working around bugs in FFMPEG. The timings FFMPEG reports varies from always 0 to mostly bogus, and length of MPEG files is always reported as being 40ms; just to mention a few huge FFMPEG bugs. Fixing or working around this stuff is really duplicating work already done in the other libraries, and I am really hoping I will soon have most of the major problems nailed, otherwise avkode might turn out to have been a less good idea.

Fortunately the other part of my SoC project, implementing random KIO access, seems to be working fine and have already been commited to trunk.

Sheldon Cumming describes his project Sleek, a new way to visualise information:
The goal of the project is to change how people view calendaring information. A related, more ambitious objective is to change how people view all temporal information, such as timezones, estimated times, creation dates and usage statistics.

I think it's important because I'm especially bored of using full-screen calendaring applications. They pretend to be like a calendar on your desk, but aren't really as they aren't as static (unless you have a second display and leave Kontact or something maximized). In my experience, people in offices would either have their calendar memorized anyways, or be at the mercy of reminder dialogs, which may appear after the subject had left to go get coffee :)

My answer is to have this information, which is exceptionally important, to be always visible while allowing the person give as much focus to the job they should be doing. Then I could probably take down the huge whiteboard calendar I have on my wall.

In practice this appears as a nifty linear clock on any edge of your screen. Very simple, yet different and full of information. You may find you view your day differently as it makes you acutely aware of how much of it is gone already ;)

It doesn't aspire to replace KOrganizer, as KOrganizer is always going to be better at a lot of things. The aim is to complement its capabilities.

The stuff in SVN is kind of old, and after talking to many people about the things it does I'm going to be changing a lot of stuff in the near future.

Here is a mockup of some projected capabilities, and an actual screenshot of the Sleek bar in use - i've been experimenting with different things to make the visuals match the name.

These are only a few of the exciting and interesting projects completed for the Summer Of Code, with many projects making terminal commits this week. Of course, we now have the Season Of KDE projects to look forward to... Good times!

Tobias Hunger, a key developer of the Decibel communications framework, one of the pillars of KDE 4, explains the project in detail:
Let's start with the current progress:

I started coding, but there is nothing worth showing yet. Most of my time is currently spent in discussions with the tapioca (which nowadays implements the telepathy spec, which I consider to be great news!) and telepathy people. There are still some areas that are somewhat hazy to me (or just not properly spec'd out ;-). The existing tapioca Qt4 bindings are mostly defunct, so that is another area that I need to spend more time on than originally estimated.

Near term goals:

Give a presentation about decibel at Akademy in Dublin and have a somewhat-working prototype of Houston, the platform-independent part of Decibel, by then. I am not yet sure whether I'll really make it, but I have high hopes.

Long term goals:

To provide a framework that makes integration of communication and collaboration features into applications as easy as possible. Wow, that is a sentence full of buzzwords, but I do not know how to explain it better ;-)

Basically I'd love to see things like whiteboards that are accessible form many applications so that people can share ideas over the network.  Simpler things like better integration of real time communication features into existing applications.

Think about better integration of your real time communication mechanisms into existing applications. Having real-time communication integrated into your mail client springs to mind here: In your list of received mails there could be an icon representing the presence state of the mail senders on networks like ICQ, Jabber or whatever and you can start a chat session with them with one click.

We would like to simplify the way accounts on real-time communication services are handled. A user wants to do things like "chat with my friend X". This does not include subtasks like figuring out which of the installed programs can actually speak the protocol used by the service X frequents, etc. What we envision is that the user selects a contact to talk to (or chat with or video-stream to) and then Houston selects a protocol to use, helps the user with creating an account on the service (if required), puts the user online on the service and fires up the preferred application to handle the protocol used.

What it will bring to the developers:

Not having to worry about the low level details of real-time communications, thus reducing the number of lines of code to integrate features based on that technology into their code.

We strive to provide a framework that people can connect to over D-Bus, implementing only those components that they need to implement to set them apart from their competitors while relying on those provided by Decibel for the rest of them. The Telepathy spec at freedesktop.org already reaches that goal for the low level components of the framework (the Connection Managers that implement the wire protocols, etc.), but there is no framework yet for high level components like chat windows, VOIP dial windows, etc. to plug into Decibel will provide that.

What it will bring to the users:

We hope it will bring better integration of communication and collaboration features into applications :-)

Besides that we hope to improve on the stability of real-time communication software by subdividing the functionality in easy to test parts that communicate over D-Bus. D-Bus isolates the different parts of the system from each other. If for example the IRC Connection Manager dies then the rest of the application will be notified of that event, but the ICQ and SIP streams handled by the same application will not get interrupted.

Then we want to allow the user to centrally manage his communication settings and accounts. This allows him to do things like set his presence information to "away" for all his accounts on all the communications networks he uses.

Keeping with the new technology theme comes a short explanation from lead developer Scott Wheeler regarding the progress of Tenor, an ambitious experiment in contextual linkage.
At my current job I'm doing cross-platform pro-audio stuff, which also has nothing to do with KDE, but for the moment I rather enjoy.

Sponsorship for my KDE work has never been something that I've sought. KDE is one of my hobbies and I'm fine with it staying that way. (Not to mention that I have to have normal full-time employment to remain in Germany where I've been for several years.)

So, then what's with Tenor?

Like I said above, KDE is my hobby. Sometimes I feel like working on it, sometimes I don't. (My life has also been really busy in the last few months, but really it's more of a matter of motivation than time.) When I don't feel like working on it, I don't. It's really that simple.

The desire to work on Tenor for me comes in waves. A couple months back I spent a few weeks hacking on it again. I haven't touched it since then.

So, will Tenor be in KDE 4?

Maybe. Really it depends on if and when I feel like hacking on it or if someone else decides to pick it up and run with it. Think of it as a surprise. ;)


Statistics
Commits: 2813 by 224 developers, 6435 lines modified, 2445 new files.
Open Bugs: 13094
Open Wishes: 11498
Bugs Opened: 304 in the last 7 days.
Bugs Closed: 291 in the last 7 days.

Commit Summary
Module Commits
/trunk/extragear
491
/trunk/KDE
461
/trunk/l10n
442
/trunk/www
335
/branches/stable
264
/branches/KDE
171
/trunk/playground
168
/branches/work
161
/trunk/koffice
80
/branches/koffice
61
Lines Developer Commits
360
Eike Hein
122
187
Dirk Mueller
87
86
Jonathan Riddell
81
71
Renato Pavičić
70
324
Hamish Rodda
62
114
Stephan Kulow
60
132
Gilles Caulier
59
58
Rinse de Vries
52
136
Frans Englich
47
42
Helio Chissini de Castro
42

Internationalisation (i18n) Status
Language Percentage Complete
Swedish
99.94%
Portuguese
99.73%
Danish
98.75%
Spanish
97.17%
Dutch
97.16%
Italian
93.84%
Estonian
93.48%
French
93.01%
Greek
92.99%
German
92.14%

Bug Killers and Buzz
Bug Killer Number Of Bugs Closed
Dirk Stoecker
34
Luboš Luňák
34
Frank Osterfeld
31
Andreas Kling
27
Eike Hein
22
Martin Aumüller
19
Tommi Tervo
18
Gilles Caulier
16
Christophe Thommeret
14
Mark Kretschmann
13

Program Buzz
Amarok
  3297
KDevelop
  713
SuperKaramba
  709
Kontact
  708
KMail
  704
Kopete
  701
K3B
  693
Kate
  684
Kicker
  612
digiKam
  469


Person Buzz
Aaron Seigo
  293
Scott Wheeler
  256
Waldo Bastian
  242
Tom Chance
  242
David Faure
  238
Kurt Pfeifle
  233
Jonathan Riddell
  223
Boudewijn Rempt
  216
George Staikos
  202
Anne-Marie Mahfouf
  192
Contents
  Bug Fixes Features Optimise Security Other
Accessibility [*]
Development Tools [*] [*] [*]
Educational [*]
Graphics [*]
KDE-Base [*] [*] [*]
KDE-PIM [*] [*]
Office [*] [*] [*] [*]
Konqueror
Multimedia [*] [*] [*]
Networking Tools [*] [*]
User Interface [*]
Utilities [*] [*] [*]
Games
Other [*]


Bug Fixes
Development Tools
Hamish Rodda committed changes in /trunk/KDE/kdevelop:
More stability - this time, allow the user to close a project and/or
kdevelop while background parsing is progressing.

Add mutexes to KDevLanguageSupport which can be locked to protect
language support resources while processing continues. This is a
per-thread mutex because otherwise all the background threads sit around
while one executes (which kind of defeats the point).

Extend abort + lock support to c# and java parse jobs.

Lock the smart interface mutex before it is deleted (thus preventing the
editor from disappearing)

Instead of dequeueing pending jobs (which doesn't give you a definitive
dequeued signal... yet?), abort them all. Not 100% right because the
progress bar gets stuck.

Fix the smart interface in the editor integrator so that
1) the smart interface doesn't suddenly appear while parsing
2) the lookup doesn't have to happen all the time.

Remove queue policies from jobs which haven't executed. This is in an
attempt to stop access to deleted policies in job destructors.. Didn't
work initally, but might actually be working now (will have to test).
For the moment the policy deletion is commented out.

Add projectClosing() signal to KDevProjectManager, so that you can do
stuff before the project has closed.

Maybe now I can get back to some features...
Diffs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 (+ 10 more) Revision 576211

Dirk Mueller committed a change to /branches/work/icecream-make-it-cool/daemon/main.cpp:
finally fixed the daemon crash we had all the time in Trysil
Diff Revision 577223

Multimedia
Ian Monroe committed changes in /trunk/extragear/multimedia/amarok:
*Mongrel now builds. So now Amarok has a DAAP server that works with Banshee
and Amarok. iTunes support is in the works (holding off ChangeLog entry until
so).
*Re-enabled Zeroconf. Still need to fix the segfault.
Diffs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Revision 575671

Office
Bart Coppens committed a change to /branches/koffice/1.6/koffice/krita/ui/kis_custom_image_widget.:
Obey the transparancy setting in the custom image dialog. Note that it changes the opacity of the initial layer, not the fill color of it (just like it used to do before, iirc).
Bug 132692: Opacity slider in template dialog has no effect
Diff Revision 574937

Utilities
Max Howell committed a change to /trunk/extragear/utils/filelight/src/part/radialMap/map.cpp:
Maybe fixes this crash on startup. I can't reproduce so I can't be sure.
RC2 will be released tomorrow or today if I have time.
Bug 132679: filelight crashes freeing invalid pointer
Diff Revision 575695

Features
Development Tools
David Nolden committed changes in /branches/work/kdevelop-teamwork.kdevelop:
Make forward-sessions work again, make the user-icons for them consistent, add user-management to the file-collaboration-sessions(using the tree-view), more debugging..
Diffs: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 (+ 22 more) Revision 574781

Jakob Petsovits committed changes in /trunk/KDE/kdevelop/languages/csharp/parser:
Support for variables in the C# binder.
Diffs: 1, 2, 3, 4, 5 Revision 575592

Jakob Petsovits committed changes in /trunk/KDE/kdevelop/languages/csharp/parser: