Toggle the table of contents

Projects/Summer of Code/2007/Ideas: Difference between revisions

From KDE TechBase

< Projects‎ | Summer of Code/2007

Latest revision as of 15:11, 20 September 2007

This page is an open list for ideas for the 2007 edition of Google Summer of Code. This page is now frozen, since the submission process is over.

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.

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

Solid is the KDE hardware abstraction layer, that enables KDE programs to get consistent results when running on different platforms.

Plasma integration with Solid: Plasma uses the term 'data engine' to describe inputs to Plasma applets ('plasmoids'). Multiple applets may make use of a data engine. One task would be to write data engines for Solid interfaces for hardware status monitoring and control via Plasma.

Media player support in Solid: Currently there is no high level support for portable media player devices in Solid. Applications such as Amarok have had to develop their own media player abstraction layers. Having this functionality in Solid would create exciting possibilities, for example, adding podcasts directly to your media device from a browser, or storing files received via IM directly on the media device.

Scanner support in Solid: On Linux, scanner support uses the SANE library. To make scanners accessible from KDE applications on other platforms, a Solid wrapper to the most frequently used scanner functions and a SANE backend would make a good Summer of Code project for a student interested in imaging on Linux.

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 successful. 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. An example would be the classic File object that could then be imported with an "import File;" directive by the user.

Some ideas for possible modules:

KIO (copy file across the network)
Mail (SMTP, POP3, IMAP)
D-Bus (to control applications from the command line)
KJSEmbed's QObject bindings
KConfig (for use by scripts themselves and application configuration)
COM (on Windows)
Text processing (search & replace etc.)

Expected results: A set of low-level modules with a documented set of constructors, functions and properties. They should form the base for pure JavaScript modules to be build on top. Where possible with reasonable effort test cases should be developed, too.

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

Project Information: Sonnet will be the future grammar, spell-checking and language detection framework in kde.

Brief explanation: Make kateparts compatible and integrated with Sonnet framework.

Expected results:

Be allowed to use inline spell-checking in kile (latex front-end based on kateparts) or in the comments of a source file.
Would be wonderful if the grammar and language detection also work with latex files.

Knowledge Pre-Requisite: I don't know but probably C++, parsers, kate parts and language studies.

Mentor:

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]>

KDEPrint -- add support for LinuxPrinting's on-line drivers query

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

Brief explanation: Add support to KDEPrint for the new OpenPrinting Database which allows on-line search for new (locally unavailable) drivers for printers during printer installation.

Expected results: This task requires a good learning of the OpenPrinting Database Querying interface. Getting accustomed with KDEPrint's printer installation algorithms is also required. Target platform is KDE-4 but time permitting, a port to KDE-3.5 would be welcome.

Prerequisites: C, C++, KDE/Qt programming

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]>.

(Note: KIconLoader would benefit from a generic cache, not limited only to SVG but usable also for PNG icons. See the second paragraph of the benefits section in the blog entry for reasons [less disk seeking]. I think it would make sense to change this to a generic cache for KIconLoader. Lubos Lunak <[email protected]> )

KDE Base applications

Konqueror - userscripts

Project Information: The goal of this project would be to implement and integrate into KDE4 a Konqueror equivalent of FireFox's Greasemonkey plugin to allow installing and running user scripts. The project could start of from this existing GPL-ed code.

It seems that someone is already well on their way to completing this already: http://namshub-kde.blogspot.com/2007/01/more-work-on-konquerors-user-scripts.html

Expected results: A Greasemonkey equivalent for Konqueror that allows (de)installing and running Greasemonkey compatible user scripts.

Knowledge Pre-Requisite: C++ programming skills

Konqueror & Dolphin - file manager

Ability to extract files from RPM packages

Plasma: wallpapers++

Brief explanation: using QGraphicsView and Qt4 for the desktop layer gives us quite a few new possibilities when it comes to desktop wallpaper images. A SoC project that results in a desktop wallpaper implementation that goes beyond the usual static display of an image would be nice.

