KDE Announces the 24 Google Projects

The KDE Project and Google announce the 24 KDE projects selected for the
"Summer of Code" project. The lucky students and the KDE e.V. will receive a
total of $120,000 if they can complete their projects in the allotted two

The accepted projects span accessibility work, improvements to the office and
personal information management suites, and innovations to KDE architecture.
Much anticipated projects include one addressing VoIP in KDE, and a unified
document viewer to handle multiple formats with a plugin architecture for third
party vendor extensions.

Twenty year old Piotr Szymanski, one of the selected students, said: "I am
really happy about developing this bounty. I worked on the KDE Polish
translation team for a couple of years, and now, whilst studying computer
science, I can get paid to create a much-needed free software application. I'm a
bit of a mix of a programmer, mathematician, artist and a philosopher, a kind of
renaissance guy.

Eva Brucherseifer of the KDE e.V. board added: "The selection process was
very difficult due to so many good applications. This is a great opportunity
for students to join the KDE community and to spend the summer on something that
will stay.

The full list of selected projects and students:

  1. Common scripting/plugin subsystem for Kontact - Kun Xi
  2. Framework and proof of concept of a write-time analysis of the value of a
    variable in C++ in the KDevelop UI
    - John Tapsell
  3. Fully integrated KDE NX Client - Christopher Cook
  4. To give Konqueror, the KDE Web Browser a complete XUL implementation - Philip Scott
  5. GTD (Getting Things Done) for Kontact - Rafał Rzepecki
  6. Implement support for OASIS XLIFF 1.1 in KBabel -
    Asgeir Frimannsson
  7. Implementation of HTML/CSS paged media in KHTML and Konqueror -
    Allan Sandfeld Jensen
  8. Improve computation engine of KSpread - Tomas Mecir
  9. Integration of VoIP/Video-Conferencing into Kontact/KDE - Malte Böhme
  10. Kamion — User State Migration Tool for KDE - Milan Mitrovic
  11. KDE Framework Addition: Distributed Application Markup Language -
    Iain Dooley
  12. KDE runtime observer: help to debug Qt/KDE applications by showing very easily runtime relations between objects: Signals, heritage, containment - David Moreno Montero
  13. KDE support for Eclipse - Oleksandr Dymo
  14. Label Browser: a new concept in desktop browsing - Ramakrishna.R
  15. Living KDE: an experimental idea of using Tag and search concept to
    organize user documents
    - Sachin Gupta
  16. A New Sidebar for Konqueror - John Doyle
  17. Nokey: an accessibility application designed to facilitate complete control of a computer using only the movement of the mouse pointer - Leo Spalteholz
  18. oKular - A powerful unified viewer application for KDE with a plugin system and backends for most popular formats - Piotr Szymanski
  19. PowerPoint import filter for KPresenter - Yolla Indria
  20. Speech recognition in KHotKeys - Olivier Goffart
  21. Spreadsheet Programming Interface for Sensor Networks -
    James Horey
  22. Visionary application - Project Knoware - Brian Beck
  23. Visual History for Konqueror - Dianfei Han
  24. Writing a KDE application not in C(++): onscreen keyboard utility written in the Java programming language and utilizing the KDE/Qt framework - Jack Lauritsen
Dot Categories: 


by Karl M. (not verified)

Now if these project will really be done in two month (which will happen i hope) kde will get a lot of really great improvements in a very short time.


I am looking forward to see this stuff on my desktop.

by Mathieu (not verified)

Now, I wonder what would happen if we could organize that 4 to 6 times a year ?
Productivity jump ?

by Thiago Macieira (not verified)

Well, it wouldn't be called "Summer of Code" anymore :-P

by David Walser (not verified)

For point #2, wouldn't it make more sense to add Qt/KDE code generation support to the Eclipse VE project than have Eclipse just externally launch Qt designer?

by Carsten Pfeiffer (not verified)

I for one quite dislike VE or SWT-Designer. Qt Designer so much more robust and easier to use.

I actually had thought something the other way round, using Qt Designer to create SWT code, e.g. via uic.sf.net.

by David Walser (not verified)

Well that would be fantastic as well.

by Thomas (not verified)

After reading through the project descriptions, I admit, I'm impressed by the amount and quality of ideas.

I'm looking forward to "GTD for Kontact" now ;-)
"Implement hyperlinkage between Kontact objects."
"Implement real attachments to KOrganizer items, as opposed to only storing URIs." - ...drool...

Good luck to all!


by emaN (not verified)


by Anonymous (not verified)


by Dmitry M. Shatrov (not verified)

We've made an attempt to create such. There are People are free to add new entries

it can be found at

or an older version:

by Giacomo (not verified)

