Google's Summer of Code 2006 Opens with KDE

Google's Summer of Code has opened for student applications, and KDE is again seeking students to mentor over the holidays. Our ideas page lists some of the projects you could work on, or you are encouraged to come up with your own. Last year we had 24 students working on KDE projects, one of the highest numbers of any project and gained important projects like Okular. For more information see the student FAQ and participant signup page. Update: be quick, the deadline is midnight UTC ending next Monday 8th May.


All these project proposal sound like something which will get done anyway. Why not something kool, I mean

Integration stuff:
* kpdf plugin for Firefox
* KControl module for Wine
* KDe dialogues in GTK apps
* VBA implementation (cmp. OpenOffice)
* Tutorial for KDE programming with Python
* KDE Java backends
* QT rendering for Firefox
* Windows data integration for dual-booters (MyMusic, MyFiles)
* bibtex engine for KWord
* latex2odf converter
* dictionary tool with wiktionary integration

* Usage Talkback compiles (applications which report and analyse how they are used)
* Podcast "production" tool
* Torrent-based Podcasting
* Screen recording
* vcard tool
* KDE Membership and finance management tool for associations
* usability in KDE security
* KDE user database / user map (cmp. gnome and debian developer map)
* webbased translation tool
* KDE presenter templates
* KDE R Frontend
* Knights extentions and integration
* uxtheme conversion tool

By gerd at Tue, 2006/05/02 - 5:00am

What about one or two good crisp fonts like Microsoft's Tahoma, Times New Roman or Courier? KDE could default to one of those. On the Windows platform, these fonts are clear, sharp and crisp. On Linux however, I find them blurry and not a pleasure to look at. To put it better, we need a better font management/rendering paradigm on Linux. Question is: Do you agree?

By cb at Tue, 2006/05/02 - 5:00am

Font rendering is pretty great if you run a distro that sets it up right (or you can do it yourself). With KDE4, that'll improve even further, I hear. You might want to check out the DejaVu font (family?), which is Bitstream Vera with wider support for unicode.

By Lee at Tue, 2006/05/02 - 5:00am

I read a while ago, they are doing something for GTK, with would include make fonts go way beyond what windows offers. Would be nice if that would work for KDE too...

By boemer at Tue, 2006/05/02 - 5:00am

Ah... I've been using the Veras since they came out. I had wondered about DejaVu. I noticed they seemed to be the same.

By Evan "JabberWok... at Wed, 2006/05/03 - 5:00am

DejaVu is based on Vera, but contains glyphs for all the Latin scripts, Greek, Cyrillic, Armenian and partially Arabic scripts. It also covers (or plans to cover) mathematical symbols. The Serif variant has some proper italic characters, instead of oblique. If you only need Latin characters, you may stick with Vera, I suppose, but I find the extended glyph coverage handy, say, to browse wikipedia, where the need of greek letters is often needed.

By Luciano at Wed, 2006/05/03 - 5:00am

There is some activity around DejaVu font family. It borrowed the base from the Bitstream Vera fonts (which lacks many non-latin chars). The latest DejaVu fonts are very good, provide Arial-like, Times-like, and Courier-like fonts and are shipped, at least, with latest OpenSuse.

A lot of effort goes into making that family THE FONT family for open source desktop.

By Daniel "Suslik" D. at Tue, 2006/05/02 - 5:00am

Fonts can look *far* better on Linux than on Windows XP. Very similar to Mac-OS in fact.

Maybe some distributions do not have the correct font configuration out of the box.

By Meneer Dik at Tue, 2006/05/02 - 5:00am

This is so true and so little known!
People complaining about fonts on Linux, READ THIS:
Open the KDE control panel and go to the Fonts settings. Click on the "Configure..." button. In the "Hinting style" combo choose "None". The setting will take effect only on newly started applications.
Now you should have a nicely smoothed Vera or DejaVu font. If you still don't like it get a different font.
In the attachment, KDE using the default OSX font, Lucida Grande.