Expected results: Efficient wallpaper support for PNG, JPEG and SVG images that supports static image effects and transition effects (e.g. when switching desktops).

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 -- Tiling Support

Project Information: KWin is the KDE window manager, an application responsible for managing all windows.

Brief explananation: Some window managers (e.g. Ion or wmii) have the ability to divide the screen to smaller sections which make it simpler to work with several windows at the same time (window maximize only to its tile, etc.).

Expected results: Implemented tiling support in KWin.

Knowledge Pre-Requisite:

C++, Qt/KDE (KWin doesn't use much functionality from Qt and KDE libraries besides basic classes though)
X11/Xlib knowledge beneficial. X11 parts are mostly abstracted in KWin, but it's possible at least little knowledge might be required (it should be possible to learn necessary things while working on the project though).
Multiple-monitor (Xinerama) setup beneficial. KWin already has Xinerama support, parts of which possibly could be used as a base for tiling support. With tiling support implemented, Xinerama support should be implemented as tiles representing Xinerama screens.

References:

Wikipedia window manager entry
KDE bug #59338
KDE bug #107554
Ion
wmii

Mentor: Lubos Lunak <[email protected]>.

KWin -- Improved Xinerama Support

Project Information: KWin is the KDE window manager, an application responsible for managing all windows.

Brief explanation: Xinerama (and various implementations known also as e.g. MergedFB or TwinView) is an X server extension that merges two or more physical monitors into one large display. KDE already provides a decent support for Xinerama, but there is still room for improvement, in particular, different monitors are linked together even in cases when it might be more beneficial to have them independent, for example with virtual desktops.

Expected results: Improved Xinerama support in KDE/KWin. Specifically, making virtual desktops on different Xinerama displays independent, per KDE bugreport #107302, and related fixes/changes.

Knowledge Pre-Requisite:

C++, Qt/KDE (KWin doesn't use much functionality from Qt and KDE libraries besides basic classes though)
X11/Xlib knowledge beneficial. X11 parts are mostly abstracted in KWin, but at least little knowledge will be required (it should be possible to learn necessary things while working on the project though).
Multiple-monitor (Xinerama) setup. Although it is possible to use Fake Xinerama for making a single monitor act like a Xinerama setup, real Xinerama setup is strongly recommended.

References:

Wikipedia window manager entry
Wikipedia Xinerama entry
KDE bug #107302

Mentor: Lubos Lunak <[email protected]>.

Strigi: chemistry and biology support

Project Information: Strigi is a promosing alternative to other desktop search tools, like Beagle/Kerry. It has a 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, via 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]

KDM -- Integration with screen saver/locker

Project Information: KDM is the KDE desktop manager, an application responsible for managing X displays and user logins.

Brief explanation: Currently, the login manager and the screen locker (which also launches the screen saver) are separate applications. KDM is completely out of the loop as long as a user session is running on a particular display. This puts some limitations on the smoothness of the so-called fast user switching and does not allow for a really integrated implementation of things like pulling the authentication token (e.g., smart card) to lock the screen.

Expected results: The KDM greeter (the graphical part of KDM) should become runable from within a user session. Krunner's idle time detection needs to be merged into KDM and the possibility to launch a sub-session to start a screen saver within needs to be added. This all needs a suitable UI and a usable config dialog. In the next step, the shutdown sequence would also be completely integrated with KDM, which would require communication with KSMServer.

Knowledge Pre-Requisites: C, C++, Qt/KDE, probably some Xlib

Mentor: Oswald Buddenhagen <[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 .

MARBLE - OpenStreetMap, GPS, Almanac, improved KML support

Brief explanation: There are a lot of other interesting projects that would make a nice Google Summer of Code 2007 project each on their own. Keep in mind that all those should be introduced in an unobtrusive manner as Marble is aimed at casual users without much technical knowledge. So a larger part should be dedicated on the usability (Of course it needs to work, too ;-):

Basic support for GPS devices: Introduce an interface to support GPS tracks and / or provide support for the GPX format. Co-Mentor: Inge Wallin.
Basic support for OpenStreetMap ( http://www.openstreetmap.org ). The applicant should find a way to incrementally download data collected by the Open Street Map project. This should happen in the background.
Marble Almanac: The applicant should extend the current placemark info dialog into a module of its own that compiles together various geographical information from different sources (like the CIA fact book).
Improve KML capabilities. Currently Marble has very basic KML support already. Although Marble won't be able to support the whole range of KML tags that e.g. Google Earth supports, it would be nice if support could be made more standards compliant. The student should be able to refactor the current code and introduce an improved design.

Knowledge Pre-Requisite: All these projects require that the student is a self-starter and will be able to do some research concerning the topics on their own. Beyond that you should have basic C++ knowledge. Prior Qt experience is a plus.

Mentor: Torsten Rahn <[email protected]>, Co-Mentor for GPS support: Inge Wallin <[email protected]>

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

Step interactive physical simulator

Project Information: Step is interactive physical simulator for education. It is very young program recently ported to KDE4. You can find more about it here: http://edu.kde.org/step/ .

Note: This entry is added by author of the Step who want to apply to SoC as a student himself and seeking for mentor (as suggested on kdeedu mailing list).

Brief explanation: In order to be useful and to be included in kdeedu Step needs a lot more features than it currently has (it is only two month old). I propose adding the following features to Step (the list will be filtered to fit in SoC timeframe):

Simulation (StepCore library):
1. collision detection with friction (I hope this will be ready before summer)
2. movement restrictions (joints) (it can be ready too)
3. global error estimation
4. molecular dynamics (2d gas, 2d fluid)
5. Brownian motion
6. soft bodies and massive springs
7. API polishing
GUI (Step itself):
1. threading (do calculations in separate thread)
2. user-editable notes in experiment
3. units for all quantities, unit conversions
4. sidebar with nice descriptions for all bodies and its parameters (main properties, physical laws about it, real-world examples, ...)
5. custom graphics for various quantities (for example v(t) or v(x) - user can select what exactly to plot).
6. custom controllers to interactively control body parameters during simulation (for example user can add slider to control mass of the body and even assign hotkeys to it).
7. knewstuff for sharing experiments
8. tutorials (series of experiments with explanations)
9. GUI polishing

Mentor:

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]>

Akonadi

Akonadi is the upcoming PIM Storage Service which will be used for KDE PIM 4. It's currently under development. You will find more information on the Akonadi pages on the KDE PIM Home Page. Akonadi provides a great opportunity for a lot of interesting projects. See below for some ideas.

Build a proof-of-concept application using Akonadi as backend. This doesn't have to be a full-blown application, but it should demonstrate that the backend can be used to deliver data. The app could concentrate on one data type like mail, events, tasks or contacts or do a clever combination of multiple types. Be creative!
Port one of the existing groupware resources to Akonadi, so that Akonadi gets access to Kolab, OX, OpenGroupware.org, etc.
Implement a non-C++ library to access the Akonadi Storage Servcie (e.g. Ruby, Java, C, Python, C#)

Contact: KDE PIM Mailing List

kxml_compiler

In KDE PIM there are some XML formats which are not parsed by one of the common XML parsers, but which are parsed by specific C++ code which is automatically generated from the XML schema by a special tool, called kxml_compiler. It currently only works for basic cases. The goal of the project would be to improve kxml_compiler to work with a wider range of schemas, in particular the proposed schema which is used by the next generation of the KOrganizer holiday descriptions.

kxml_compiler is part of the Kode suite. It consists of parsers for XML Schema and Relax NG, a layer for intermediate representation of the structure of the schema and the code generator itself which makes use of a helper library for generating C++ code. Working on kxml_compiler would probably involve working on all of these components.

Expected results: An improved version of kxml_compiler which is able to generate a fully working parser for the XML descriptions of KOrganizer holiday files.

Knowledge Pre-Requisite: Good knowledge of C++ and XML is mandatory, experience with Qt or XML Schema is a plus.

Mentor: Cornelius Schumacher

KDE Games

Kombination - AI Engine

Project Information: Kombination is a KDE4 scrabble clone. The project would be adding an 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/ .

Kate

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. It is aimed to developers and other more advanced users, therefor with KDE 4, it will ship with kdesdk. The following projects are planned for Kate:

Enhance the development related features of Kate

Project Information: The goal of this project is to make Kate a even better tool for software developers and a tighter integration of Kate into the development process (support for projects, SVN, ...).

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 a 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

Extend the scripting support of Kate

Project Information: Kate for KDE 4 supports already scripting of the part via kjs, but this support should grow to be available for the application, too. Beside this, the kjs support of the part needs enhancement, too. Beside this, evaluation, if kjs or QtScript should be used for the long run is in scope of this project.

Brief explanation: Enhance and implement the JavaScript scripting of Kate part and app, evaluate the use of kjs or QtScript for the KDE 4 timeframe, define interfaces for the scripting API. A tight cooperation with the other Kate developers and coordination with the kwrite-devel mailing list is must, as the created interfaces will need to stay around over the whole KDE 4 timeframe.

Expected results: The intended result would be a set of new scripting interfaces for either kjs or QtScript for both the part and the application. They should provide a cleaned up superset of the current interfaces, allowing to write both general purpose scripts and indentation scripts.

Mentor: Christoph Cullmann <[email protected]>.

Mailing list: The Kate mailing list

Improve Search/Replace in Katepart to handle newlines

Project Information: Katepart is the KDE Advanced Text Editor component used in noumerous KDE applications with text editing needs. Katepart stores the text in a vector of lines, and searches one line at the time. Adding support for finding text spanning multiple lines, and easily replacing with text with multiple lines is one of the most wanted features in the component.

Brief Explanation: Add support for entering and finding text containing 'newlines' - according to the document settings, for entering and replacing with text containing newlines (as above), and for searching with regular expressions containing atoms matching newlines.

Expected Results: Ability to enter and find strings containing newlines both with regular expression search and normal search, and ability to replace with strings containing newlines, in the Katepart editor component.

Knowledge Pre-Requisite: A prequisite would be knowledge of Qt/KDE and the ability to setup a KDE build environment. Additionally, knowledge of regular expressions, and general C++ knowledge would be required.

Mentor: Anders Lund <[email protected]>, Christoph Cullmann <[email protected]>.

Mailing list: The Kate mailing list

KDevelop & Quanta

Extend KDevelop's snippet support

Important: read first! Project Information: Extend KDevelop's current snippet support to provide more powerful features, see RFE 106165 for a detailed description (this proposal has been confirmed by popular vote).

Brief explanation: Provide heavily improved snippet support as a standalone kpart module, that other KDE applications may use.

Planned features:

support multiple snippet databases
support arbitrary snippet attributes to store snippet-specific meta information (such as "description", "platform", "OS", "supported_compilers", "required_libs", "required_headers", "authors", "version", "last_modified", "languages" etc).
support attribute-based database browsing & searching
support fully customizable code snippets
support mutual dependencies for code snippets
support exporting (i.e. to facilitate sharing) of snippet databases

Development milestones:

conceive suitable and extensible database structure/format, given that database sharing/exchange (export) are vital components of the original idea, it might make sense to directly use XML as foundation for the actual DB itself, too.
implement support for loading/saving and modifying snippet database files, consider providing support for multiple databases opened concurrently.
implement support for "meta info" (classification and categorization of snippets using arbitrary snippet "attributes" (key=value) pairs for each individual snippet)
extend the current UI to provide facilities for browsing and searching the snippet DB using the aforementioned snippet attributes (meta information).
extend current snippet templating mechanism, to facilitate interactive and self-explantory template customization/parametrization, i.e. by enabling developers to provide an optional descriptive field for each customizable snippet template variable.
provide a GUI frontend to the previously mentioned interactive, wizard-like templating mechanism, where a snippet end-user may be interactively queried, to customize the requested snippet
implement foundation to provide support for inter-snippet dependencies, so that snippets may have mutual dependencies, which could be taken care of automatically (see original RFE).

Knowledge Pre-Requisite:

basic/intermediate C++
QT/KDE familiarity required
XML

Expected results: implement the foundation and infrastructure required to facilitate development of the aforementioned features as a kpart, so that other KDE applications (besides kdevelop) may make use of snippet support.

Suggested Approach: given that the envisioned functionality would probably be interesting to a rather large user base/audience, one should consider using a library-oriented approach, where key-functionality is provided in a fashion that facilitates standalone library-deployment, so that other OSS projects (i.e. other IDE projects) may eventually employ the corresponding library to add "snippet"-support, too.

Mentor: none yet

Potential Mentors: none yet

Mailing list: KDevelop mailing list

Implement foundations for KDevelop4 Ruby language support

Project Information: Ruby language and Rails web development tool is rapidly gaining popularity. The goal of this project is to implement the foundations for the best possible Ruby/Rails support in KDevelop.

Knowledge Pre-Requisite: advanced knowledge of C++ is a pre-requirement. KDE and Qt skills are desired but not required. At least basic knowledge of parsing theory (lexers, LL parsers, AST's) is necessary as well. This is a challenging project.

Brief Explanation: There're beginnings of Ruby support for KDevelop4 already. So the Ruby parser would be finished first and then definition-use chain for would be implemented. Those would allow to build extended code highlighting, navigation and problem reporting. The design for Ruby code completion would also be in the scope of this project.

Expected Results:

Ruby parser with tests covering most of the language features
DUChain builder for class/method definitions and their usages
Advanced Ruby code highlighter and problem reporter
Working and well-tested Ruby language support plugin
Design for Ruby code completion

Mentor: Alexander Dymo

Mailing list: KDevelop mailing list

Implement foundations for KDevelop4 C# or Java language support

Project Information: This is the project with a goals similar to the previous Ruby's one. Same are the prerequisites and expected results with only one differences. C# and Java parsers are already complete so the work could start with integrating them into KDevelop infrastructure. Also code completion for these language will be much easier to implement.

Mentor:

Mailing list: KDevelop mailing list

Kopete

Fix jingle support. Actually, make jingle support work. That means port everything below libjingle to the current version of ortp, make sure it is working and make jingle support on by default. Please.

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

Integrate Additional Music Store or Streaming Music Service

Brief explanation: Since the introduction of the integrated Magnatune.com music store in Amarok, there has been many proposals for other stores or services that could be integrated in a simmilar way. In the process of working towards Amarok 2.0, a new framework for adding such services without cluttering the interface has been proposed and the Magnatune store has been ported to this framework. Adding a new store or service is a nice way of getting into coding on Amarok at is fairly easy to approach witout knowing all the intricate details of Amaroks inner workings.

There are several types of services that could be of interest:

DRM free music stores ( preferably with good, full length, previews )
Streaming audio content services ( Again, no DRM is a must )
Live recording archives
Most likely a 100 other kinds of sites that I have not thought of...

The service chosen will have to be legal, and the service must agree to the integration taking place.

There are currently no concrete agreements in place with other services, so this is very much a "bring your own idea" project, which both makes it a bit harder to get started, but also more rewarding.

Expected results: The student reaches an agreement with a music store/service/whatnot and integrates its service into Amarok. Some effort would most likely also be spent on helping to mature the service framework.

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: Nikolaj Hald Nielsen <[email protected]>

Mailing list: The Amarok mailing list

okular

Project Information: okular is a KDE 4 document viewer. http://www.okular.org

Mailing list: The okular mailing list

Improve the rendering of PDF patterns

Explanation: okular uses the Poppler library to render the PDF files. Some files with complex patterns may take even minutes to render, while with Acrobat Reader just a couple of seconds.

Expected results: One needs to improve the Poppler library code that handles rendering of PDF files with patterns, making the pattern rendering faster with no drawbacks.

Knowledge Pre-Requisite: basic knowledge of C++ is a requirement. Qt4 is strongly suggested too. Graphics and PDF konwledge are strongly suggested as well, but not mandatory.

Mentor: Albert Astals Cid <[email protected]>

Improve the presentation mode

Explanation and Expected results: okular has a presentation mode for displaying documents on the screen in a way similar to a presentation application (think about KPresenter, OpenOffice.org Impress). Currently, the mode can just display only a single page, at the maximum size allowed by the screen. The idea is to extend the presentation mode by adding:

zooming support and pan mode
facing mode
missing PDF transitions, like Fly, Push, Cover, Uncover, Fade

Knowledge Pre-Requisite: knowledge of C++ and Qt4 is a requirement. KDE 4, graphics and PDF konwledge are strongly suggested as well, but not mandatory.

Mentor: Albert Astals Cid <[email protected]>

Improve the annotation support

Explanation and Expected results: one of the okular's goals is to support the annotations, mainly coming from PDF documents (but also from DjVu and ODT documents). As the support is not yet complete, some ideas could be:

adding the visual editing features (e.g. mouse click to visually select, drag to move around or resize, etc)
adding support for more kind of annotations (e.g. Caret, Watermark, etc)
improve the annotation toolbar
better support for text and line annotation drawing

Knowledge Pre-Requisite: basic knowledge of C++ is a requirement. Qt4 is strongly suggested too. Graphics and PDF konwledge are strongly suggested as well, but not mandatory.

Mentor: Albert Astals Cid <[email protected]>

3D artwork support

Explanation and Expected results: the PDF formats allow the embedding of 3D artwork in documents. The idea is to start supporting this kind of artwork, and start displaying them on the document. What is required to do is:

basic reading support
basic displaying of the artwork on the document (thus creating a 3D view)
basic interaction with the 3D artwork (mouse or document actions)

Knowledge Pre-Requisite: knowledge of C++ is a requirement. Qt4 is strongly suggested too. Graphics and PDF konwledge are strongly suggested as well, but not mandatory.

Mentor: Albert Astals Cid <[email protected]>

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:

Application User Interface Test System

There are a couple of tools available for Qt / KDE that allow testing of applications - squish and kdexecutor. Both are binary only, and are specific to the systems that they are built on.

It would be useful to have an open source tool that allowed us to test applications in a scripted way. Similar open source tools include Dogtail and LDTP, which use the accessibility interfaces in Gnome.

There are arguments for and against using accessibility - it might be a lot more useful to implement a separate system, using some of the Qt4 specific features including QMetaObject. Qt4 has a nice set of hooks, and QTestLib shows how they can be implemented. However instead of requiring specific code in the application (as done by QTestLib), it would be more flexible to use LD_PRELOAD and a small interface library.

More discussion: Brad Hards <[email protected]>

Ad-hoc collaborative content & file sharing applet

Your team contributes, and wants instant, easy way to share your work-in-progress and to solicit review by peers on IRC. You either upload to your own web space or use Kicker's Personal Web Server applet, but really want to just click in one place and paste the fully qualified URL in the chat window... Hustle of establishing a collaboration mechanism should be removed from the process of contributing. When it comes to free content, even a small penalty of monotony may stifle the flow of collaboration.

We need the free artists and content contributors. Next generation of prospective free content contributor / collaborator needs something more friendly and accommodative than today's Kicker Personal Web Server.

Proposal 1

http://accentsolution.com/socproject/

by Daniel Dotsenko ( dd @ accentsolution . com )

Proposed mentors:

A. Wiedenbruch (wirr) - Active SuperKaramba maintainer and porter to Kross and KDE4 (Contacted. He indicated general interest in the project.)

R. Nickell (p0z3r) - Long-time SuperKaramba maintainer.

Oxygen

Decibel

You can find a list of Decibel related ideas in the Decibel Wiki

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

All KOffice projects have common contact information and background info; You can read documents on www.koffice.org and wiki.koffice.org, various proposals will reference pages on the wiki as thats the main design 'scratch pad' for the developers of KOffice. Contact information; IRC: irc.kde.org channel #koffice Mail: sent mail to the koffice mailinglist. Info here

KOffice-wide Projects

Collaborative editing in KOffice apps

See Collaboration. We don't expect a fully working implementation, as it is most probably too big a project. So please guestimate what you want to work on and finish.