many of these projects look like nice buzzwording, and won't deliver. Some verge on the useless:
Okular? Like we don't have already zillions of modularized viewers and players...
Writing a KDE application not in C++? ahem, Python bindings anyone?
Distributed Application Markup Language sounds like a .NET ripoff, with security scenarios so awful I don't want to even start thinking about it.
Label Browser is just the last fashion in The Quest For Perfect Metadata: people don't classify their stuff, but geeks simply won't give up the fight.
Knoware is a work that will require at least two years, not months...
Kamion is partly already implemented in KitchenSink (and please fix that first, it really needs some help)

Don't get me wrong: I hope everyone succeeds and I'm sure people will have fun trying; however, these submissions for the most part don't seem to be either realistic or original... the best ones are "coherent" progressive work on KOffice and Konqueror elements; it might as well be that the "visionary" ones have been chosen by the Google guys as a way of taking the piss with the submitters.

Anyway... good coding to everyone! :)

by James Richard Tyrer (not verified)

Writing a KDE application not in C++? ahem, Python bindings anyone?

Yes, but they are not an application.

Writing KDE apps in Java is an interesting idea. It would be even more interesting if the GNU Java compiler supported the current Sun Java implementation.

Specifically, if both were fully supported, we could use the Apache SVG code instead of writing out own.


by Brian Beck (not verified)


I submitted the Knoware proposal. Believe me, you aren't the only skeptical one.

But think about it: building a huge and useful database is the part that will take a while. This is not part of the proposal; that part is up to users. The proposal is for a project that will have the smarts to build and analyze the database. I'd say building a highly accurate spam filter is even a harder use of Bayes algorithms, would you say that takes two years?

Brian Beck
Adventurer of the First Order

by Kevin Krammer (not verified)

> Okular? Like we don't have already zillions of modularized viewers and players...

Well, the idea is based on suggestions of the KPDF/KGhostview developers if I remember correctly.
A viewer which combines all their features into one application is obviously not available yet.

> Writing a KDE application not in C++? ahem, Python bindings anyone?

Any bindings would have been OK. You have to let the students decide which one they want to write their application in.
My choice would have been Java as well.

> A viewer which combines all their features into one application is obviously not available yet.

Evince is available for Gnome

by Anonymous (not verified)


It even supports mail. Evince is probably comparable to Konqueror as far as being a generic shell interface.

by Kevin Krammer (not verified)
by Odysseus (not verified)

>Okular? Like we don't have already zillions of modularized viewers and players...

If you were to read the background, you would understand why. It's taking the existing brilliant kpdf frontend and turning it into a generic document viewer that can allow viewing of pdf, ps, chm, dvi, doc, kwd, sxc, ppt, whatever with a single interface for the users regardless of the document type. That is a DOCUMENT viewer with decent navigation and previews, etc, which is a very different beast to an image viewer. To me, it sure as hell beats the current situation where I need to learn 3 different interfaces to view my pdf, djvu and ppt files.


by superstoned (not verified)

I think it is a great idea to have a unified document vieuwer. kword etc embedded in konqueror isn't that great, as I always want to/try to edit documents in there... i already asked the dev's to make it r/w, but this is better - a real distinction between vieuwing and editing a document!

Hey Label browser is a cool idea. Why do u think only people will clasify stuff. I think this guy also has in his mind about applications classifying them. look at the proposal. It sounds great. If u are one of those who dont classify things then u are one of the very few who hate gmail.
Even the other projects are good. The thing is you havent gone through them properly.


by Me (not verified)

Don't 14 and 15 boil down to the same thing?

by James Richard Tyrer (not verified)

Some of this should be simple since most of the Konqueror (note that Konqueror is not a web browser) UI already has an XML interface that controls about 90% of the interface. I hope that someone is working on the other 10% :-)

However, the Firefox XUL user interface is not all good. Firefox does not support the FreeDesktop standard for icons (which KDE uses). I point out to P.S. that as a KDE app that Konqueror with a XUL based UI will need to continue to support the KDE/FD icon system rather than having the icons in JARs like Firefox.

So, he will have to solve the icon issue. When he does, this could also be ported to Firefox.

by Morty (not verified)

I don't think it's aimed at making it possible having XUL based UI for Konqueror, it sounds like it geared towards making Konqueror accept XUL based objects. Like plugins and such. Not making the UI of Konqueror in XUL, but making it possible to run XUL plugins, like the ones made for Firefox, native in Konqueror.

by Illissius (not verified)

As far as I know - and that's only peripherally - Firefox's XUL plugins are only possible /because/ the entire UI is written in XUL. So one follows from the other.
Rather, I think the goal is XUL in webpages, but I'm not the one doing it so obviously can't say with certainty =).

by Peter (not verified)

my proposal "Haskell Bindings for KDE" was denied. But I'm not complaining about it, I suppose the developers did their best deciding what's needed.

by Antonio (not verified)

Just because you're not getting paid, doesn't mean you can't do it :-)

I'm just sayin...

by Peter (not verified)