By Flavio at Wed, 2006/05/03 - 5:00am

Or you can use fonts that haven't got broken hinting and get beautyfull fonts like Windows or OSX by enabling font-hinting.

By carewolf at Wed, 2006/05/03 - 5:00am

I think the problem is that good fonts and/or font settings are not included *by default* in KDE. In other words, if I were to grab an SVN snapshot and build it, it would not have the best fonts.

Someone with SVN access should take a couple of hours and ensure that the KDE default fonts are indeed the very best free fonts available.

By ac at Wed, 2006/05/03 - 5:00am

Times is no font suitable. Times was developed for English newspapers. It was a mistake to use the font for computing from a font development perspective.

By humhum at Tue, 2006/05/02 - 5:00am

Then we need a good serif font to replace it.

By James Richard Tyrer at Wed, 2006/05/03 - 5:00am

> Then we need a good serif font to replace it.
Gentium, Charis SIL or DejaVu Serif are pretty good hinted serif fonts.

By Moyogo at Wed, 2006/05/03 - 5:00am

i agree 100% the fonts in KDE are not pleasing to look at for the most part and MS fonts look much better. it would also be good to have times new roman for writing papers, documents, etc. for people who don't know anything outside of MS

By puter at Fri, 2007/07/27 - 5:00am

The wiki is editable by anyone -- why don't you add those ideas yourself?

By ac at Tue, 2006/05/02 - 5:00am

KDE Membership and Finance Management Tool?

I guess that would mean... if they're not actively involved in the KDE community, they don't get paid? ;)

By Lee at Tue, 2006/05/02 - 5:00am

Vereinsverwaltung - Association management tool probably

By humhum at Tue, 2006/05/02 - 5:00am

> * kpdf plugin for Firefox

Not a KDE project. KPDF works fine in Konqueror. And I think there is a plugin for Firefox to load KParts. It's up to them to make use of it.

> * KControl module for Wine

Good idea, but could be rather limited for a full project.

> * KDe dialogues in GTK apps

I do not understand. Besides, our goal is to make KDE applications better, not GTK apps.

> * VBA implementation (cmp. OpenOffice)

I'd much rather see JavaScript in the KOffice suite. The project to implement VBA would be too big for Summer of Code.

> * Tutorial for KDE programming with Python

Summer of Code must produce Code.

> * KDE Java backends

Those already exist.

> * QT rendering for Firefox

Not a KDE project. It would be a Mozilla project.

> * Windows data integration for dual-booters (MyMusic, MyFiles)

Looks too simple for a Summer of Code project.

> * bibtex engine for KWord

Good idea.

> * latex2odf converter

Good idea, probably coupled with the last one.

> * dictionary tool with wiktionary integration

I think this has been discussed and deemed impractical.

> * Usage Talkback compiles (applications which report and analyse how they are used)

Good idea, but this is suggested again and again. Implementing this is a good idea, but who is going to read the data that it produces? Please figure that out first before implementing this.

> * Podcast "production" tool
> * Torrent-based Podcasting

I don't understand these.

> * Screen recording

Good idea, probably requires some deep X knowledge. Would also present some interesting problems regarding event compression.

Note: there are some commercial tools that do that in KDE.

> * vcard tool

Huh? That's too vague.

> * KDE Membership and finance management tool for associations

Could be... but its usage would be so limited I'd rather see SOC money used for other things.

> * usability in KDE security

You'd need to elaborate.

> * KDE user database / user map (cmp. gnome and debian developer map)

We already have the contributor map.

> * webbased translation tool

Not a KDE project.

> * KDE presenter templates

Summer of Code must produce Code.

> * KDE R Frontend

What's R?

> * Knights extentions and integration

What's Knights?

> * uxtheme conversion tool

What's uxtheme?

By Thiago Macieira at Tue, 2006/05/02 - 5:00am

Given who you are in the KDE community, I am quite surprised that you are so unfamiliar with the items in this list as you are.

By Mineri Devangu at Wed, 2006/05/03 - 5:00am

