|
| 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 |
|
|
/trunk/KDE |
|
|
/trunk/l10n |
|
|
/trunk/www |
|
|
/branches/stable |
|
|
/branches/KDE |
|
|
/trunk/playground |
|
|
/branches/work |
|
|
/trunk/koffice |
|
|
/branches/koffice |
|
|
|
Lines
|
Developer
|
Commits
|
|
|
Eike Hein
|
|
|
|
Dirk Mueller
|
|
|
|
Jonathan Riddell
|
|
|
|
Renato Pavičić
|
|
|
|
Hamish Rodda
|
|
|
|
Stephan Kulow
|
|
|
|
Gilles Caulier
|
|
|
|
Rinse de Vries
|
|
|
|
Frans Englich
|
|
|
|
Helio Chissini de Castro
|
|
|
|
|
Internationalisation (i18n) Status
|
|
|
Bug Killers and Buzz |
|
Bug Killer
|
Number Of Bugs Closed
|
|
Dirk Stoecker
|
|
|
Luboš Luňák
|
|
|
Frank Osterfeld
|
|
|
Andreas Kling
|
|
|
Eike Hein
|
|
|
Martin Aumüller
|
|
|
Tommi Tervo
|
|
|
Gilles Caulier
|
|
|
Christophe Thommeret
|
|
|
Mark Kretschmann
|
|
|
|
Program |
Buzz |
|
Amarok |
|
3297 |
|
|
KDevelop |
|
|
SuperKaramba |
|
|
Kontact |
|
|
KMail |
|
|
Kopete |
|
|
K3B |
|
|
Kate |
|
|
Kicker |
|
|
digiKam |
|
|
|
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 |
 |
|
|
|
![[*]](/images/standard/other) |
|
Development Tools |
![[*]](/images/standard/bugfixes) |
![[*]](/images/standard/features) |
![[*]](/images/standard/optimise) |
|
|
|
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... |
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
|
|
|
|
|
Features |
|
|
|
|
|
|
