removing widgets as well as positioning and sizing for PanelContaiments. Ways

removing widgets as well as positioning and sizing for PanelContaiments. Ways

to control the wallpaper, if any, will also be provided in the per-Containment

to control the wallpaper, if any, will also be provided in the per-Containment

−

D-Bus interface.

+

D-Bus interface. A KRunner plugin make an easy to discover way to offer this functionality directly to the user.

In turn, a D-Bus interface for each widget representing its available

In turn, a D-Bus interface for each widget representing its available

Line 475:

Line 475:

----

----

+

====Project: Add Weather support to Marble====

+

'''Brief explanation:'''

+

There are several sources for freely available weather data on the internet. It should also be possible to display these weather information in Marble as little sun icons and temperature information in the map. Additionally it could be possible to display forecasts based on the Marble time support.

−

=== KStars ===

+

'''Expected results:'''

−

KStars is a Desktop Planetarium for KDE. It displays a map of the sky and provides a lot of tools to learn astronomy, or to calculate and predict astronomical phenomena. See [[http://edu.kde.org/kstars|The KStars Homepage]] for more information.

+

* Weather information gets fed from the weather service.

+

* The weather information, such as temperature and cloud status, are displayed in the marble map.

+

* The user can click on the icons to get further information like air pressure.

+

* The shown weather information depends on the time that is currently shown by Marble.

+

* Perhaps it could be possible to show also historical values.

+

* Perhaps it is possible to build a weather plasmoid based on this feature.

−

==== Project: Community Integration for KStars ====

+

'''Knowledge Prerequisite:''' C++ and Qt.

−

'''Project Information:''' KStars is a desktop planetarium program for KDE.

+

−

'''Brief explanation:''' Amateur Astronomy (which is one of the important use-cases of KStars) is typically done in communities. KStars permits users to save their own observing logs. It would be nicer if the user could share his observing logs with other users and see other observers' logs within KStars. It would also be nice if KStars had a map (using MarbleWidget) to display various Astronomy-related establishments (like amateur associations, observatories, research institutes). Another possible idea could be an observing report generator that would generate a report based on observing logs, and at the user's will, share it / post it on the internet.

+

'''Mentor:''' Torsten Rahn / Patrick Spendrin

−

'''Expected results:''' Implement some features that will make it easier for users to collaborate, as suggested above.

Marble already has got GPS support. However it would be nice if it would get improved.

−

'''Mentor:''' Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

+

'''Expected results:'''

+

Here are a few possible things one can focus on

+

* Port GPX-Import over to the geodata framework and extend it.

+

* GeoClue-integration.

+

* Improved UI

+

* Support for GeoCaching

+

* Basic integration with OpenStreetMap (?)

−

==== Project: FITS Image Overlay on the sky map. ====

+

'''Knowledge Prerequisite:''' C++ and Qt. Knowledge about KML/GPS/GPX is not necessary but would be appreciated.

−

'''Project Information:''' KStars is a desktop planetarium program for KDE.

+

'''Mentor:''' Torsten Rahn / Patrick Spendrin.

−

'''Brief explanation:''' It would be great if a FITS image could be overlayed on the sky map so that the field drawn by KStars could be compared with the field in the FITS image. This would be of great benefit to observational astronomers, astrophotographers and comet / asteroid observers. An extension would be to download a DSS image using KStars' already existing tool and map it onto the sky map. The support of shapes like ds9 region, annotations on the sky, etc. could also be added.

+

=== KStars ===

+

KStars is a Desktop Planetarium for KDE. It displays a map of the sky and provides a lot of tools to learn astronomy, or to calculate and predict astronomical phenomena. See [[http://edu.kde.org/kstars The KStars Homepage]] for more information.

−

'''Expected results:''' Functionality to overlay a FITS image or a DSS image obtained through KStars on to the sky map.

+

==== Project: Community Integration for KStars ====

+

'''Project Information:''' KStars is a desktop planetarium program for KDE.

'''Brief explanation:''' Amateur Astronomy (which is one of the important use-cases of KStars) is typically done in groups. KStars permits users to save their own observing logs. It would be nicer if the user could share his observing logs with other users and see other observers' logs within KStars. It would also be nice if KStars had a map (using MarbleWidget) to display various Astronomy-related establishments (like amateur associations, observatories, research institutes). Another possible idea could be an observing report generator that would generate a report based on observing logs, and at the user's will, share it / post it on the internet.

−

'''Mentor:''' Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

+

The first step in this project would probably be evaluating existing XML-based formats for interchange of observing logs like the [[http://observation.sourceforge.net/en/download.html COMAST XML Schema]]. If nothing fits our purpose (which is unlikely), we might need to create a new format. The next step would be to make a user interface to store one's own log and retrieve other users' logs in this format. Then, you could proceed with an observing report generator or something. Further development of these ideas is left to the student.

−

==== Project: Tools for Eclipses ====

+

'''Expected results:''' Implement some features that will make it easier for users of KStars and amateur astronomers to collaborate, as suggested above.

−

'''Project Information:''' KStars is a desktop planetarium program for KDE. Currently, it can predict Solar Eclipses (using the Conjunctions tool), but cannot plot trajectory of shadows, or predict Lunar Eclipses.

+

'''Knowledge Pre-Requisite:''' Required: C++. Prior knowledge of KIO_HTTP will help. Ability to grasp XML specifications from documentation will help too.

−

+

−

'''Brief explanation:''' The project's primary goals are to include simulation and prediction (maybe using the existing Conjunction backend) of Lunar eclipses, and to create a tool to mark the trajectories of Solar and Lunar eclipse shadows on a map of the earth, including marking of totality, partial eclipse and annular eclipse. Something similar to this: [http://eclipse.gsfc.nasa.gov/SEmono/TSE2009/TSE2009iau/TSE2009-fig01.GIF]

+

−

+

−

'''Expected results:''' A complete set of tools to deal with eclipses.

'''Project Information:''' KStars is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons.

−

−

'''Brief explanation:''' Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage.

−

−

'''Expected results:''' Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.

−

−

'''Knowledge Pre-Requisite:''' Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.

'''Mentor:''' Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

'''Mentor:''' Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Line 628:

Line 628:

Since in a ultimate look, automates are graph, it would be nice to have an automate support for it.

Since in a ultimate look, automates are graph, it would be nice to have an automate support for it.

+

----

===KDevelop===

===KDevelop===

+

----

KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages.

KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages.

Line 646:

Line 648:

'''Knowledge Prerequisite:''' C++ and Qt. Experience with parsers would be a bonus.

'''Knowledge Prerequisite:''' C++ and Qt. Experience with parsers would be a bonus.

KDevelop has a fairly comprehensive model of the user's codebase, however at this point it has not been fully exposed to the user. In order to visualize the code, the user currently has to use the code browser, which can only show one context/declaration at a time.

+

+

This project would aim to create a graphical visualization of the code structure, and allow much more powerful navigation of the code.

+

+

'''Expected results:'''

+

Using graphicsview, a widget would be created which shows the code browser's current context or declaration, in a [http://en.wikipedia.org/wiki/Control_flow_graph control flow graph]. It would be able to zoom out, pan, etc... loading data as required from the definition-use chain in a separate thread. There could also have a separate view to show code structure. Refactoring and other tools would be made more accessible using this widget.

+

+

Other ideas for utility of the widget include linking with the debugger and/or callgrind tools to show how the program has/is being executed, which areas need optimization, etc.

+

+

Investigation could be performed into reuse of code from the Umbrello project, if suitable to kdevelop's design.

+

+

See the [http://api.kde.org/4.x-api/kdevplatform-apidocs/language/duchain/html/index.html Definition Use Chain] documents for the api which contains the information about the code structure.

+

+

'''Knowledge Prerequisite:''' C++ and Qt. Experience with graphics technologies would be a bonus.

'''Explenation:''' The modern way of a summary is a tag cloud/concordance graph a la Wordle.net. This to a document in many cases makes way more sense than a table of content or index - its like an instant summary based on the actual text. It is used in so many web content systems that it is really weird there is no Office suite that offers it for regular office documents. The SoC project would work on an interface to control tag clouds in documents it a little better than in web apps - say by setting the amount of cloud items you want, have a user-editable list of words you want to keep out (or add), add icons/image alternates, change the weight of things you want to be more visible, drag and drop reordering of cloud text, font and styling preferences.

==== KPresenter ====

==== KPresenter ====

Line 846:

Line 910:

----

----

====Project: Akonadi Resource for KMail local folders====

====Project: Akonadi Resource for KMail local folders====

+

+

'''Most of this will probably be done as part of an NLnet project, see [http://thread.gmane.org/gmane.comp.kde.devel.pim/23895 this announcement].'''

+

+

'''Brief explanation:'''

'''Brief explanation:'''

KMail stores its mail in a folder hierachy where each folder can contain mails '''and''' further sub folders.

KMail stores its mail in a folder hierachy where each folder can contain mails '''and''' further sub folders.

Line 882:

Line 950:

Of course, your own ideas are very welcome as well

Of course, your own ideas are very welcome as well

+

+

'''Another idea, which invalidates most of this, is to use a Webkit-based editor, like described in [http://labs.trolltech.com/blogs/2009/03/12/wysiwyg-html-editor/ this blog post].'''

The aim of this project is developing Mancala game with lively interface that is changeable depend on the culture user chose to play. For example, if user choose Africa Culture, the interface will be a board drew on sand with several stones plus sounds of jungle, wild-animals...

The aim of this project is developing Mancala game with lively interface that is changeable depend on the culture user chose to play. For example, if user choose Africa Culture, the interface will be a board drew on sand with several stones plus sounds of jungle, wild-animals...

−

'''Contact me to get more details'''

+

'''Mentor:'''

−

Name: Mr. Phan Quoc Huy

+

currently there is no mentor for this project, please go to kde mailing list and find one !!

−

Student in University Of Science, Ho Chi Minh city, Viet Nam

−

−

email: diepvien00thayh@gmail.com

−

−

'''Mentor:'''

−

Anyone find this is an interesting project please feel free to contact me, I'm very willing to implement it for KDE4.

[http://techbase.kde.org/Projects/Games/Proposed_Games#Robot_Battle_.28Programming_Game.29 Based on this idea] the robots game would be a cross between games and edu, a game where users would also learn some programming basics while they are building their robots for the competition.

+

+

'''Brief explanation:''' The idea is to develop a simple game loosely based on Robocode, where computer programmed robots created by the player can fight among themselves.

+

+

'''Expected results:''' A fully playable game which is also an opportunity for learning programming basics and provide infinite replayability.

+

+

'''Prerequisites:''' Strong C++/Qt skills

+

+

'''Mentor:''' To be picked among kdegames and kdeedu community

----

----

Line 1,065:

Line 1,149:

'''Mentors:''' Gilles Caulier (caulier dot gilles at gmail dot com)

'''Mentors:''' Gilles Caulier (caulier dot gilles at gmail dot com)

+

+

====Project: Face Recognition====

+

+

'''Project Information:''' Digikam is a photograph collection manager able to collect, organize and send pictures to some major web gallery services, like Picasa Web or Flickr. Face recognition is useful for it's purpose as it makes tagging people on photos really easy and painless. People with thousands of photos in their library would get much of the work needed to catalog them done by digikam right in the process of acquisition from media.

+

+

'''Expected results:''' The scope of this project is to implement in digikam a face recognition component (using Principal component analysis - PCA) which automatically tags faces when new photos are inserted. This is one of the highest priority feature request: wish 146288.

+

+

This component should be able to keep a little database of known faces and apply the related tags for them. When a face is not recognized in those present in the database, the face should however be selected and tagged manually by the user.

'''A brief explanation''': Teacher would like to create a geography test. Five questions will be about flags (set 1), five about language (set 2) and another five about culture (set 3). Teacher has more than 5 questions in each issue and he would like to each student answer to randomly taken 5 question from each issue, but general structure of test has to be 5 (flags) - 5 (language) - 5 (culture).

+

+

All the questions has to be stored in exam file.

+

+

'''Knowledge Pre-Requisite''': C++

+

+

'''Expected results''': Teacher can create some sets of questions and determine of how many questions in the every issue test will be built. Some questions may not belong to a any set (or belong to set called e.g. "general") so each student will answer to these.

+

+

=== Step ===

+

+

[http://edu.kde.org/step Step] is an interactive physical simulator for KDE.

+

+

====Project: 3d mode====

+

+

'''Brief explanation:'''

+

Implement physical simulation in 3d. This involves:

+

* convert all classes in StepCore to templates with dimension as a template parameter, implement specialized versions where required, modify meta-object system to handle it

+

* implement 3d mode in GUI: viewing and editing

+

+

'''Expected results:'''

+

Ability to create, edit and view 3d simulations in Step with the same set of objects as in 2d.

Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:

+

* investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at [http://elbeem.sourceforge.net/ elbeem] library from Blender)

These are a list of smaller ideas related to Step. You can use them as a tips for building your own project.

+

* use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)

* support for non-convex polygons (probably by implementing triangulation)

+

* optimize collision detection (AABB trees, etc.)

+

* finish friction and bounceness implementation in StepCore.

+

* collision callbacks in StepCore.

+

* framework for dynamic object creation/destruction in order to allow implementing particle emitters

+

* statistical models (for example prey/predator model)

+

If you have other ideas please feel free to propose them !

+

+

'''Mentor:''' Vladimir Kuznetsov <ks dot vladimir at gmail dot com>

+

+

===Kopete (IM Client)===

+

http://kopete.kde.org

+

====Project: Chat Room improvements====

+

'''A brief explanation''': Kopete has a great interface when it comes to one-to-one conversation. But chat room has a different workflow, and the current interface is not that much suitable. Additionally, the support of group chat in some protocol is quite poor or unfinished.

+

+

The goal is to improve the user interface for this special usage. This include a special mode for the chatwindow (ability to choose a different style). Suitable notifications mechanism. Good presentation in the contactlist for bookmarks or auto-join.

+

+

It may also include improving support in one protocol such as IRC or Jabber MUC

+

+

'''Expected results''': Kopete need to be usable in chat room with at least one protocol, with a polished interface. As great to use as any client designed for group chat.

+

+

'''Knowledge Pre-Requisite''': C++, Qt is a plus

+

+

'''Mentor:''' Olivier Goffart <ogoffart at kde dot org>

+

+

===Other===

+

+

====Project: Ultracopier====

+

'''Brief explanation:'''

+

Ultracopier is advanced copier, but it is written in Qt. The target is convert Qt part in KDE part and optimize it, while keep the Qt part for no KDE platform. The target is too found the best way for possibility of integrate ultracopier as on demand copier.

+

+

'''Knowledge prerequisite:'''

+

Knowledge of C++ and some familiarity with Qt, KDE and especially KIO and konqueror/dolphin plugin system.

+

+

'''Mentor:'''

+

BRULE Herman (alpha.super-one at laposte.net). You can contact my as instant messager: ICQ: 367926760 or msn: alpha_one_x86 at hotmail.fr

+

+

====Project: Social Desktop====

+

'''Brief explanation:'''

+

Bits and pieces needed to implement basic functionality of the Social Desktop

+

+

'''Expected results:'''

+

A couple of applets integrate information from OpenDesktop with information

+

about contacts that is already available on your local machine and on the web

+

(blogs, microblogs, maybe content from social networking sites such as facebook).

KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE. There has been a SoC in 2008 which has added basic NX support, but unfortunately the project is not finished yet. This project should build up on that work. The current work needs to be updated to the current state of the external libs, and everything needs to be polished after NX support is basically working.

+

+

'''Expected results:'''

+

Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.

+

Also part of the task is a documentation of external dependencies as help for distributions. At the moment there is not much documentation available.

+

+

'''Knowledge Prerequisites:''' Knowledge of the NX protocol (see http://www.gwright.org.uk/protocol.pdf for an older version of the protocol), C++/STL/Qt/KDE coding and cross platform coding.

KRunner has the potential to be awesome in its functionality as an interface for quick access to a wealth of information. However, in its current form, the only way to add functionality from the point of view of the user base is to write plugins, which requires a knowledge of C++ and the KDE framework. The project would be to create a scripting interface through a plugin, that uses Kross.

+

+

'''Expected results:'''

+

A plugin for KRunner that give access to the scripting interfaces provides by Kross, allowing users to simply drop a script in /usr/lib/kde4/ to behave like a normal compiled plugin. Also, a suite of scripts demonstrating the use of this new feature and greatly extending KRunner's functionality as a quick-use information-grabber.

libmbca/mobile-broadband-provider info is a database of connection parameters and supporting library for mobile broadband (cellular networking). This makes it easy for people to setup their datacard or phone to provide an Internet connection. This idea suggests integrating this database into the Network Management tool for KDE 4.

+

+

'''Expected results:'''

+

* UI components to access the provider info database

+

* Integration with the configuration module for Network Management

+

* Unit tests to ensure that Network Management is robust if the provider info database is corrupted.

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.

Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big!

If there is no specific contact given you can ask questions on the general KDE development list kde-devel@kde.org. See the KDE mailing lists page for information on available mailing lists and how to subscribe.

Brief explanation:
The Service should be able to parse WSDL files and let Plasmoids connect to the described Webservices as well as optionally announce itself to the local network over uPnp and/or zeroconf. Finally, a Service that announces itself and can send a widget over the wire to another Plasma instance would complete this project.

Brief explanation:
Plasma could offer a Media center mode, where features a really simple ui to browse media files and plasmoids that shows the actual media. All should be operable with mouse, keyboard or a simple remote control. the work could consist in building the whole thing or just writing a plasmoid able to browse media files, that is the most important missing part.
Mockups for it by Nuno Pinheiro can be seen here and here

Expected results:
An applet to browse and thumbnail media files, like the first mockup and control the actual media viewing applets, like the media player applet or the picture frame applet. At this stage the functionality will be really minimum

Brief explanation:
PlasMate is an application that gives people a way to start creating scripted plasmoids without worrying about anything except making their bits. It hides the whole metadata.desktop thing, the package layout details, making a Plasmoid package (aka "zipping up the directory"), uploading content and version control system.

Expected results:
Working application that one can do the tasks described above, making it easy to create and distribute a scripted plasmoid.

Brief explanation:
A layer over Qt Kinetic to provide a standardized set of "out of the box"
animations and bring them into libplasma. The work will be done with the Plasma developers to make this API as efficient as possible. The work will be based on Kinetic, the next framework for animations in Qt.

Expected results:
We can kill Plasma::Animator class. The goal is to bring fancy effects/animations in Plasma to have one of the best desktop ever.

Knowledge prerequisite:
Knowledge of C++, familiarity with QGraphicsView related classes and some familiarity with animations bits.

Brief explanation:
A set of Containments and Plasmoids specifically designed for primary school
students.

Expected results:
A simplified panel containment that contains basic launchers and user feedback
for the student, a widget that allows teachers to provide context-specific
sets of applications and documents to the student (context being a combination
of the student logged in and the current class subject), a widget that
provides some basic teacher->student communication and status (e.g. what the
current assignment is, how long the student has been logged in, etc) and
optionally some widgets that work with KDE edu apps.

Knowledge prerequisite:
Knowledge of C++.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Expected results:
A containment that provides a similar user experience to the Mac OS X dock:
application launchers that are also task bar entries when the application is
active and a separate area for widgets such as the trash, battery, etc.

Knowledge prerequisite:
Knowledge of C++.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Expected results:
A KDM screen that is rendered completely using Plasma. This means both using
libplasma in KDM for the log in screen as well as writing Plasmoids for
entering the user name and password, listing users, session switching, etc.
Some of these widgets already exist for the desktop shell, so in some cases
this will be simply integrating existing Plasmoids, but in other cases will
mean writing new ones from the ground up.

Knowledge prerequisite:
Knowledge of C++.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Brief explanation:
Raptor aims to deliver a new kind of launch menu system for KDE. It is designed with usability and beauty in mind.
Raptor-Menu does not try to be the final answer to the menu question, instead aspires to be the best answer we can give, merging many ideas form modern desktop launch menus.

Brief explanation:
A new widget explorer that supports both our own widgets as well as others
more seamlessly.

Expected results:
A usable and pretty browser for widgets that allows a user to see an icon or
snapshot of the widget, select a widget to be placed in a containment, search
for a widget based on name/description, sort the widgets into categories, rate
widgets and provide ways to launch the online browsers and installers for both
native Plasmoids as well as third party tools such as Google Gadgets (which is
already supported in the Package class). All the required support
functionality already exists, this project is really about creating a
beautiful and dynamic user interface for looking through a widget catalog that
looks "Plasma".

Knowledge prerequisite:
Knowledge of C++.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Brief explanation:
A comprehensive set of D-Bus interfaces for the plasma-desktop Plasma shell.

Expected results:
The D-Bus interface must provide access to the Corona (DesktopCorona class),
which in turn will list all existing Containments and allow Containments to be
added, removed, saved, etc.

A D-Bus interface for each existing Containment will be made available as
well, which will provide a standard set of tools including listing, adding and
removing widgets as well as positioning and sizing for PanelContaiments. Ways
to control the wallpaper, if any, will also be provided in the per-Containment
D-Bus interface. A KRunner plugin make an easy to discover way to offer this functionality directly to the user.

In turn, a D-Bus interface for each widget representing its available
contextual actions will be provided dynamically upon request.

Finally, the application D-Bus interface for things such as locking/unlocking
widgets will be designed and implemented.

The result will be a Plasma that is fully accessible via D-Bus.

Knowledge prerequisite:
Knowledge of C++.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Brief explanation:
A set of methods to define the existing security state of the Plasma
application, the security requirements of individual widgets, mechanisms to
respect those two sets of information and cryptographic signing of Plasmoid
packages.

Expected results:
A set of functionality descriptions will be enumerated (e.g. "Network access",
"Local file system access", etc.). Individual widgets will advertise which of
these functionality sets they require.

The plasma-overlay shell (used on the screensaver) will have code added to it
to respect these settings and not run widgets that advertise they need things
that aren't safe to provide on a screensaver (due to it being locked to
prevent others from accessing the system).

The plasma-desktop shell will gain the ability to be put into various lock down
states which will map to different sets of functionality. Part of this project
will be enumerate the various states, but that list must include "only load
trusted widgets", "no external access", "no local file system access".

The JavaScript engine will provide methods for each of the functionality sets
(e.g. a set of functions to access local files) which will be exported or not
based on the current Security state. This implies providing a security state
to the Corona which can then be passed on down to Applets and AppletScripts.

Finally, GPG signing of Plasmoid packages will be implemented along with a way
of checking the validity of these at runtime.

Knowledge prerequisite:
Knowledge of C++ and some experience with security.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Brief explanation:
The user has a system with limited resources, and lots of activities. It must be possible to close the ones that haven't been used recently, but not delete them forever.
The user has a really cool setup, and a friend wants to get one of his/her activities.

Expected results:
The idea is to save out the containment's config to another file (in $APPDATA or something for use case 1) and remove it, then when the user wants to load a saved containment we give them a list of the saved containments (plus an option to load from any file), then pull in the one they choose. If they choose one from the list then we remove that file so that they don't get multiple copies of the same activity.

Knowledge prerequisite:
Knowledge of C++ and Qt.

Mentor:
Plasma team. Contact at plasma-devel@kde.org or #plasma on freenode.

Brief explanation:
Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client or possibly a UPnP media server would be useful. In addition to that controlling a UPnP Media Renderer from within Amarok is possible with framework support.

The Coherence server would likely be used since it is also intended to be used by a KIO slave.

Expected results:

Using the Amarok Collection framework, create a plugin which allows Amarok to browse, search and play music off of a UPnP share. Playing music may use the UPnP KIO-slave, but more advanced functionality requires Amarok to handle this directly.

Allow Amarok to share it's collection with other devices or control other devices via UPnP. This is secondary priority but it may be pretty easy with Coherence.

Brief Explanation:
The Context View (CV) is currently used to display multiple applets that expose various information. However, due to the fact that each applet displays a certain type of information from one data source, there is significant amount of wasted space, and it is hard to show much more than 3 different pieces of data at once.

Meta-Applets are large applets that integrate date from multiple data sources in order to display more semantically related information coherently and efficiently. This could mean, for example, an applet that brings together lyrics, artist info, upcoming concerts, and related songs/artists.

Brief explanation:
Amarok currently has no automatic code regression testing ("unit testing") in place at all. We very much need such a system in place (for as many components as possible), as we sometimes accidentally break certain components of the program by extending the code.

Expected results:
Code regression test suite for Amarok 2, implemented as one "Amarok-Script" (JavaScript), and internally split into multiple separate files and components, so that it would be possible to run arbitray tests (or the full suite) with very little effort, and no compiling, at any time. A requirement would also be testing of the collection scanning code (with test case collections), and testing of GUI correctness with the QTest library.

Brief explanation:
In Amarok 2.1, the layout of the playlist will be very configurable, being able to show as much or as little information about each track as each user might wish. Currently however, it is lacking an advanced system for sorting in the playlist, something that many users comming from Amarok 1 are missing. While simple sorting is relatively easy to do (and has already been partly implemented) we would like to aim a bit higher with Amarok 2.

Expected results:
A proxy model allowing the tracks in the playlist to be sorted using an arbitrary number of "layered" sort criteria. for instance, a sort setup could be "artist-album-tracknumber" This would sort all tracks by artist, then sort the tracks from each artist by album, and finally the tracks from each album based on track number. Once this model is working, a GUI is needed for making this functionality easilly avaialble to the user. Ideally this gui should tie in well with the playlist layout and search/filter stuff. Also, all track navigators (the classes that determines the order of playback, such as normal, random, random album and so on) need to be updated to use and work correctly with the new proxy model.

Brief explanation:
Mediadevices and services can add tracks and playlists to Amarok. Synchronization would automatically copy over tracks between the main Amarok Collection and devices or services or even between each other, either for a single playlist or the complete collection.
An algorithm needs to be implemented that does this automatically in a fast and efficient way with minimal intervention needed by the user.

Expected results:
Playlists set up on both the local collection and a portable mediaplayer will get synchronized the moment the player is connected.

Brief Explanation:
Many Amarok users will remember the support for Musicbrainz in the 1.x series. These intrepid users might also remember how it worked approximately 50% of the time, sometimes deciding on a whim that divulging the secrets of the correct tags would be too much to share. In Amarok 2 we have decided to skip integration with Musicbrainz as a result of our problems using the library etc.

Luckily, Last.fm provides a fingerprinting service, similar to musicbrainz, that will allow us to look up track data. However, the real challenge for the summer is not writing the code to allow Amarok to tag individual tracks, but rather how to present a mass-tagging interface in a aesthetically pleasing and usable way.

This project involves designing and implementing a UI for mass-tagging of tracks, and requires the student to interact with usability experts and visual designers as well.

Expected Results:
Mass-tagging functionality in Amarok using data from Last.fm

Brief Explanation:
Improve the handling of albums with several artists in Amarok.

The Various Artists / Compilations support in Amarok 2 is far from at the level at which it was in Amarok 1.x, and really is mostly just lacking completely. It desperately needs a student who is passionate about various artist support and wishes to dedicate his/her summer to fixing it :)

With regard to the technical details, the potential student is recommended to look at the "Various Artists in Amarok 2.0" thread here: december mailing list archives to craft some sort of concrete proposal.

This is definitely a project that would involve deep changes in Amarok, so a serious and dedicated student is important. Also, close discussion with the Amarok devs on amarok@kde.org during the proposal process will help to outline what is reasonable and desirable for a summer of work.

Expected Results:
Elegant and subtle handling of Various Artists support in Amarok 2.x

Brief explanation:
Applications such as Amarok and Dragon Player cannot have an analyzer or visualizations since they use Phonon which does not yet have the functionality to do it. The analyzer is the little bar graph thing which bounces around while music is playing. Users like it as its pretty and gives them a visual indication of their music playing.

Expected results:
As this project is working on extending a library, it has three parts: the Phonon library itself, a Phonon backend, and an application. The Phonon library would need the new API calls. At least phonon-xine and preferably 1 or 2 other Phonon backends must then implement the new API. An application like Amarok or Dragon Player should be used to demonstrate the use of the new API.

Knowledge Prerequisite: C++ and Qt. Experience with Xine or GStreamer is probably useful.

Mentor: Ian Monroe (contact on the Amarok mailing list) or possibly another Amarok or Phonon developer.

Brief explanation:
Satellite navigation devices have become widely used and the quality of openstreetmap data is becoming high, with some cities completely mapped already. Providing satellite navigation would be a useful desktop app for many as well as adding appeal for the use of KDE in embedded devices.

It also opens the possibility to bringing many of the free software ideals to interaction with the real world such as collaborative/social POIs.

Expected results:
The project would aim at getting a basic satellite navigation application running. The most basic features required would be getting the current location from a GPS device and providing route calculation to a destination.

The AndNav project (http://andnav.org) has already achieved something similar for Android so it could be a point of reference for how to use OpenStreetMap data to achieve this. A possible approach would be to use vector tiles from Cloudmade.

Knowledge Prerequisite: C++ and Qt. Experience with GPS devices under linux would be beneficial. Knowing java may also be of benefit in order to study the AndNav implementation.

Mentor: I (Alan Jones, skyphyr using gmail) am willing to mentor, but not having any GPS or Marble experience there is most likely somebody far more suited to undertake this role.

Comment from a Marble Project guy: Alan, please get in touch with the Marble Project. Our mailing list is marble-devel@kde.org. We'd like to support this project if a student is willing to do it.

Brief explanation:
Wouldn't it be great to be able to see the world at different times in Marble? Like having a slider which would give you the ability to browse through the time? Marble's internal datastructure is modelled after KML. But support for time-related tags is missing.

Expected results:

Having a GUI on the map and as a QWidget based dialog which allows people to "slide" through time.

Implementation of the KML <TimePrimitive> and <TimeSpan> tag: Creating the KML-handler and needed data classes for the GeoData parser.

Having a central "internal" clock which the current view would be based on.

Porting existing features (like the starry sky and the sun shading) over to the new class design.

Knowledge Prerequisite: C++ and Qt. Knowledge about KML is not necessary but would be appreciated.

Brief explanation:
These days there are several freely available 360deg panorama photos available on the internet. For other planets (like Mars) there are several panorama photos available for the numerous landing sites.

Some of them are geo-referenced already. So it would be nice if it would be possible to add placemarks to Marble which get associated with the Panorama picture.
Another "trimmed down" MarbleWidget instance could be used as a Panorama picture viewer: it would show these panorama photos either in equirectangular or spherical projection depending on the type of panorama photo.

Expected results:

Locations of panorama photos get fed as a KML file and appear on the Marble Widget.

The user can click on such Panorama placemarks

The photo gets downloaded in the background

A new modal dialog appears which technically shows another instance of a MarbleWidget that displays the Panorama photo. The Settings of the MarbleWidget would need to default to some configuration that doesn't show all the planet-specific floatitems and properties (like the graticule, etc.)

The user is able to navigate inside this window (up, down, left, right, zoom in/out).

The user is able to close the panorama viewer and returns to the Marble application.

Knowledge Prerequisite: C++ and Qt. Knowledge about KML is not necessary but would be appreciated.

Brief explanation:
There are several sources for freely available weather data on the internet. It should also be possible to display these weather information in Marble as little sun icons and temperature information in the map. Additionally it could be possible to display forecasts based on the Marble time support.

Expected results:

Weather information gets fed from the weather service.

The weather information, such as temperature and cloud status, are displayed in the marble map.

The user can click on the icons to get further information like air pressure.

The shown weather information depends on the time that is currently shown by Marble.

Perhaps it could be possible to show also historical values.

Perhaps it is possible to build a weather plasmoid based on this feature.

KStars is a Desktop Planetarium for KDE. It displays a map of the sky and provides a lot of tools to learn astronomy, or to calculate and predict astronomical phenomena. See [The KStars Homepage] for more information.

Brief explanation: Amateur Astronomy (which is one of the important use-cases of KStars) is typically done in groups. KStars permits users to save their own observing logs. It would be nicer if the user could share his observing logs with other users and see other observers' logs within KStars. It would also be nice if KStars had a map (using MarbleWidget) to display various Astronomy-related establishments (like amateur associations, observatories, research institutes). Another possible idea could be an observing report generator that would generate a report based on observing logs, and at the user's will, share it / post it on the internet.

The first step in this project would probably be evaluating existing XML-based formats for interchange of observing logs like the [COMAST XML Schema]. If nothing fits our purpose (which is unlikely), we might need to create a new format. The next step would be to make a user interface to store one's own log and retrieve other users' logs in this format. Then, you could proceed with an observing report generator or something. Further development of these ideas is left to the student.

Expected results: Implement some features that will make it easier for users of KStars and amateur astronomers to collaborate, as suggested above.

Knowledge Pre-Requisite: Required: C++. Prior knowledge of KIO_HTTP will help. Ability to grasp XML specifications from documentation will help too.

Project Information: KStars is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful.

Brief explanation: We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset). One could also think of using Qt-GL rendering optionally.

Expected results: Successful implementation of any of these ideas to make KStars more beautiful.

Project Information: KStars is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better.

Brief explanation: A printed star chart should at least include a legend explaining the symbols, and provide some information on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.

Project Information: KStars is a Desktop Planetarium for KDE. Currently KStars loads some star catalogs that are made available in a KStars native format.

Brief Explanation: KStars currently loads Tycho-2 and parts of USNO NOMAD catalog of stars. These catalogs are required to be in KStars' native format which uses the Hirearcheal Triangular Mesh to index regions in the sky. Popular star catalogs like USNO A organize stars and divide the sky into regions differently. Most users of astronomy software typically have one of these popular catalogs downloaded, and it would be great if KStars could support them somehow. While ability to read the non-native catalogs straight off is desirable, tools to convert these catalogs into KStars' native format would also help.

Expected Results: Implement support for at least the most popular catalogs like USNO-A2.0, Stellarium's Extra catalog, Cartes du Ciel's Tycho and Tycho-2 catalogs.

Knowledge Pre-Requisite: Required: C++. Ability to read documentation and quickly understand the existing code and ability to deal with binary files will help.

Project Information: KStars is a Desktop Planetarium for KDE. Currently KStars does not explicitely use vector instructions or thread.

Brief Explanation: To load catalogs, calculate the position of the celestial bodies, etc. KStars currently treats each object one after the other. With the increasing presence of vector units in modern CPU and the advent of CPU having multiple cores, KStars underexploits them. KStars could be made faster using vector instructions (by the way of Eigen 2 for instance for good performance and easy maintainability) and threads (using Threadweaver). This project complements the “Prettyfication” project that would use OpenGL to render the sky.

Expected Results: KStars is faster to load, add catalogs, can display more stars simultaneously while still being smooth.

Project Information:
The goal of this project is to integrate Strigi as backend behind the periodic table and the glossary (and possible other elements).

Brief explanation:
The idea here is to have a GUI element that shows Strigi search results based on the element selected from the periodic table, or the item from the glossary, found on the users desktop. For element, this would include the elements name, and possible even the element symbol, if integration with last years Strigi-Chemistry GSoC project is achieved. For glossary items, a simple text search would suffice.

Another idea is to make it possible to querry like this: "Give me all molecules with a molecularweigth of 123u and at least one Carbon atom". For this we can use the Chemical File Database (or of course every other database, even those for proteins.

Expected results:

provide GUI for Strigi search results for an element selected in the periodic table

Project Information:
Many parts of Kalzium could need a fresh up of the interface. For example, the main table should be written using Qt Model/View technique and for example use SVGs as a background. A first (uncomplete but working) code is already existing.

At the same time, many dialogs are not as beautiful as they could be. This project could also include the creation of a "simplified Kalzium" mode in which some parts of the feature set are hidden; this would be good for schools.

A third idea is to make more use of Plasma, for example improve the already written Plasmoids and/or extent Kalzium so that a Plasmoid could open a information dialog using Kalzium.

Expected results:
Depending on the chosen project for example a cleaned up codebase with an improved interface.

Project Information:
Kalzium already has a basic mass calculator for molecules (in the sidebar). The goal of this project would be to add full-blown widget that allows users to calculate masses of molecules, do calculations with them, calculate concentrations (mol/l, g/l..) of solutions...
ChemicalDataObject already has the needed data to achieve this, there's a parser for molecule formulas, so the project's goal is to make a nice GUI and of course write code that uses that data in the good way.

Expected results:
An easy-to-use (multi-tabbed?) window, where users can enter what they know (molecule name and number of grams...), pick what they want to know (number of mols).

Rocs is a Graph Algorithm Testbed for universities. It aims to give the students a place to visualize the results of the algorithms, so it doesn`t provide any, instead there`s a place for the studant to write them down and see what happened.

KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages.

Brief explanation:
C++ support in KDevelop is already highly advanced, often equalling or surpassing what the user and compiler understand about the code. A few refactoring tools have been developed already, but they have been constructed in a crude fashion, generating code via string concatenation.

This project would aim to create a new system to implement refactoring tools, and to create, test and deploy several advanced refactoring tools for c++.

Expected results:
A library would be created to enable refactoring based on the c++ AST (abstract syntax tree). A reverse parser (AST to code) already exists, but classes would be created to allow programatic manipulation of an AST. Optionally this library would also cover a generic framework based on the duchain which would be re-usable by other languages and make refactoring plugins easier to develop and partially shareable between languages.

Brief explanation:
KDevelop has a fairly comprehensive model of the user's codebase, however at this point it has not been fully exposed to the user. In order to visualize the code, the user currently has to use the code browser, which can only show one context/declaration at a time.

This project would aim to create a graphical visualization of the code structure, and allow much more powerful navigation of the code.

Expected results:
Using graphicsview, a widget would be created which shows the code browser's current context or declaration, in a control flow graph. It would be able to zoom out, pan, etc... loading data as required from the definition-use chain in a separate thread. There could also have a separate view to show code structure. Refactoring and other tools would be made more accessible using this widget.

Other ideas for utility of the widget include linking with the debugger and/or callgrind tools to show how the program has/is being executed, which areas need optimization, etc.

Investigation could be performed into reuse of code from the Umbrello project, if suitable to kdevelop's design.

See the Definition Use Chain documents for the api which contains the information about the code structure.

Knowledge Prerequisite: C++ and Qt. Experience with graphics technologies would be a bonus.

Brief explanation:
KDevelop's libraries are ready to support integration of languages other than C++. C# support already in place includes the lexer, preprocessor, parser, and basic definition-use chain creator.

This project would aim to make KDevelop a viable alternative IDE for C# development.

Expected results:
The C# support plugin needs the following work, the project may incorporate some or all areas:

Locate and parse inbuilt language api and linked libraries.

Implementation of an expression visitor, so that uses and types can be calculated

Implement code completion (based on existing KDevelop code completion api) such that the completion list is accurate for the context in which it is executed (integrate the expression visitor)

Integration of documentation

General c# support bug fixing

c# build system(s) support, if required

Refactoring and/or code generation support

Knowledge Prerequisite: C++ and Qt. Experience with C# / Mono and/or parsers would be a bonus.

Explanation: The OpenDocument specification doesn't include support for multiple versions of the same document in a single file. But that feature is supported by OpenOffice.org. The objective for this Summer of Code is to add support for that versioning system in KOffice. Since KOffice shares the OpenDocument loading/saving code, it should be possible to add this support in every KOffice application in one Summer of Code.

Expected results: Being able to load a specific version of a file, and create/manage versions

Knowledge Pre-Requisite: C++, excellent english reading skills.

Project: Add support for e-book formats to KOffice.

Brief explanation: Add a new export for one or more formats that are specifically tuned for e-book devices.

With the increased popularity of ebook readers there is going to be a need for tools to create ebook content. While most e-book devices can display PDF there are in fact a lot more formats in use. One such format is .epub, which allows reflowable content (unlike PDF). The format itself is based on XML and uses style sheets (CSS) to format content. There are few free software tools that can generate and manipulate this format and those that exist are restricted to command line.

Since most people creating content will most likely want to use an office suite or word processor to make documents it makes sense to add an export option for this format to KOffice.

Explanation: KOffice can already load and save most of the shapes that ODF defines. Still a few features are missing especially text on shapes, but also caption, title, description and the measure shape.

Expected results: The project should implement the mentioned features and it should be possible to load, save and easily edit them

Explenation: The modern way of a summary is a tag cloud/concordance graph a la Wordle.net. This to a document in many cases makes way more sense than a table of content or index - its like an instant summary based on the actual text. It is used in so many web content systems that it is really weird there is no Office suite that offers it for regular office documents. The SoC project would work on an interface to control tag clouds in documents it a little better than in web apps - say by setting the amount of cloud items you want, have a user-editable list of words you want to keep out (or add), add icons/image alternates, change the weight of things you want to be more visible, drag and drop reordering of cloud text, font and styling preferences.

Explanation: From some years ago another gSoc project implemented the basis for powerpoint import, but it was never finished. So there is a good basis to start from. From a quick look it seems like styles support is the thing missing most to complete the work, however a thorough analysis of what is there and what is not needs to be done. And then the actual work needs to be done too, obviously

Project information: Krita's current tile engine suffers from some limitations, like extensive locking. A new tile engine should offer some compelling features, like mipmapping, tile aging, in-memory compression, lock-free access of tiles, as efficient as possible undo information, pluggable backends (like png or tiff). See for a short summary http://wiki.koffice.org/index.php?title=Krita/Akademy_2007_Meeting#tile_backend.
Expected Results: an production-ready implementation having these features.

Knowledge Prerequisite: This is a difficult, ambitious project. Applicants should have a good knowledge of C++, data structures and be aware of existing literature on this subject and have a knowledge of graphics applications.

Project: Sketch-pad interface for Krita

Project Information: Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.

Expected results: This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.

Knowledge Pre-Requisite: C++

Project: Shader filters and generators for Krita

Project Information: Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.

Expected results: The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.

Knowledge Pre-Requisite: C++, OpenGL.

Project: Animation support

Project Information: There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.

Expected results: A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.

Knowledge Pre-Requisite: C++

Project: PSD and Gimp plugins

Project Information: Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.

Expected results: 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces. Ideally the project would also deliver a library to convert PSD/XF to/from Open Raster files.

Knowledge Pre-Requisite: C++

Project: Workspaces

Project Information: A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.

Expected results: the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.

Knowledge Pre-Requisite: C++, artistic workflow

Project: Kipi and digikam plugins compatibility

Project Information: Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.

Expected results: Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.

Project Information: In KOffice 1.6 Kivio provided tools and stencils for editing flowcharts. Flake already provides the the building blocks: shapes, glue points and a connector shape. Goal of the project is to recreate old functionality based on flake.

Expected results: Import of the Kivio stencil format. A docker that allows to handle collections of stencils. Implementation of a connector tool, that can easily connect different shapes.

Brief explanation:
An Akonadi Agent is a service process for performing tasks on data provided through the Akonadi server.

The task of a Janitor agent would be to keep the user's PIM data neatly organized, for example deleting news feed items which are above a certain age and not flagged, moving last week's mail to an archive, etc.

Expected results:

An Akonadi Agent capable of managing actions on Akonadi collections triggered by various criteria

At least fully working implementation of actions based on "Expire" criterias for mail, e.g. delete mail above certain age, move/copy to different collection, etc

GUI for configuring actions and their trigger criteria.

Knowledge Prerequisite: C++ and Qt. Ideally would already have gone through the Akonadi Resource Tutorial since Resources are a specialized form of agents and thus share some of the API and characteristics.

Brief explanation:
Akonadi has a server/client like architecture where clients such as applications (but also resource) connect to a service and communicate with it through a suitable protocol.

Currently this is implemented for KDE in library called libakonadi-kde, however it is desirable to have additional implementations to be suitable for other library stacks, e.g. GLib/GObject based ones.

Brief explanation:
Akonadi provides a structure of collections and items, similar to folders and files of a filesystem. Similarly the internal structures have to follow certain constraints which must not be violated. Nevertheless, this can happen as result of bugs, hardware failures, power loss and a million other reasons.

Filesystem checks exist to detect and possibly fix such situations. Such functionality would also be desirable for Akonadi.

Expected results:

A consistency checker (built into the Akonadi server or stand-alone) that performs an extensible set of checks on the internal data structures of the Akonadi server, such as:

items belong to existing collections

collections are child collections of existing collections

the collection tree is non-cyclic

every collections is owned by an existing resource

collection sub-trees are owned by the same resource

every item payload part belongs to an existing item

content type constraints of collections are not violated

...

each check should be accompanied with recovery code, such as moving orphaned items into a lost+found folder

Most of this will probably be done as part of an NLnet project, see this announcement.

Brief explanation:
KMail stores its mail in a folder hierachy where each folder can contain mails and further sub folders.

While mails are stored either as mbox or maildir, additional index files are used to speed up message listing and to store message status and flags.

The already existing Akonadi MailDir resource can handle the maildir aspects but cannot handle either mbox based folders nor the additional information stored in the index files.

Expected results:

a set of classes, probably as a library, capable of

recursively listing the KMail folder tree given a base directory

reading mails from the mbox and maildir folders in the KMail folder tree

reading KMail index files

an Akonadi resource using these classes to provide read-only access to all mails currently handled by KMail. The resource should also be able to transfer the flags stored in KMail's index file to Akonadi.

Writing a migrator, similar to the current KResource->Akonadi migrator, that automatically reads the KMail config file and creates a Akonadi resource out of it. Optionally, depending on the overall progress, the migrator would also convert some of KMail's folder settings, like the folder icon or the expiry settings, to Akonadi collection attributes.

Knowledge Prerequisite: C++ and Qt mandatory, code analysis skills would be helpful regarding the handling of index files, refactoring skills if KMail's classes are to be extracted from KMail's code base (not required).

Brief explanation: Improve the HTML support in KMail, especially making it possible to preserve the HTML format when replying or inline forwarding.

While KMail's HTML support has been constantly improving, it still has some important bits missing and some minor bugs. The goal of this project would be to implement the missing features and do general bugfixing in the HTML support.

One of the biggest missing features, with over 1500 votes on bugzilla, is the ability to preserve the HTML format when replying or forwarding, which is often an essential requirement in some enterprises.

Recently, support for inline HTML images was added to KMail. This support needs a few improvements, like being able to put images in the signature or resizing the images.

Currently, KMail relies on QTextEdit::toHtml() to generate the HTML source. This however is very weak, as QTextEdit has some bugs and generally produces HTML that is only equaled by MS Word in its ugliness. Stephen Kelly has started some work to make this output nicer, and to produce other forms of markup, like text/enriched. This is achived by creating so-called rich-text builders. One goal would be to finish this work and integrate it into KMail.

Comment by Thomas; QTextEdit html generation is not optimal due to html simply not supporting all QTextEdit features. Qt45 choose to export to ODF instead. Maybe KMail should try to leverage this instead?

Other nice points would be to support the text/enriched format for reading or composing mails, and to support the text/flowed format when composing. Although this is not strictly HTML related, it would improve the experience for many people.

Of course, your own ideas are very welcome as well

Another idea, which invalidates most of this, is to use a Webkit-based editor, like described in this blog post.

Expected results:

Option to preserve the HTML format when replying or forwarding

Support inline images also in signatures

Improve inline image support by allowing to scale the images

Nicer HTML generation by completing and integrating the HTML builder from Stephen Kelly

Various bugfixes in the HTML support

Optionally, also support text/enriched as alternative to HTML (both reading and composing). See RFC 1896. Composing support can also be based on Stephen's builders.

[edit]Project: import/export for filtering rules in Sieve format in KMail

Sieve is a language for declaring mail filter rules on a mail server. It was developed as part of the Cyrus IMAP server, but was quickly spin off and turned into a standard (http://tools.ietf.org/html/rfc5228). There are quite a few servers that have support for Sieve, in various degrees of completeness. It is quickly gaining support. Clients that support it are KMail and Thunderbird.

KMail already has support for talking to Sieve enabled servers and also has support for client side filters. These two rule sets seem to be separate. It would be nice if you could dump the rules you have in one client and able to either install them on a server, or load them into another client, if you want to access your mail from different machines, but don't want to reconfigure your mail clients over and over again, or to quickly reconfigure clients if you don't have a Sieve enabled server.

Expected results:
Successful import and export of a (subset) of mail filtering rules between various KMail instances.

Brief explanation:
The porting efforts to make KDE available across platforms do need some backends for system dependent tasks. One of the KDE libraries that bundles this is Solid.

Expected results:
You implement a backend for the Solid API using WINAPI.
It has to work with both MinGW and MSVC compilers. Not every function is required, but the basic functionality (network access, removable drives/harddisks and power) should be implemented.

Knowledge Prerequisite: Windows API and C++/Qt. You should be able to set up the development environment yourself and be familiar with it.

Brief explanation:
Mancala is a family of board games played around the world, sometimes called "sowing" games, or "count-and-capture" games, which describes the game-play. Mancala games play a role in many African and some Asian societies comparable to that of chess in the West. The list of mancala games best known in the Western world includes Kalah and Oware. Other games are Congkak, Omweso, Ünee tugaluulakh, Bao, Sungka and Igisoro.

The word mancala comes from the Arabic word naqala meaning literally "to move." There is no one game with the name mancala; instead mancala is a type, or designation, of game. This word is used in Syria, Lebanon, and Egypt, but is not consistently applied to any one game.

In the USA, however, "mancala" is often used as a synonym for the game Kalah.

Expected results:
The aim of this project is developing Mancala game with lively interface that is changeable depend on the culture user chose to play. For example, if user choose Africa Culture, the interface will be a board drew on sand with several stones plus sounds of jungle, wild-animals...

Mentor:
currently there is no mentor for this project, please go to kde mailing list and find one !!

Brief explanation:
Kolf 2 is the second incarnation of KDE's minigolf game. We are currently rewriting it from scratch to take advantage of the powerful technologies provided by Qt 4 and KDE 4.

Expected results:
The task in this project is to create an object (or multiple objects) that provide(s) landscape textures, slopes, puddles and sand bunkers.

If you finish this task before the end of the summer, you can fill the remaining time by porting as much game objects from Kolf 1 to Kolf 2 as possible (e.g. windmills, floating blocks, signs or bumpers).

Knowledge Prerequisite: C++/Qt. Experiences in graphics programming with Qt will definitely help, as you are expected to implement 2D rendering for the landscape object.

Brief explanation:
The minigolf game Kolf provided an editor interface from the beginning, to allow the users to create custom courses. For Kolf 2, we are rewriting the game engine and can therefore not use the old editor code.

Expected results:
Your task would be to create an editor interface (may be embedded in the game, or a standalone application). A few basic parts are available, and the Kolf 2 engine supports generic methods to provide data to editor interfaces, and display editor overlays on the game view.

If you finish the editor interface before the end of the summer, you can fill the remaining time by porting as much game objects from Kolf 1 to Kolf 2 as possible (e.g. windmills, floating blocks, signs or bumpers), or using your editor to put together some cool courses.

Knowledge Prerequisite: C++/Qt. Experiences in model/view programming with Qt will be of good use.

Parsek is a client for playing 4X (explore, expand, exploit and exterminate) galaxy conquest strategy games, which are created using Thousand Parsec framework. You can think of it as an advanced version of Konquest.

Brief explanation: Parsek uses the existing C++ Thousand Parsec protocol library to create a KDE 4 graphical game client. The client is then used to connect to any game server running any game created using Thousand Parsec framework. Some code (you can find it in playground/games/parsek) is already written (to get object of the universe and messages) but you can't play the games yet. The student's task will be to bring Parsek at least to a state so that people would be able to play games with it.

Expected results: To be able to play games some features must be added: displaying a star-map, displaying object info in a nice way, displaying messages in a nice way, getting and displaying object orders, creating new orders. If there is some time left after before mentioned required features are implemented the student will work on additional optional features, for example: automatic discovery and display of game servers (on local network and/or from meta-server), game servers accounts manager, plug-in for game server administration, Plasma widget with overview and quick access to the games someone is playing, single-player wizard (to easily setup local server and AI clients)...

Brief explanation:
Because JavaScript frameworks have popularized access to parts of documents using various query languages, direct browser support for such queries
has become fairly common. This project is about adding support for one (or two) of such languages to KHTML. Basic implementation of each is expected to be simple, but there may be some interesting optimization opportunities to explore.

Expected results:
Implementations of XPath 1 or DOM selectors API at DOM level with appropriate JavaScript bindings that are standard-compliant, written in simple & maintainable fashion, and perform reasonably well.

Knowledge Prerequisite: C++, and some comfort with working with large codebases.

Brief explanation:
Adding UPnP support to Solid would mean offering transparent UPnP support to every KDE application using the Solid API, keeping them clean from every UPnP implementation aspect.
At the present, the Jolie language is being integrated with Plasma by means of the QtSodep library, soon to offer higher levels of abstraction.

The aim of this project would be to implement a UPnP protocol for Jolie, so that Solid could re-use the integration being made with QtSodep and gain UPnP support without having to worry about implementation details. Having a UPnP protocol implementation in Jolie would have other considerable consequences, like the possibility to act easily as a UPnP server or to compose and export existing UPnP services.

Expected results:

The creation of a "upnp" protocol in Jolie, supporting at least the Internet Gateway Device (IGD) and MediaServer profiles.

The creation of a UPnP Jolie service for UPnP service discovery and monitoring.

Extending libsolid to expose UPnP devices found on the network.

Material Prerequisite: Having UPnP devices or software applications to test with. Most home routers support IGD, and there exists free software supporting the MediaServer profile (mediatomb).

Knowledge Prerequisite: Understanding of the UPnP specifications, Java (for the development of the Jolie UPnP protocol) and basic knowledge of the Jolie language.

Brief explanation:
Window tabbing is a feature that allows you to group multiple application windows together to cover the same space. It is identical to what is already available in any modern web browser except it applies the the window as a whole. Window managers that have this feature available include Fluxbox and Ion. This feature was originally requested in 2002.

Knowledge Prerequisite: C++ and Qt. Understanding of the X window system and Xlib is a benefit but not required.

Brief explanation:
Window tiling is a technique of displaying application windows side-by-side without overlap. The position, size and layout of the windows can either be specified by the user or determined automatically to best fit the screen. Examples of existing tiling window managers include Awesome, XMonad, Ion and Ratpoison. One of the main advantages of tiling is that is makes application windows easy to navigate solely by the keyboard. This feature was originally requested in 2003.

Expected results:

Users should be able tile existing floating windows on-the-fly with simple keyboard shortcuts or mouse gestures.

It should also be possible to run the entire desktop environment entirely in tiled mode (Enabled by configuration settings). In this mode new window would be added to the tiling grid by default yet can be removed by the user if required.

The final tiling system should not interfere in any way with the existing floating window management.

Knowledge Prerequisite: C++ and Qt. Understanding of the X window system and Xlib is a benefit but not required.

Project Information: digiKam is an advanced digital photo management application for KDE, which makes importing and organizing digital photos a "snap". The photos are organized in albums which can be sorted chronologically, by folder layout or by custom collections. digiKam has an Image Editor which has its own plugin subsystem with some common tools e.g. red eye correction or Gamma correction. Additional plugins are provided with the main application to process advanced corrections on image like color management, noise reduction, or special effects. digiKam image editor support 16 bits color depth image internally. The goal of this project is to create a new plugin dedicated to create HDR image.

Expected results: This project should implement an HDR tool will mix two or more (nearly) identical images having different exposure into a new image representing a wider dynamic range, which is closer to human perception of a photographic scene. Tone-mapping method must be used to create HDR images. An open-source implementation is already available at this url and can be re-used as well. There is an old feature request.

Project Information: Digikam is a photograph collection manager able to collect, organize and send pictures to some major web gallery services, like Picasa Web or Flickr. Face recognition is useful for it's purpose as it makes tagging people on photos really easy and painless. People with thousands of photos in their library would get much of the work needed to catalog them done by digikam right in the process of acquisition from media.

Expected results: The scope of this project is to implement in digikam a face recognition component (using Principal component analysis - PCA) which automatically tags faces when new photos are inserted. This is one of the highest priority feature request: wish 146288.

This component should be able to keep a little database of known faces and apply the related tags for them. When a face is not recognized in those present in the database, the face should however be selected and tagged manually by the user.

Project Information: The Telepathy Framework allows for components which can watch channels whilst a user is interacting with them through another application. A program could be created to log the content of text instant messages into an Akonadi collection.

Expected results: This project should result in a telepathy watcher which is capable of logging the contents of text chats into an Akonadi collection. It should be possible to go off-the-record in a particular conversation from telepathy user interfaces and the logger should not save any messages in this situation. This project might also include modifying the Kopete logging plugin to use the same akonadi collection for logs, and making a migration tool from Kopete's old logging format to the new Akonadi collection.

Knowledge Pre-Requisite: C++/Qt, some basic knowledge of the Telepathy Framework is an advantage, but not necessary if you have an interest in real-time communcation and are prepared to learn fast.

Expected results: This project should result in a collaborative feature or instant messaging integration being added to the chosen KDE application. It should be complete enough to provide at least basic functionality to end users, with the possibility of further improvement after the summer of code period ends.

Knowledge Pre-Requisite: C++/Qt, some basic knowledge of the Telepathy Framework is an advantage, but not necessary if you have an interest in real-time communcation and are prepared to learn fast.

Mentors: George Goldberg (grundleborg at gmail dot com) IRC: grundleborg. You should also discuss your idea with the development team of the application in which you would like to provide a Telepathy feature.

Expected results: You should provide multiple points of integration between presence and contact information and plasma. Plasmoids allowing the display and manipulation of your own presence information should be made available, building on the plasma applets and datengines already in existance for presence information. Plasma activities could also be made aware of presence, and the contacts plasmoid could be made aware of your buddies from Telepathy instant messaging accounts.

Knowledge Pre-Requisite: C++/Qt

Mentors: George Goldberg (grundleborg at gmail dot com) IRC: grundleborg. You should also discuss your ideas with the plasma development team before making a proposal.

Brief Explanation:
The ideas is to have a sidebar on the desktop (see Plasma project above for example) which shows information about the resource in the current context. Examples include files or important emails from a specific person that sent the email I am currently reading. Or related information on a webpage I am currently browsing. Or the author information on a pdf I am reading. And so on.
The sidebar should pick up DBus signals that can be sent out by any application to change the current resource (this is just an idea).

Expected Results:
Creation of the sidebar and integration into at least two applications (like KMail or Okular) which will then update the resource in focus. It might also be good if the sidebar could monitor if the application that set the resource looses focus or is closed.

Brief Explanation:
Today we still save and load our documents using a file browser. We navigate through folder structures that we created and try to find the best spot for the document. Another way would be to store a document by specifying meta-data about it. We could for example set the type (not the mimetype but the actual type like it is a letter or an invoice or a holiday picture and so on) or set properties on the document like related projects, related persons, tags, and so on. The system would then store the document someplace (we don't care about that). Loading the document would work the same way: filter documents according to type, date, persons or any other property we might have chosen to describe it.
In KDE applications today can predefine the file extension. How about letting the application predefine a set of meta-data properties.

Expected Results:
A prototype for saving and loading documents via meta-data and at least one use case which is demoable.

Knowledge Pre-Requisite: C++/Qt/KDE, knowledge on ontologies and RDF are very helpful

Hints:
One might think of a plugin system here that allows to suggest annotations to the user. Compare the annotation system already in playground based on Nepomuk::Annotation.

Brief Explanation: KDE 4.2 contains a KIO slave which uses Nepomuk to provide virtual folders (nepomuksearch:/). It has not been deeply integrated into KDE yet (such as the file dialog or Dolphin). The project would change this situation and allow to browse virtual folders in addition to simply use it as a search client. Ideas include subfolders which sort by result type or allow to refine the search. Also interesting is the saving of virtual folders and a graphical interface to define searches (folders).

Expected Results: An improved version of the virtual folders which is highly usable without prior knowledge (such as the nepomuksearch:/ scheme). The possibilities are vast.

Brief Explanation: A bookmark plugin for konqueror, that creates a bookmark folder structure on the fly, out of the tags that are assigned to each bookmark-item.
A bookmark could be a local or remote file, of any kind: html/pdf/video/…
The tags could either be assigned by the user(with a very simple/quick interface), or just indexed automatically.

Expected Results: A virtual folder structure that would replace or supplement the current bookmarks toolbar. E.g. one could find the digikam web page either like:
Linux->KDE->multimedia->[digikam], or Photography->Programs->[digikam].
Because the bookmark has all these tags: Linux,KDE,multimedia,Photography,Programs.
An initial database could be created by importing the current bookmarks.xml file, using the directories as tags.

Brief Explanation: Using Nepomuk the user can create a lot of metadata such as tags and comments and in the future way more. All this data is important to the user and needs the same attention any other data gets. This includes backups and migration of data.

Expected Results: A Nepomuk service or application which provides a backup service for Nepomuk data. It would allow to manually backup and restore data, as well as automated ones. The service should not just backup everything but only that data which cannot be recreated easily (the latter includes data extracted by strigi).

Brief Explanation: Semantic queries can be very complex and having a user type in SPARQL or even something simpler can scare them away very easily. Thus, a visual query builder which can be reused by multiple applications and looks nice would help a lot.

Expected Results: A library which provides a nice GUI for users to define semantic Nepomuk queries.

Brief Explanation: We get new files from different sources all the time. This includes downloads, email attachments, pictures from a camera, but also files we create ourselves with applications like word processors or the like. It would be very helpful if the system supported the user in deciding how to categorize or annotate the new files. Based on source or application or storage folder or previously used annotations a non-intrusive dialog could propose certain annotations to the user.

Expected Results: A system which monitors for new files, decides if this is an interesting file (ignore log files and the like) and then proposes possible annotations to the user. This could include tags but also resource types (PIMO) or relations to other resources (such as projects or persons).

KMyMoney and Kraft are applications in the area of personal finance management: While KMyMoney is a full featured personal finance manager, Kraft is a tool for invoicing and more
for small enterprises.

Both applications deal with users financial data and integrate well in the KDE desktop for the benefit of the user.

Brief Explanation:
With the concrete example of KMyMoney and
Kraft a KDE global service should be developed which exchange financial information between these and possibly other applications on the KDE desktop.

KMyMoney helps the user to keep overview about his money dealing with all kinds of financial accounts and transactions. Kraft is an applicaton where invoices can be created. Once an invoice is sent out, a payment is expected. That is information KMyMoney should be aware of and list an expected payment. When KMyMoney gets knowledge of the payment (i.e. through online banking) the information should
go back to Kraft to mark the invoice as paid. For that a semi automatic identifier matching between incoming and expected payments must be implemented.

Other data should be shared through Fids like the users account information hold by KMyMoney. A desktop global unique number service for documents help the user to create correctly numbered documents through various applications like Kraft. The most challenging thing would be to provide country dependent tax information through Fids.

The financial transaction data might be best handled in an Akonadi plugin.

Expected Results:

KMyMoney and Kraft share information about sent out invoices which result in expected payments. If the money comes in Kraft needs a notification. For that a generic infrastructure, maybe based on Akonadi, must exist. The solution must not be limited to KMyMoney and Kraft but provide a generic solution for all KDE apps interested in financial data.

Knowledge Prerequisite: C++ and Qt. KMyMoney, Kraft and Akonadi knowledge could be useful.

Mentors: Klaas Freitag (freitag at kde org) and members of the KMyMoney
team.

Wishlist item 169511 discusses why it might be useful to record presentations. It is fairly easy to extract the timings from a recording, however it might also be useful to package up the complete presentation (slides, timing and audio).

An interesting idea is to make these into an Ogg container, using Ogg/Speex or Ogg/Vorbis for the audio, and Ogg/Kate for the slides. A proof-of-concept implementation of the timing + Ogg/Kate output is available in a branch. You'd need to find a way to record the presentation audio (e.g. extend Solid to detect audio input sources and Phonon to record)

A brief explanation: When teaching math (e.g. basic algebra or fractions) user has to type values manualy to each exercise. Using templates it would be much easier.
Math teacher could express an exercise of simple adding as:

Take 2 random, integer values (e.g.: x, y)

Both has to be between 1 and 15

Correct answer is a x+y

Let KEduca random some answers but only one can be correct

Suggestion: It would be good to make two types of templates: static, and dynamic. In dynamic one each time user open an exam variable's values are taken randomly. In static one: Values are written to exam file once.

Templates will be written in kind of pseudocode. It has to be As Easy As Possible in use.

Knowledge Pre-Requisite: C++, experience with parsers, Qt is a plus

Expected results: Teacher can prepare exams in math without any effort. Teacher can be sure that each student will recieve unique set of exercises.

Written pseudo scripting language for templates (other solutions are welcome)

A brief explanation: Teacher would like to create a geography test. Five questions will be about flags (set 1), five about language (set 2) and another five about culture (set 3). Teacher has more than 5 questions in each issue and he would like to each student answer to randomly taken 5 question from each issue, but general structure of test has to be 5 (flags) - 5 (language) - 5 (culture).

All the questions has to be stored in exam file.

Knowledge Pre-Requisite: C++

Expected results: Teacher can create some sets of questions and determine of how many questions in the every issue test will be built. Some questions may not belong to a any set (or belong to set called e.g. "general") so each student will answer to these.

Brief explanation:
Currently Step has molecular dynamics based simulation of gas and water (that is a gas is simulated as a collection of particles). This is very usefull for demonstrating microscopical properties of the gas as well as its connection with macroscopical quantities like temperature. But this is far from optimal to demonstrate things like a boat floating in the water, water flowing from a glass, etc. This project involves:

investigate fast methods of simulating water and gas: ranging from molecular dynamics but with simplified potentials, various optimizations, coarse graining methods, to lattice Boltzmann methods; investigate existing libraries for water simulation (for example take a look at elbeem library from Blender)

Brief explanation:
These are a list of smaller ideas related to Step. You can use them as a tips for building your own project.

use KAlgebra library for parsing user-supplied expressions in PropertiesBrowser; allow value in Meter, x- and y-values in Graph to be arbitrary expression; implement ParametricForce object that will apply a force given by user-supplied expression; implement a series of ParametricJoint objects that will allow creation of various parametric constraints (like fixed particle trajectory)

A brief explanation: Kopete has a great interface when it comes to one-to-one conversation. But chat room has a different workflow, and the current interface is not that much suitable. Additionally, the support of group chat in some protocol is quite poor or unfinished.

The goal is to improve the user interface for this special usage. This include a special mode for the chatwindow (ability to choose a different style). Suitable notifications mechanism. Good presentation in the contactlist for bookmarks or auto-join.

It may also include improving support in one protocol such as IRC or Jabber MUC

Expected results: Kopete need to be usable in chat room with at least one protocol, with a polished interface. As great to use as any client designed for group chat.

Brief explanation:
Ultracopier is advanced copier, but it is written in Qt. The target is convert Qt part in KDE part and optimize it, while keep the Qt part for no KDE platform. The target is too found the best way for possibility of integrate ultracopier as on demand copier.

Knowledge prerequisite:
Knowledge of C++ and some familiarity with Qt, KDE and especially KIO and konqueror/dolphin plugin system.

Mentor:
BRULE Herman (alpha.super-one at laposte.net). You can contact my as instant messager: ICQ: 367926760 or msn: alpha_one_x86 at hotmail.fr

Brief explanation:
Bits and pieces needed to implement basic functionality of the Social Desktop

Expected results:
A couple of applets integrate information from OpenDesktop with information
about contacts that is already available on your local machine and on the web
(blogs, microblogs, maybe content from social networking sites such as facebook).
A contact applet collates IM presence, addressbook data, and activity data
from opendesktop.
A clear concept of a Contact is needed, an ontology in Nepomuk will be created
for this. All information about a contact should be easily queriable via Nepomuk.

Brief explanation:
KRDC lacks NX support, which is gaining momentum in the free software world. Build upon the work done by George Wright in the 2006 SoC and the work done by Urs Wolfer in the 2007 SoC to create a top quality NX client for KDE. There has been a SoC in 2008 which has added basic NX support, but unfortunately the project is not finished yet. This project should build up on that work. The current work needs to be updated to the current state of the external libs, and everything needs to be polished after NX support is basically working.

Expected results:
Fully working NX integration for KRDC, including support for advanced NX features such as sound, VNC/RDP tunnelling etc. Feature parity with the commercial NX client shouldn't be necessary, but aiming for that isn't a bad idea. All NX connection handling code should be in the cross-platform client library nxcl (C++/STL/autotools), and all GUI specific code should be in KRDC.
Also part of the task is a documentation of external dependencies as help for distributions. At the moment there is not much documentation available.

Brief explanation:
KRunner has the potential to be awesome in its functionality as an interface for quick access to a wealth of information. However, in its current form, the only way to add functionality from the point of view of the user base is to write plugins, which requires a knowledge of C++ and the KDE framework. The project would be to create a scripting interface through a plugin, that uses Kross.

Expected results:
A plugin for KRunner that give access to the scripting interfaces provides by Kross, allowing users to simply drop a script in /usr/lib/kde4/ to behave like a normal compiled plugin. Also, a suite of scripts demonstrating the use of this new feature and greatly extending KRunner's functionality as a quick-use information-grabber.

libmbca/mobile-broadband-provider info is a database of connection parameters and supporting library for mobile broadband (cellular networking). This makes it easy for people to setup their datacard or phone to provide an Internet connection. This idea suggests integrating this database into the Network Management tool for KDE 4.

Expected results:

UI components to access the provider info database

Integration with the configuration module for Network Management

Unit tests to ensure that Network Management is robust if the provider info database is corrupted.