Huh? Really no need to bring this on a personal level. If you have something to say about the listed items then please do so, but abstain from attacking persons. Thanks.

By Marco K at Wed, 2006/05/03 - 5:00am

There is a difference between ad hominems and just pointing out something as such.

By Jui Kai at Wed, 2006/05/03 - 5:00am

A lot of those items he was "unfamiliar with" don't really seem connected to KDE.

"R" is statistics, nothing to do with KDE. Knights appears to be a chess program unaffiliated with the KDE Project. uxtheme seems to be a Windows XP thing. Podcasting has never been particularly popular in the OSS community. Maybe those things would be useful in KDE, but I wouldn't be surprised if 90% of the KDE community doesn't care about any of them.

So, yeah, what the heck are you talking about?

By EY at Wed, 2006/05/03 - 5:00am

It's called rkward ( Still a little unstable, but usable.

By Luca Beltrame at Wed, 2006/05/03 - 5:00am
A statistical power house for professionals, though without GUI, so no SPSS replacement for social scientists. There is a project I think

Knights is the best and stable chess program for KDE but discontinued. Hope it will get ported to 4.

uxtheme -- I think Frank Richter did something in the Wine project,
conversion of Win-themes to KDE themes probably or theme bridge, quite a lot win-themes out there.

Podcasting is like Ruby, it wins. It is no big issue in the KDE community because existing tools suck. Try iTunes on your Mac. Podcasting == audio blogging. Very simple from a technology perspective: mp3/pdf/ogg etc. + special RSS format

E.g. German chaosradio podcast

or O'Reilly Oscon05 talks

BBC offers nice podcasts

daily language courses etc.

or see

torrent-podcasts Oh well, this breaks the only real weakness of podcasting and will be required for videopodcasts. which means when you offer an mp3 of 10 megabyte and you get 10 000 subscribers its 100 GB for you as a provider of these services. The same applies when you file is 110 MB, so torrents like protocols would save bandwidth and the first tool which implements it wins.

By Gerd at Wed, 2006/05/03 - 5:00am

About the KDE dialogs in GTK programs:
I think that this would be a huge improvement for KDE as well as for GTK programs. GTK programs will look much more like KDE programs with that simple addition. If we do this with GTK-QT, we may be able to have (almost) full integration between GTK apps and KDE.

By Alex Lowe at Wed, 2006/05/03 - 5:00am

Integration between GTK apps and KDE will occur when Gtk apps support kisolaves. In fact, a KDE dialog maybe unusable if the Gtk app can't access to the floppy or Cdrom by kioslaves (they are what KDE dialog shows).

By Iñaki Baz Castillo at Wed, 2006/05/03 - 5:00am

Integration between GTK apps and KDE will occur when Gtk apps support kisolaves. In fact, a KDE dialog maybe unusable if the Gtk app can't access to the floppy or Cdrom by kioslaves (they are what KDE dialog shows).

By Iñaki Baz Castillo at Wed, 2006/05/03 - 5:00am

>About the KDE dialogs in GTK programs:

I really can't see the reason for all this facination with intergrating GTK+ applications flawlessly in KDE. If you absolutly need to run a GTK+ application, the GTK-Qt theme makes it look less out of place. If you want thighter intergration perhaps it's time the GTK camp do something for intergration too.

All told the sugestion of using KDE dialogs in GTK+ are nothing but lots of work for very little gain. As I see it, next to no GTK+ application exist which does not have a KDE eqvivalent beeing just as good or even better. I guess the only exceptions are Incsacpe and Kino. And I think making Karbon as good as Incscape are less hard and difficult work, than making GTK+ applications use KDE dialogs in a stable manner(and keeping it in sync with changes in GTK+). Basicly it's a question of using the development resources wisely.

By Morty at Thu, 2006/05/04 - 5:00am

R is a statistics program

It would also be great to have very good frontends for other open source math programs like maxima, yacas and octave.

By JA at Wed, 2006/05/03 - 5:00am