I know, and I'm planning to do so, but it will take a lot longer since I'm forced to work on something else (far less interesting) that pays the bills in the mean time...
Maybe I will be on time for KDE 4 ;-)

by Giacomo (not verified)

I wonder why you didn't propose Prolog bindings... now *that* is interesting!

by ltmon (not verified)

I can imagine it now....

You start a KDE application, and after waiting for 30 seconds a single dialogue box appears:



by superstoned (not verified)


by Scott Wheeler (not verified)

Well, just notice that we basically have no applications written in Java (or any of the other languages for which we have bindings with the arguable exception of Python) though we've had Java bindings for a while. And a lot of people know Java. Haskell honestly just be an exercise in generating bindings, not something that would be actively used for application development.

by gerd (not verified)

#10 sounds very good. It is an important usability task where most De fail

by ac (not verified)

Frome what I hear NX is great, lightning fast compared when compared to VNC and X11 but in the long run doesn't it make more sense to fix the X11 client/server protocol? I understand that this would be a massive undertaking not only from a technical standpoint (creating a new protocol) but also from a political standpoint (reaching a consensus on how the new standard would look and work).

Now I'd like to say that I'm not one of those guys that says we need X12 because X11 has been arrond since September 15, 1987. If it ain't broke don't fix it. The thing is we've learned a lot since '87, we have more processing power (compression costs less) and our usage paterns have evolved. Do you remember computing in '87?

by ltmon (not verified)

The most successful standards often don't come from a commitee designing them, but from one individual effort that is so good or popular that everyone else copies it.

With the core of NX being free, if it proves worth it's hype and a lot of people start using it, it could quite easily become part of "X12" without having to design by commitee or rub a whole lot of people the wrong way.


by NS (not verified)

Congratulations for KDE team for posting the result approved projects with title and details, in summer of code first!!!

We know that there are lot of projects approved in SoC for open source communities, yet some of the communities has less priority in posting what projects approved and details.

This only shows that KDE.org is truly for all of us, not just for developer but users as well.

Long live python plugin, as a scripting for KDE.

Well done! KDE Team.

by Michael (not verified)

If you want to be petty, NetBSD announced theirs last week http://www.netbsd.org/Foundation/press/soc.html.

by NS (not verified)

Sorry, probably, I am BSD is part of my vocabulary, I am into linux and more interested in applications in general.

Thanks for your correction and link.

Any other announcements in SoC Results? Topics and detailed description


by NS (not verified)

Python Software Foundation (PSF) got one now:-)


by Davide Ferrari (not verified)

There are LOT of interesting project, but if Knoware will be complete and functional it will be one of the more interesting!

by Brian Beck (not verified)

Thanks for showing interest! I'm keeping a development blog here: http://blog.case.edu/bmb12

Brian Beck
Adventurer of the First Order


Go Kontact, go!

by Mario Fux (not verified)

If could for the Tenor (the new KDE linkage technology) exists would it be valuable for the projects #14 and #15.

I'm really curious about Tenor but heart nothing about it for some time now.
Does anybody knows more about its status?

by Thiago Macieira (not verified)

Tenor won't be delivered in time for the students' work. So using it could be very difficult for them.

Not that some of them haven't suggested using it -- quite to the contrary.

by superstoned (not verified)

but maybe he can help writing it, at least outline some things it needs to do...

by Timur (not verified)

It is just a very short whish list... it would be really great if KDE/Google:

- create a KDE/Linux client for Google Earth (and maybe integrate it with GPSDrive)
- create a KDE/Linux client for Google movies

just my .02 cents


by superstoned (not verified)

well, google maps should be doable, as google has released the API. maybe the same will go for Google movies, as DVD John aparently already cracked it :D

but i'm sure it'll take some time.

by ra1n (not verified)

well the latter should be easy since google posted the code of their work on VLC:

by hannes hauswedell (not verified)

man, they rejected the windoze port of kdevelop... i kinda doubt it would have been accomplished in the time, but it sure sounded good...
then again if kde4 is supposed to be ported alltogether, we will hopefully get kdevelop to win-platforms

by Aivars (not verified)

In a world filled with so much bullshit that we still have noble projects such as this. Free for all to use and done purely in the spirit of innovation and furthering of knowledge.


by Rory (not verified)

"Free for all to use and done purely in the spirit of innovation and furthering of knowledge"


- Notoriety
- Bragging rights
- Cash payout
- Future consulting gigs
- Etc.

I wouldn't say that it's "done purely in the spirit of innovation and furthering of knowledge."

Especially since:

1) There is *very* little innovation here ("innovation" is a word that's been tossed around so much that it's practically lost its meaning)

2) This isn't so much about furthering knowledge - there are plenty of good coders out there who could implement many of the features listed - it's a question of time and resources rather than ability, so I see little that contributes to "furthering of knowledge" except perhaps for the coders directly involved

Hate to sound like a cynic, but someone has to keep his head on straight around here...