Projects/Summer of Code/2007/Ideas

This page is an open list for ideas for the 2007 edition of Google Summer of Code. It will remain editable while the submission process is open.

This list is not exhaustive. It is just a collection of some ideas. To get further ideas, you can also look at our list of ideas for the year 2006

Before proceeding, please read the participation instructions. They are useful for students and developers alike. Before editing this page, please take a look at the Notes on editing this page section at the end.

Past ideas

You may want to take a look at the ideas page for 2006. Some of the ideas there are still valid today.

Project ideas

These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.

If there is no specific contact given you can ask questions on the general KDE development list [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.

When adding an idea to this section, please try to include the following data:

if the application is not widely known, a description of what it does and where its code lives
a brief explanation
the expected results
pre-requisites for working on your project
if applicable, links to more information or discussions
mailing list or IRC channel for your application/library/module
your name and email address for contact (if you're willing to be a mentor)

KDE Libs

KPassivePopup

Project Information: KPassivePopup is the class that displays information next to taskbar icons, system tray icons or windows without interrupting the user. It is used both directly and by KNotify and is part of libkdeui.

Brief explanation: Convert KPassivePopup to use QSvg for the frame etc. this would allow it to be much more flexible in its visual appearance and could allow us to eliminate the various custom implementations that are floating around. This would include examining these forks and ensuring the same functionality could be cleanly incorporated.

Expected results: The intended result would be a single implementation of KPassivePopup that could be reused without copying code by applications such as Kopete that currently maintain their own versions.

Knowledge Pre-Requisite: A prequisite would be knowledge of Qt/KDE and the ability to setup a KDE build environment. Knowledge of SVG would obviously be a big help.

Mentor: Richard Moore <[email protected]>, Aaron Seigo <[email protected]>.

Solid

Phonon

KHTML

KJS - Scripting Modules

Project Information: KJS is KDE's JavaScript engine that was originally developed for the Konqueror Web browser. It as a light-weight, standalone library that can easily be embedded into other applications to make them scriptable.

Besides being restricted to running in the sandbox of an application usage for text and file processing or other administrative or server side tasks in a command line interpreter are thinkable. Consider what made e.g. Perl successfull. What's lacking are modules providing the necessary functions.

Brief explanation: The project would start out with gathering an overview of typical functions found in other scripting languages like Perl, Python and Tcl. The most important ones would then be selected and implemented in (at first) C++ modules that are dynamically loaded by the KJS command line interpreter.

Expected results: A set of low-level modules like File, CGI, JSON or similar with a documented set of constructors, functions and properties. They should form the base for pure JavaScript modules to be build on top.

Knowledge Pre-Requisite: Some C++ programming knowledge is required. Knowledge about other scripting languages like Python and Perl would be advantageous.

Mentor: Harri Porten <[email protected]>.

Sonnet

Kross

Project Information: Kross is a modular scripting framework that provides a complete framework to embed scripting interpreters like Python, Ruby and KDE JavaScript transparently into native applications to bridge the static and dynamic worlds together.

Brief explanation: While Kross does already provide access to Python, Ruby and KDE JavaScript, Java is missing. With a Java backend we could provide access to JDBC databases, Hibernate, Sandboxes and all the other goodies.

Expected results:

Target is to implement a Java backend and offer Java as another supported scripting backend in Kross.
Propably just bridge or at least provide access to QtJambi.
Unittests and clean code :)

Knowledge Pre-Requisite: knowledge of C/C++, be able to get into the dark details of embedding Java.

Mentor: Sebastian Sauer <[email protected]>

KDEPrint -- UI redesign

Project Information: KDEPrint is the well known and very advanced printing platform common to all KDE applications.

Brief explanation: Redesign user interfaces related to printing. Improve usability.

Expected results: Produce an improved set of graphic interfaces to KDE's printing technology, based on usability reports already available and using new (original) usability ideas.

Prerequisites: C++, KDE/Qt programming, experience with design and creation of usable UI.

Mentor: Cristian Tibirna <[email protected]>

KDEPrint -- porting to CUPS > 1.2

Project Information: KDEPrint is the well known and very advanced printing platform common to all KDE applications.

Brief explanation: Port the current KDEPrint code to supporting CUPS later than 1.2, both in KDE-3.5 and KDE-4 branches.

Expected results: Based on the already very well thought out interface to CUPS-1.1, work is necessary for supporting new features and following bug fixes in the latest incarnation of CUPS, the most important backend of KDEPrint.

Prerequisites: C, C++, KDE/Qt programming, writing code following specifications.

Mentor: Cristian Tibirna <[email protected]>

KDEPrint -- porting to Qt-4.3/KDE-4

Project Information: KDEPrint is the well known and very advanced printing platform common to all KDE applications.

Brief explanation: Port the KDEPrint code of KDE-4 branch to latest Qt-4/KDE-4 libraries technologies.

Expected results: This task requires a thorough analysis of technologies used by KDEPrint in the previous (KDE-3.5) incarnation and replacement as needed with new or improved equivalents from Qt-4/KDE-4. Use of the new intercommunication technologies (D-Bus) and new notification technologies is required.

Prerequisites: C, C++, KDE/Qt programming, willingness to learn D-Bus as well as KDE-4 APIs.

Mentor: Cristian Tibirna <[email protected]>

KIConLoader: SVG Render Cache

Project Information: KIconLoader is the class the fetches icons from disk on demand and returns pixmap data for use on screen. This project would add an on-disk binary cache to be used for SVG icons.

Brief explanation: See my blog entry here for a description of the problem.

Expected results: A transparent cache that would increase the efficiency of SVG icon usage at runtime, with the possibility of adding runtime composition capabilities to KIconLoader.

Knowledge Pre-Requisite: A prequisite would be the ability to setup a KDE build environment. Qt/KDE programming knowledge is not a high requirement for this task, though the student will obviously be picking some of that up as they go. Experience with similar projects involving caching would be good.

Mentor: Aaron Seigo <[email protected]>.

KDE Base applications

Konqueror - web browser

Konqueror & Dolphin - file manager

Plasma: icon placement

Brief explanation: Ordering the icons on the desktop has always been a pain for the users. They invent a certain arrangement (images top left, devices lower right, ...) and try to stick with it. Whenever they drop something to the Desktop folder in their filemanager, or when they plug in a new device the icon appears at an arbitrary location. Using clustering techniques and meta information about the existing icons, it would be possible to determine the most useful location for a new icon on the desktop.

Expected results: Improve the icon placing strategy of kdesktop (plasma) using clustering techniques.

Try various clustering algorithms (Wikipedia Data Clustering might help) and choose the one most suitable for the task
Implement an icon placement strategy in plasma, using the chosen clustering algorithm.

Knowledge Pre-Requisite: Familiarity with clustering algorithms or motivation to study them, C++/Qt coding skills

KWin

Strigi: chemistry and biology support

Project Information: Strigi is a promosing alternative to other desktop search tools, like Beagle/Kerry. It has an plugin architecture that allows writing indexing plugins for a specific area, or specific enhanced purposes. Available are both inline plugins (written in C++), as well as plugins that call programs written in other languages via the command line. Strigi is showing progress towards integration to semantic desktop ideas, as in the Nepomuk project. This allows chemical information to be semantically marked up, and easily retrieved.

Brief explanation: The idea of this project is to integrate chemistry and biology knowledge into the KDE desktop, by writing chemistry and biology aware plugins for Strigi. Exact molecule searching on the hard disk will be supported via the InChI. For the rest, normal free text searching will do fine for now. Generation of InChI's will be done via OpenBabel, for files supported by the Chemical MIME's (which has existing KDE support) and kfile-chemical (which is available for KDE3 and KDE4). Optionally, the student can incorporate the chemical text mining tool OSCAR3 developed in Cambridge, UK, to extract InChI's from text documents, like PDF, HTML, etc. Here Strigi's jstream technology come in handy, as it will provide a plain text version for all those formats. Extraction of biochemical information is much easier, as these files commonly plain text already.

Expected results: Strigi plugins that:

extract meta data for (bio)chemical files defined by the Chemical MIMEs, va the kfile-chemical kfile plugins,
process files with a (subset of) (bio)chemical MIME with OpenBabel to generate an InChI for indexing,
(optionally) use OSCAR3 to process plain text and create InChIs for molecules found in that text. Additionally, the student is invited to propose a useful ontology for marking up the extracted chemical and biological information.

Knowledge Pre-Requisite: knowledge of C++ is a requirement, as is high school education in chemistry and biology.

Mentor(s): Carsten Niehaus <[email protected]>, Jerome Pansanel <[email protected]>, Egon Willighagen <[email protected]>, Jos van den Oever" <[email protected]>

Mailing list: [email protected]

KDE Edu

A 3D Molecular Editor

Project Information: There are several 3D molecular editors, but only few open source programs, such as Ghemical. The GPL-ed OpenBabel project open chemistry library has expanded its usefulness improving chemistry software. This resulted in, among other things, an application and library called Avogadro. Kalzium and Avogadro will soon merge a lot of code so that both apps share an underlying rendering library for molecules (using OpenGL). Avogadro already has basic "molecule construction" capabilities. The goal of this project is to extend these such to yield a 3D editor suitable for basic molecular drawing and visualization for high school and university students.

Expected results: The improved application would be based on the new OpenGL based rendering code, and able to construct common organic molecules (such as this one). The 3D-display code inside Kalzium will be reused and expanded to handle, for example, protein "ribbon" views, surfaces, and surface-mapped functions like electronic charge. Additional features such as configurable labels (for atoms, protein residues, etc.) and flexibility to change rendering for individual atoms or bonds would be welcome.

Knowledge Pre-Requisite: Basic Qt-knowledge and basic chemistry knowledge. OpenGL experience welcome.

Mentor: Carsten Niehaus (cniehaus at kde dot org)

Mailing list: kalzium at kde dot org

MARBLE - Adding a 2D View

Project Information: Marble is a Qt 4-based generic virtual globe widget which is meant to integrate well with the KDE desktop to provide basic input and visualisation facilities for geographical data. Marble currently lives in http://websvn.kde.org/trunk/playground/base/marble/ and the author would like to see Marble be included with KDE-Edu soon. More information: the Marble description.

Brief explanation: To be properly integrated with other applications a 2D View for Marble will be needed in addition to the preferred 3D View (e.g. for merging functionality of KGeography and Marble). Three steps are suggested:

reuse the current rendering engine in 2D mode
write an optimized approach for the 2D case and thereby refactor parts of Marble (especially the texture mapping)
include adding proper access methods for applications and the user interface

Depending on the knowledge of the applicant the refactoring part can be extended.

Expected results: adding the 2D View Mode to Marble. Optionally, if enough time is available, integrate that view mode in another application like KGeography.

Knowledge Pre-Requisite: basic knowledge of C++ is a pre-requirement. Basic highschool trigonometry knowledge would be helpful. Other useful skills, but not mandatory are:

Qt experience

Mentor: Torsten Rahn <[email protected]>.

Mailing list: The kde-edu mailing list: http://lists.kde.org/?l=kde-edu&r=1&b=200702&w=2 .

KDE PIM libraries and applications

KPilot - Enhance Record based syncing

Project Information: KPilot is the KDE application which synchronizes Palm OS PDAs with various KDE applications, including KMail, KAddressbook and Calendar. KPilot makes use of the pilot-link library to handle the interaction between the device and the conduits. These conduits are plugins which handle the actual synchronization of the items. For more information see [1]

Brief explanation: The vast majority of KPilot's conduits are record-based in nature. This means that the logical program flow for each of the conduits is very much the same in that they will each:

Open a Palm database
Retrieve either all records or just the changed records
Open a PC data store
Retrieve either all or changed records
Handle tri-directional syncing, conflict handling, and merging changed data
Then write the resolved data sets back to the PC and Palm data stores

But the current conduit framework does not abstract this common functionality into a set of base classes as it should. This has resulted in a lot of duplicated code throughout KPilot's conduit base, and each conduit has its own way of handling this common functionality. Understandably, this has led to bugs in the syncing algorithms and has made maintainability of the conduits (and KPilot) a much more difficult thing than it should be. For every conduit, the maintainer has to learn how the actual syncing is done. To make matters worse, there are a couple of conduits which don't sync correctly because of a incomplete implementation of handling records.

Expected results: The student will create an improved framework for KPilot's record-based conduits and (re)implement a (new) conduit as a proof of concept.

Documentation about the syncing process of a record based conduit.
1. Sequence diagrams detailing sync logic for each of the major scenarios: HotSync, FullSync, Copy PC to Handheld, Copy Handheld to PC
2. Class diagram detailing:
  - Inheritance hierarchy
  - Class relationships
Implementation of the abstract record based conduit in the KPilot library.
(Re)implementation of a (new) Conduit as proof of concept.

Knowledge Pre-Requisite: basic knowledge of C++ is a pre-requirement. Other useful skills, but not mandatory are:

Qt experience
Pilot-link experience

Mentor: Adriaan de Groot <[email protected]>, Jason 'vanRijn' Kasper <[email protected]>.

Mailing list: The kde-pim mailing list: http://lists.kde.org/?l=kde-pim&r=1&w=2.

KitchenSync

KitchenSync is the frontend to the generic synchronization system OpenSync. It is supposed to become the standard syncing solution for KDE. Right now it already supports synchronization of KDE PIM data with a wider variety of mobile devices like phones and PDAs as well was synchronization with other applications like Evolution or Google calendar.

KitchenSync works pretty well as OpenSync, but doesn't yet cover all functionality OpenSync provides. The goal of this project would be to improve that. For example the configuration GUIs for the various OpenSync plugins would need some work.

This project requires some knowledge in KDE programming. It will also involve collaboartion with the OpenSync team, so some experience with C is helpful.

Mentor: Cornelius Schumacher <[email protected]>

KOrganizer Theming

KOrganizer Theming: In the real world calendars are made from paper and carry lots of pretty pictures, witty sayings, historical data or similar things. Compared to that calendar programs are extremely plain. One of the intents of the CalendarDecoration plugin interface for KOrganizer was to make it possible to add theming to the calendar views, so that you can add all the fun things which make paper calendars more than just a bunch of papers with dates on it. Combined with the KNewStuff technology this could bring much more color to our desktops and make KOrganizer interesting to people which currently wouldn't think of using a calendar program.

Mentor: Cornelius Schumacher <[email protected]>

KDE Games

Kombinaton - AI Engine

Project Information: Kombination is a KDE4 scrabble clone. The project would be adding a artificial intelligence interface and at least one engine. Kombination currently lives in trunk/playground/games/kombination/ and the author would like to see Kombination be included with KDE Games soon. More information: the Kombination web page.

Knowledge Pre-Requisite: basic knowledge of C++ is a pre-requirement. Basic knowledge of Scrabble rules is a must too. KDE and Qt skills will be useful but not mandatory.

Mentor: Albert Astals Cid <[email protected]>.

Mailing list: The kombination mailing list: http://home.gna.org/kombination/ .

KDE SDK Applications

Kate

Project Information: Kate is a multi document editor, based on a rewritten version of the kwrite editing widget of KDE, offering all the features of that plus a bunch of its own.

Brief explanation: Make Kate a much more capable yet still lightweight development tool for KDE4. Add features to Kate including CVS and SVN integration (either via recognition of the kdesvn or kcvs utilities, or with a custom implementation), Eclipse-like workspace and project management, and build environment integration for various languages/tools via an extensible interface. Scale Kate as much as needed to accomodate these changes, and not beyond that (at least for the scope of this project).

Expected results: The intended result would be an stable and extended implementation of Kate, providing CVS and SVN integration, Eclipse-like workspace and project management, and build environment integration.

Knowledge Pre-Requisite: A prequisite would be knowledge of Qt/KDE and the ability to setup a KDE build environment. Additionally, knowledge of interfacing with source code repositories via C++, and general C++ knowledge would be required.

Mentor: Christoph Cullmann <[email protected]>.

Mailing list: The Kate mailing list

KDevelop & Quanta

Kopete

Amarok

Project Information: Amarok website

Tightening of Web Service Integration

Brief explanation: Amarok's motto is Rediscover your music. Since listening to music can be a somewhat uninteresting experience, we try to enhance this aspect in a number of ways:

Wikipedia information retrieval
Lyric downloads
Cover Art
Music suggestions

etc, etc. I'm sure you are more than familiar with the 'omg-im-going-to-wet-myself-this-is-so-cool' experience that you have at least once experienced.

We would like to see some sort of enhancement to meta-information which can be displayed to the user. Some ideas that come to mind may include:

Upcoming concerts
Random artist trivia

Expected results: The student will come up with a set of web-service enhancements and will implement them so that they integrate tightly with the final Amarok 2.0 interface and design goals.

Knowledge Pre-Requisite: basic knowledge of C++ is a pre-requirement. Other useful skills, but not mandatory are:

Qt experience
Web service skills, such as SOAP, XML/DOM structures etc
A keen eye for usability and the difference between features and benefits

Mentor: Seb Ruiz <[email protected]>

Mailing list: The Amarok mailing list

Other Applications

KBugBuster

KBugBuster is a native KDE client for the bug tracking system Bugzilla. It allows to browse, search and view bug reports and make modifications to them. It provides features which the web interface can't provide like an offline mode.

One potential task would be to make KBugBuster work with the XML-RPC interface of Bugzilla. This would make access to Bugzilla more robust and make it possible to better support the editing of bug reports.

Mentor: Cornelius Schumacher <[email protected]>

Knoware

Knoware is previous SOC project. It creates a system that collates bug reports as well as anonymous system specs offered by users. It provides a statistical way of matching up bugs to likely culprits in a system or configuration so that developers can get a better handle on what the problem likely as as well as informing users of KDE what the potential pitfalls of their current system could be.

One potential task would be to document the current system for further development. Another could be porting the curent code to Qt4.

Mentor:

Oxygen

Usability

A new design for contextual help (Whatsthis)

Implement Ellen Reitmair's, Olaf Schmidt's, Philip Rodrigues' plan for a new infrastructure for contextual help. ideas_whatsthis_january06_v1.3.pdf

Infrastructure

A way to make bugzilla help in finding duplicated bugs. could be some kind of 'suggested related bugs'

KOffice

A list of KOffice ideas can be found at the KOffice wiki.

KWord Scripting

Brief explanation: KWord comes with a Scripting Plugin based on Kross. The plugin provides a clean interface to offer access to the KWord functionality from within scripting backends.

Expected results: Improve the current scripting plugin.

Evaluate what is needed or what a script could need and implement it to earn a powerful scripting backend for KWord 2.0.
The current design may need to be refactored cause the scripting API should be as simple as possible.
Provide sample scripts to demonstrate what's possible and Unittests for regression testing.

Knowledge Pre-Requisite: knowledge of C++/Qt, experience with word-processing

Mentor: Sebastian Sauer <[email protected]>

Improve Kexi Data Import/Export

Brief explanation: Currently Kexi allows importing CSV files into an existing database, and converting MySQL/PostgreSQL/MS Access databases into Kexi databases.

The aim of this project is to provide plugin(s) that import from more database backends/formats.

You can select a backend you like to implement migration for:

HSQLDB - the OpenOffice.org DB backend (quite important to have)
ODBC
Paradox
DBase (e.g. using http://www.anubisnet.de/products/dbf )
MS SQL Server (e.g. using http://www.freetds.org/ )
Firebird - pending licence checks

For the ODBC driver, a migration plugin and a backend plugin should be provided. For Paradox, only a migration plugin is required, although this will require modifying the migration framework to allow more than one file to be selected as the source database (i.e. the database to be imported).

Both a migration plugin and a backend plugin could be provided for HSQLDB, which should be implemented using JNI to invoke JDBC methods in the HSQLDB library.

In any case, migration plugins are simpler to implement than direct access plugins (drivers), so these can be developed first.

Knowledge Pre-Requisite: knowledge of C++, (knowledge of Qt and experience with a given database format/backend is recommended)

More info:

Mentor: Jaroslaw Staniek <[email protected]>

Mailing list: kexi-devel

Kexi Web Forms

Brief explanation: Web Forms allow to read-only or read-write access to database projects created with Kexi. It is optional feature for uses where client has no Kexi installed for any reason. The fact that the Web Forms will use Web standards, adds another advantage over competitors like MS Access (which uses proprietary Windows-only ActiveX bindings).

Proposed solution is to develop a small standalone web server. It is probably already written in C++ or C by FOSS community. Good examples are lighttpd - http://www.lighttpd.net/ and (being already in KDEnetwork module) KPF - http://rikkus.info/kpf.html.

The web serwer would be dynamically linked to kexidb and thus can access Kexi databases via universal KexiDB API, and create HTML content on demand as an answer to HTTP requests.

For alternative solution see "Alternative solution for Kexi forms using PHP" below.

Knowledge Pre-Requisite: knowledge of C++ and HTTP/web standards, (knowledge of Qt and experience with a given database format/backend is recommended)

More info: Solution proposed by Jacek Migdal last year

Mentor: Jaroslaw Staniek <[email protected]>

Mailing list: kexi-devel

Alternative Solution for Kexi Forms Using PHP

Brief explanation: Create a Kexi plugin generating PHP code saving it directy to the filesystem. This will require Apache (or other PHP-compatible web server) to be present and configured, and also will require the plugin to be packaged with a script that will install appropriate tools that allow r/w accessing the Apache/php subdirs.

Knowledge Pre-Requisite: knowledge of PHP, web standards and C++, (knowledge of Qt is recommended)

Mentor: Jaroslaw Staniek <[email protected]>

Mailing list: kexi-devel

Notes on editing this page

Before making any modifications, please log in to Techbase. This will help us track who is contributing to the ideas.

When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.

Please use the talk page if you want to discuss an idea.

Finally, do not delete ideas without a reason for doing so (like, for instance, being contrary to KDE ideals, being completely unrelated to KDE, being unfeasible, etc.) -- you may want to state in the talk page why you removed the idea.

Do not re-add ideas that were removed without discussing first with the developers of the target application.