> > * VBA implementation (cmp. OpenOffice)
> I'd much rather see JavaScript in the KOffice suite. The project to implement VBA would be too big for Summer of Code.

KOffice has a framework for scripting languages (called kross) that allow exporting the same API to any potential script language (currently it only supports python and ruby, but JavaScript would probably be a two days work at most), but only Krita and Kexi use it currently. Some work has been made to have it integrate in KSpread.

As for VBA, well : 1) it would be pretty easy to add support for basic interpreter (like gambas for instance) 2) the VBA's API has a lot of problem (bloat, unstability, etc...) which we want to avoid in KOffice.

But we would welcome anyone willing to write the kross binding to KWord, KPresenter and add more functions to the KSpread one.

By Cyrille Berger at Wed, 2006/05/03 - 5:00am

> * KDe dialogues in GTK apps

It's just the file dialog, but take a look at

I've tried it in Firefox, and it does seem to work.

By Dhraakellian at Tue, 2006/05/02 - 5:00am

KPDF plugin for Firefox: Interesting idea but not general enough. How about a NSPlugin for all KParts that work in Konqueror.

KDe dialogues in GTK apps: Would QTK+ be too much of a kludge?

QT rendering for Firefox: this is in the source tree but it is still alpha.

Windows data integration for dual-booters: We have that, but it ONLY works for KDE apps. This is only a bug that needs fixing.

And my ideas,

XDG integration of icon theme selection and widget themes. IIUC we are going to have MIME types in KDE-4 but someone could backport it to 3.6.

A SMIL authoring tool.

Google heal thyself. Google needs to have everything it puts on the web be 100% W3C & ECMA compliant. Note that this works both ways. If they can't do everything that they want to with existing W3C stuff then they can contribute to the W3C standards.

By James Richard Tyrer at Wed, 2006/05/03 - 5:00am

I think there already is an NSPlugin that loads KParts. I remember seeing this more than once appear in because Konqueror loaded the nsplugins KPart, which runs nspluginviewer, embeds it and then loads the NSPlugin that loads the target KPart (KGhostviewPart). I've seen it because it crashed.

Of course, it's completely unnecessary to load nspluginviewer to load a KPart, since Konqueror can display a KPart directly. But Firefox could use it. I'm not sure if it would be a KDE or Mozilla SOC project though.

By Thiago Macieira at Wed, 2006/05/03 - 5:00am

The other way around it makes sense:

The Konqueror blocked popup notice is as fat, misplaced and therefore annoying as a propup -> make it like Firefox (small and near to the url bar). Same for the seamless find function os Firefox.

The ad blocking functionality doesn't compare to Firefox plugins (adblock plus, rip) and is not reachable from the popupmenu. The current solution is (and that only for single box installations) as good as a proxy with filtering capabilities.

The bookmark system is very dated - no live bookmarks, no keywords, no engine that creates backups of sites as requested, tests for unreachable sites and informs the user after a specified number of tries/weeks about the dead bookmarks.

Making the popupmenu configureable by the user would be a huge improvement.

That would be Konqueror usability improvements. Rendering is fine both with Gecko and KHTML, but I don't know a reason to use Firefox with KHTML under the hood.

By Carlo at Wed, 2006/05/03 - 5:00am

There are many interesting and cool projects are on last years list, full NX integration, speech recognition, oKular, VoIP and Video Conference support for Kontact, ... But since last years SoC ended I never heard of these projects anymore.

What happend to them?

It looks like a general problem with these Summer of Code projects. Most of them remain in that state the student left them forever.

By furanku at Tue, 2006/05/02 - 5:00am

Very true. Hard to get excited about anything this year when there are few visible results from last year. It might be a good idea to pick up some of the stuff that was left undone. Getting things done a bit at a time each summer isn't totally ideal, but perhaps better than letting things rot. If it was a good idea last summer, I daresay it still is.

By jason at Wed, 2006/05/03 - 5:00am

full NX integration never got off the ground. The student had to abandon the project very early.

Speech recognition was finished and merged into KDE (KHotKeys). oKular is still in development. KCall also is there already, but hasn't seen much attention since the end of last year's SOC.

The one project I'd particularly like to see picked up is Kamion.

By Thiago Macieira at Wed, 2006/05/03 - 5:00am

My own project was variable analysis in kdevelop. I did what I said I would, but that's maybe 10% of the work needed.
At the moment I'm putting all my kde time into ksysguard instead. It is nice to be able to play with the more fun things, but there are far more urgent things to fix in kde first ;-(

By John Tapsell at Fri, 2006/05/05 - 5:00am

1.) True autocompletion support for Python in KDevelop.
2.) True WYSIWYG print output, particularly with respect to fonts. (If you don't believe me, do some serious looking in Bugzilla; and you will see the complaints.)
3.) More DCOP interfaces.
4.) Font DPI parity between GNOME and KDE. (Why is it that the same fonts, at supposedly the same size, render differently in KDE and GNOME. Gtk+/GNOME applications can look terrible when started in KDE without gnome-settings-daemon?)
5.) Full Esperanto localization. ;-)

By Robert de Gaulle at Tue, 2006/05/02 - 5:00am

> True autocompletion support for Python in KDevelop
100% correct autocompletion for dynamic typed languages is not possible.
But for most cases good guess can be made.

Do you want to pick up this project? Just send a mail to [email protected] (subscribers only) and you'll surely find a mentor.

By Alexander Dymo at Wed, 2006/05/03 - 5:00am

"True autocompletion support for Python in KDevelop
100% correct autocompletion for dynamic typed languages is not possible.
But for most cases good guess can be made."

Yes, it's true you can't do it statically just by parsing the source of the program. But you can do it dynamically while the program is running using python or ruby introspection.

So when you're using Ruby's irb shell it has code completion because it's interacting with running code. If it was possible to provide a graphic front end for irb or python, so you could develop code as it was running like a Smalltalk environment, that would be a killer application. But unfortunately it would probably be too ambitious for a SOC project.

By Richard Dale at Wed, 2006/05/03 - 5:00am

We can't get DPI parity between GNOME and KDE. The bug is in GNOME incorrectly handling and changing DPI in X11, but the bug has been closed as WONTFIX, since it only bothers KDE that they mistreat the standard.

By carewolf at Wed, 2006/05/03 - 5:00am

I haven't had any luck finding this in the bugzilla database. Could you please provide a link to it, as I would be very interested in reading about it?

By Robert de Gaulle at Wed, 2006/05/03 - 5:00am


Windows is totally broken in this. Regardless of your actual screen size, it sets the resolution to 96 DPI.

Monitor manufacturers very often write wrong dimension information in their devices' EDID data. This means the monitor size is often incorrectly detected.

X detects the size automatically and calculates the DPI correctly (if the monitor EDID was correct). You can override the values if they are incorrect.

KDE and Qt-only applications make use of the DPI to translate the font size from points to pixels. Remember that 72pt = 1 inch. So, at 96 dpi, a 72pt font should be 96 pixels high.

Many web designers are careless and write webpages that assume the text size is constant. This is obviously bogus (think of accessibility for an instant!), so the page layout completely breaks if your dimension doesn't match 96 DPI.

KHTML enforces a minimum of 96 DPI by scaling the fonts if the monitor settings are < 96 dpi. This is only done so that webpages are shown reasonably correct.

GNOME couldn't care less what the monitor size is and follows on the Windows footsteps. But it does much worse and SETS the X configuration to 96 dpi. This causes the weird behaviour of KDE applications changing font sizes after you start some GNOME applications.

Both sides say it's WONTFIX. We're in deadlock.

By Thiago Macieira at Wed, 2006/05/03 - 5:00am

0) The Twinkle SIP client is already pretty incredible, but it needs some usability love. Work on it so that it can become the standard VoIP client on KDE. Improve its Kontact integration and extend the range of SIP services included in its setup wizard. Eventually, all KDE users and developers should be able to call each other out of the box for free when they install KDE. This would do wonders for KDE project collaboration and closeness among the KDE community.

1) Further extend the OpenDocument support in all KOffice applications. KDE 1.5's support is a good beginning, but its rendering and use of documents produced by openoffice is still far from seamless. Feature-wise, Koffice is already very impressive.

2) Work on the stability of Koffice. Assign somebody to do ongoing unit testing and bug squatting in kword, kpresenter and kspread.

3) A professional citation and bibliography management application that integrates with Kword. Tellico already has some bibliography management functionality, but Tellico is a general collection management application and in trying to be all things to all people doesn't do the bibliography management as well as it could. We could call it "Kcite".

4) Improve the multimedia features of Digikam. The current pki filters are cumbersome and have never worked properly for me.

5) Kpilot/Opensync functionality. This shit needs to just work. Send a student 10 or 15 pdas and make sure that he cannot leave his room until they all work seamlessly with Kontact.

6) Better tested integration of Kontact and the groupware suites, particularly egroupware. Egroupware has remained as one of the top-5 projects in sourceforge for quite some time and has one of the most impressive and easiest to deploy applications, but kontact's support for it is clunky and buggy.

7) Location-based awareness for all applications. Create location-based configurations for all applications. When I am home and I switch to my home AP, my default printer should switch to the right one as should my network-mounted shares and so forth.

8) Some further work-flow and usability love for Kontact. For instance, Kontact's naming of its own features is far too technical for everyday users. Many people often don't realize what great features lay hidden behind many KDE applications because their naming simply baffles them. I write this as a linguist and translator. I realize that Google may be more interested in hiring developers than people of my training, but a software application is a lot more than just its code. With the increased awareness that the KDE4 efforts are having about interface design, maybe opening one slot or two for graphic artists and translators would be a good thing to do for the SOC positions.

By Gonzalo at Wed, 2006/05/03 - 5:00am

5) Kpilot/Opensync functionality. This shit needs to just work. Send a student 10 or 15 pdas and make sure that he cannot leave his room until they all work seamlessly with Kontact.

Where are you going to *get* 10 or 15 PDA's? It's not like any manufacturer has ever supported syncing on Linux in any way at all. These things aren't free (as in beer), you know. The number of people working on syncing worldwide is very low (including OpenSync, perhaps half a dozen) and it's just a very much no-fun thing to do (testing is a pain because you need a device, usage patterns vary wildly, the devices change their data support irregularly, etc.)

By Adriaan de Groot at Wed, 2006/05/03 - 5:00am

I am sure we could get corporate sponsors to donate the needed hardware if there was a serious proposal to make said hardware work with Linux.

At the end of the process, the hardware could either be returned or if desired by donor company, it could then be given to people who complete specific KDE project goals or any other arrangement that the KDE foundation and donyouor of hardware finds suitable.

10 PDAs x $300 or $400 is not that much money.

So, by and large, this is doable.

By Gonzalo at Wed, 2006/05/03 - 5:00am

If we want to compete with Microsoft, we must have better tools for user friendly collaborative work.

Adding a wiki component in the Kollab stack tailored for knowledge workers which integrates well with KOffice and Kontact. For example using the shared Kollab addressbook, this wiki would creates pages for every employee of your team where you could easily drag and drop Kword files, save from KWord into a special page of the wiki.

Unison is a nice application that I use everyday to synchronize my notebook and my main computer. The command line interface is geeky and the gtk frontend clumsy. Adding synchronization in the heart of KDE with a kio slave, a kcontrol module and a framework for reconciliation of files would be nice.

By Charles de Miramon at Wed, 2006/05/03 - 5:00am

Well, as far as I can tell (not much experience with it), NetBeans has a good collaboration plugin, so perhaps better integration with Java apps in general would be helpful. Probably will become more viable if Sun releases their J2SDK under a free license or when GNU Classpath finishes up support for Swing.

By JVz at Sat, 2006/05/06 - 5:00am