GSoC/2012/Ideas - KDE Community Wiki

Guidelines

Information for Students

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 [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.

Adding a Proposal

Note

Follow the template of other proposals!

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

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

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

If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.

Ideas

How to find ideas? To see previous Project ideas, see: 2011 ideas. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.

Amarok

Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it!

Website - Mailing list (for proposal submission) - Google+ page - IRC channel: #amarok on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Project: QMLify Amarok's context view

Brief explanation: Amarok's context view has been rewritten using Plasma for the beginning of the 2.x series. While this technical choice presented and still presents many advantages, the implementation has been lacking on some fronts for various reasons also unrelated to Plasma. The goal of this project is to rewrite and otherwise conceptually revamp the context view, basing it on QML. Specifically, we require a redesigned set of models, and a way to distribute 3rd party context view applets. Optionally, if there's time, a bit of interface work on new context view widgets would also be nice.

Some interesting reading:

Expected results: Amarok's context view, rewritten for QML.

Knowledge Prerequisite: C++ and Qt, QML and SPARQL knowledge a plus.

Mentor: TBD, certainly an Amarok core team member, contact Teo Mrnjavac or Bart Cerneels for details

Project: Semantic desktop collection in Amarok

Brief explanation: Several years ago a Summer of Code student had developed a Nepomuk collection backend for Amarok. At that time however Nepomuk was a very different beast, and mostly for performance and reliability reasons the work was never used. The goal of this project is to pick either Tracker or Nepomuk (or both!) and develop one or more collection backends for those data stores.

Expected results: At least one fully working collection backend based on Nepomuk or Tracker.

Knowledge Prerequisite: C++ knowledge, Qt recommended, Nepomuk/Tracker/SPARQL knowledge a plus

Mentor: Teo Mrnjavac, maybe also someone from Nepomuk?

Project: Tomahawk features in Amarok

Brief explanation: Tomahawk is a cross platform, open source social media player that allows users to share music seamlessly and listen to it anytime, anywhere. The goal of this project is to implement the same features in Amarok and maintain compatibility with Tomahawk

Expected results: Implement a service in Amarok that allows users to share their music files with online friends and allows them to listen to the tracks via stream

Knowledge Prerequisite: Qt/KDE development(includes C++ and git), streaming

Mentor: Bart Cerneels

Project: Amarok unit testing

Brief explanation: Since recently Amarok has a continuous integration system. This is awesome, but we can hardly exploit its advantages without good unit test coverage. Amarok does have some unit tests, but they are few and mostly out of date. The goal of this project is to assess the current unit testing situation and provide lots and lots of high quality unit tests (and related documentation).

Expected results: Write an agreed-upon number of unit tests that cover speficic Amarok functionality. We expect a list of the exact features/classes the student will write tests for detailed in the project proposal. Functionality in src/core and src/core-impl takes precedence.

Knowledge Prerequisite: C++, Qt and unit testing knowledge a plus

Mentor: An Amarok core team member, contact Teo Mrnjavac for details

digiKam

digiKam is an advanced digital photo management application for Linux, Windows, and Mac-OSX.

digiKam project web site - Mailinglist - Google+ page - IRC channel: #digikam on Freenode

Project: Camera User Interface Revamp

Brief explanation: digiKam features a graphical interface to access and download pictures from digital cameras. Code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.

This project would involve taking the old code apart, rewriting a clean code base backend and front-end, but also adding user interface elements to make the most important everyday task as easy as possible.

In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and GPhoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code re-use, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.

User Interface design: the current one is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.

It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.

There also the technical TODO list relevant of this project

Expected results: A camera user interface based on a pure Qt4 model/view and a cleaned code which provides the currently available features, offering a quick path to download new pictures.

Knowledge Prerequisite: Qt, C++. Interest in Qt model/view and User Interface code.

Mentor: Gilles Caulier

Project: Native MacOSX support

Brief explanation:

digiKam needs to be available under MacOSX in native. Currently, - Macports project is the only way to get last digiKam under Apple computers. Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.

Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system. Graphical interface need to polished.

See relevant entries in KDE bugzilla about MacOSX support :

257679 257773

Expected results: Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX. Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.

Knowledge Prerequisite: C++, Qt, MacOSX, scripting, DMG, packaging

Mentor: Gilles Caulier

Project: Video metadata support

Brief explanation:

All recent digital-still camera devices provide video capture. digiKam must be able to manage these files as it do with images. digiKam can already play-back video and register files to the database, but it lack important metadata used to catalog and sort items (as date, camera name, and all record conditions).

To improve video files support, video metadata management done in background need to be improved, to patch Exiv2 shared library, already used by digiKam for photo metadata handling.

See relevant entries in KDE bugzilla about video support :

164442 229543

Expected results: Add video files support to Exiv2. Patch digiKam metadata interface to handle video information.

Knowledge Prerequisite: C++, Qt, video format, metadata

Mentor: Gilles Caulier and Andreas Huggel

Project: Clone Tool for Image Editor

Brief explanation:

In digiKam image editor we need a simple clone tool to be able to remove quickly dusts, spots, and other unwanted artefact from an image.

See relevant entry in KDE bugzilla about it :

132483

Expected results: add a new tool (as new image editor plugin) with the clone feature.

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier or Marcel Wiesweg

Project: Video Slideshow Generator

Brief explanation: In digiKam image editor we need a new tool to export images as video slideshow.

See relevant entry in KDE bugzilla about it :

153061

The tool must be able to export to video files, as MPEG, AVI, DIVX, or to video media, as CD and DVD video.

Expected results: Add a new tool (as new kipi plugin) to export image collections on video. The tool must be able to do authoring with image contents, for example to change order of images, slide time pause, add transition effects, and add main menu for video media. Too, tool must be able to add audio files as a background. The tool must be portable under Linux, MacOSX and Windows.

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier and Angelo Naselli

Project: Face Recognition

Brief explanation: digiKam is already able to detect faces in photos, through libface, OpenCV, and libkface shared libraries, but Face Recognition is not yet properly implemented to identify the person depicted and automatically tag the region on the photo with the person's name.

See relevant entry in KDE bugzilla about it :

271679

Expected results:

Face Recognition: Improve existing Eigenfaces implementation. Implement Fisherfaces recognition, work with GNU science library to implement the needed QZ algorithm.
Round up this underlying technology in a libface and libkface library with some test cases.
optionally, define the format to store tags on regions of images (currently it's only possible to tag an image as a whole) in metadata and database. You will get support here from the digikam core developers.
Design some user interface solutions for the training tasks involved (telling the classifier what's right and what's wrong)

Knowledge Prerequisite: C++ and Qt. Knowledge of matrices and working with them. Some idea of clustering algorithms and previous OpenCV experience would be useful.

Mentor: Alex Jironkin for face recognition part through libface, Marcel Wiesweg and Gilles Caulier for the digikam integration through libkface interface.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Marble

Marble is a Virtual Globe and World Atlas. It runs on Desktop systems (Linux, Windows, Mac) and mobile devices (Nokia N900, N9).

Project: OpenStreetMap vector rendering with tiling support (draft)

Brief explanation: Marble supports general vector rendering and basic vector rendering for OpenStreetMap. Currently OSM data must be downloaded and opened manually by the user. During this project a tiling scheme (separation of OSM data into small rectangular regions with different zoom levels) should be developed such that Marble can open and display the right part of the map without any further user interaction (other than panning/zooming).

Develop a tiling scheme that maps lon/lat/zoom tuples to filenames and vice versa
Use a tool like osmosis to create tiles for a sample region (say, the city you live in)
Extend Marble's .dgml format to be able to specify .osm files as input (and your tiling scheme)
Improve the current vector rendering to handle different zoom levels better
Add more OSM elements for vector rendering in Marble, improve existing ones (e.g. street names)
(Optional) Work on a .pbf parser for Marble to read .pbf instead of .osm files (much faster)
(Optional) Look into a new file format tailored for OSM vector rendering for Marble. Research existing formats like mapsforge
(Optional) Create a tool that automates the process of creating the tiles needed by Marble

Expected results: A new map theme (.dgml) for Marble that is based on locally stored .osm or .pbf files using a (possibly already existing) tiling scheme. The tiles are loaded from a local directory; tile data for a certain region is enough for a start. When opening the map theme in Marble, the locally stored tiles are loaded automatically as needed and displayed by the existing and extended OSM vector rendering.

Knowledge Prerequisite: C++, Qt

Mentor: Torsten Rahn

KDE Edu

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

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.

Website - Mailing list - IRC channel: #kdevelop on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE PIM

KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc.

There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc.

Have a look at last year's ideas as well.

Website - Project Wiki - Mailing list - IRC channel: #kontact and #akonadi on Freenode.

Project: Improve HTML composing

Brief explanation: The HTML support for the composer is currently limited. This should be improved: Replying and forwarding should (optionally) preserve the HTML format. The composer should use WebKit editing so that all HTML is fully supported. This will extend last years project GSoC/2011/Ideas#Project:_Improved_HTML_support_in_KMail with the composer parts.

Expected results:Replying and forwarding HTML mails should be fully supported. The QTextEdit-based widget in the composer should be replaced by a WebKit-based widget, to support all HTML instead of a small subset. Currently support exists only in the libraries and not in the composer.

Knowledge Prerequisite: C++, Qt, JavaScript and (X)HTML

Mentor: Torgny Nyblom

Project: Plasma Workspace Integration for Akonadi

Brief explanation: Akonadi is intended to offer PIM services to many applications, i.e. not being just there for KDE PIM apps. While other applications are already using Akonadi for data, currently the KDE PIM applications are the main interface for interfacing with the setup or status of the system.

This idea is about working and completing several smaller items for workspace integration

E.g. ways to see the status and progress information of Akonadi infrastructure, similar how status and progress of KIO infrastructure services is made available.

Additional tasks are displaying or allowing creation of data through workspace facilities, e.g. Plasma applets. E.g. KDE currently has multiple notes plasmoids to store user notes. The best looking plasmoid is currently the one that plasma ships, but it does not use akonadi to store notes. It would be better to have one plasmoid which looks awesome and stores data in Akonadi and retiring other plasmoids.

Expected results: Multiple working Plasma Workspace integration bits and pieces as described above

Knowledge Prerequisite: Qt, JavaScript, C++

Mentor: Kevin Krammer, need also a co-mentor from the Plasma team

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra Karbon

Karbon is a vector drawing application with an user interface that is easy to use, highly customizable and extensible.

Web - Mailinglist - IRC channel: #calligra on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra Words

Web - Mailinglist - IRC channel: #calligra on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra Krita

Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/

Project Page: http://www.krita.org/

Irc channel: #krita on irc.freenode.net

Forums: http://forum.kde.org/viewforum.php?f=136.

Wiki: http://community.kde.org/Krita

Project: Perspective Drawing:

Brief explanation:

Krita is a 2D painting tool, but artists often need to give the illusion of depth. Krita has two tools to help the user draw perspective correctly: the perspective grid and the perspective assistant. The latter is more advanced, but needs improvements to become a real star feature. It needs to be expanded by allowing real 3D objects to be important and put into perspective. This means rotation, setting the vanishing point, scaling, and then integration with the paint tools. At the same time, to get into the codebase, the student should implement other missing features in the perspective assistant.

Expected results:

A perspective painting assistant that can use real 3D objects and place them on the canvas, integrate with the perspective system and painting system.

Knowledge Prerequisite:

C++, mathematics, Qt. You need a good level of programming experience to tackle this task.

Mentor:

Boudewijn Rempt

Project: Add an infinite canvas/wraparound mode to Krita

Brief explanation:

Krita is a 2D painting application with a focus on texturing, matte painting and comics drawing. For texturing, we need to expand the Krita image model in two ways: make the canvas infinite, so the user never needs stop painting, and making the canvas wraparound in all directions.

Expected results:

Two new canvas modes, where the canvas is infinite and the image size is dynamically set to the size of the largest layer, and a wraparound mode, where the imagesize is fixed, but the canvas can scroll in all directions infinitely, wrapping around and around.

Knowledge Prerequisite:

C++, Qt. You need a good level of programming experience to tackle this task.

Mentor:

Boudewijn Rempt, usability consultant: Bugsbane.

Project: Painting and Separation of 3D Textures

Brief Explanation: As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.

Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.

Mentor: Lukáš Tvrdý

Used technologies: C++, Qt

Resources: http://www.krita.org

Project: 3D Material Image Maps

Brief explanation: 3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:

1. Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.

2. When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.

3. In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).

For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita.

Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.

Used Technologies: C++, Qt, color theory, mathematics

Mentor: Boudewijn Rempt

Project: Matte painting

Brief explanation:

One of Krita's main use cases is as a professional tool for painting textures and mattes in digital film. Mattes are primarily made of sequences of images generated by a combination of two methods, first by animatable spline based shapes, which currently exists and is being developed in blender, and then after that, by hand painting frames for detailed areas and corrections. The trouble is that no currently maintained FOSS application currently tries to provide the ability to create hand painted mattes. This project is to extend Krita for this purpose.

Expected results:

The ability for Krita to load manually selected sequences of color managed images as frames to be represented as a single layer in Krita. Optionally would be the ability to display playback at reduced resolutions to increase performance and to offset the time at which sequences were inserted.

A “Timeline” docker which would display the current frame displayed, and allow clicking and dragging to different points in time, updating the image displayed in the canvas to match. Optional would be the ability to zoom and scroll the timeline, mark modified frames on the timeline, playback the image sequence, forwards and backwards as video (most likely only in the openGL mode of Krita or with an external tool like ffplay) and display times in a range of formate EG SMTP, PAL, NTSC, Secam etc.

Updating the paint and transparency layer types, so that when Krita is using a frame sequence and one of these layer types is created, they also represent a series of frames rather than just a single image. This could possibly be a toggle switch on layers, much as visibility, alpha lock etc. are now.

The ability to save layers that are displaying frame sequences out as frame sequences also, giving them user definable names (eg where to insert the frame number, how many digits to pad).

Keyboard shortcuts to move forwards and backwards 1/10/100 frames, to jump to the start and end of the timeline and forward / backwards play if video playback is supported.

Knowledge Prerequisite:

C++, Qt. This is again not a job for a beginning coder.

Mentor: Boudewijn Rempt

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra Stage

Stage is an easy to use yet still flexible KDE-based presentation application.

Mailing-list: https://mail.kde.org/mailman/listinfo/calligra-devel

Project Page: http://www.calligra-suite.org/stage/

Irc channel: #calligra on irc.freenode.net

Forums: http://forum.kde.org/viewforum.php?f=203

Wiki: http://community.kde.org/Calligra/Stage

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra Tables

Tables is a fully-featured calculation and spreadsheet tool. Use it to quickly create and calculate various business-related spreadsheets, such as income and expenditure, employee working hours…

Mailing-list: https://mail.kde.org/mailman/listinfo/calligra-devel

Project Page: http://www.calligra-suite.org/tables/

Irc channel: #calligra on irc.freenode.net

Forums: http://forum.kde.org/viewforum.php?f=203

Wiki: http://community.kde.org/Calligra/Tables

Project: Improve OpenFormula-support

Brief explanation: Calligra Tables supports the OpenFormula-specification to implement formula functions. To fully support all of the defined heighest level 4 we need to add support for following 18 formulas which are missing at the moment in Calligra Tables; averageif, averageifs, b, chisqdist, chisqinv, countifs, critbinom, dde, external, forecast, hyperlink, legacychitest, linest, logest, networkdays, percentrank, prob, sumifs.

Every of those 18 formula should come with unittests to prove that the formula is working as expected. Also every of the formula needs to have documentation so it can be added/edited from within the UI.

Depending on the time we need for that task and if there is time left we would improve the unittest-coverage for all of our formulas.

Sources are at;

functions the C++ code of the existing set of 564 formula functions supported by Tables currently is within the h+cpp files.
tests the existing unittests for our functions are within the h+cpp files. Most of the currently supported 564 formula functions comes with unittests.
docs the documentation for all of our formulas is within the xml files.

Expected results: Full support level 4 of the OpenFormula specification.

Knowledge Prerequisite: Qt/C++

Mentor: Sebastian Sauer <[email protected]>

Calligra Plugins

As Calligra is quite powerful it is easy to add plugins to it that then can be used by all Calligra applications.

Mailing-list: https://mail.kde.org/mailman/listinfo/calligra-devel

Project Page: http://www.calligra-suite.org

Irc channel: #calligra on irc.freenode.net

Forums: http://forum.kde.org/viewforum.php?f=203

Wiki: http://community.kde.org/Calligra

Project: Improve saving of charts to OpenDocument

Brief explanation: The Calligra charting-plugin makes it possible to load, display, edit and save charts within Calligra. The charting-plugin can be used in all Calligra applications including Words (the word-processor), Tables (the spreadsheet-application) and Stage (the presentation-application).

While loading and displaying Microsoft Word, Powerpoint and Excel 2000/2003/2007/2010 files and ISO OpenDocument ODT, ODS and ODP files works very well we are rather bad at saving them back. Since the charting-plugin does not only allow viewing but editing and saving this is a rather big problem. In lot of cases charts are basically lost after loading+saving a file. The goal of this project is to fix that and improve the current situation.

Since ISO OpenDocument is the native format of Calligra we would concentrate on improving saving charts to OpenDocument files.

Note that this is a *very* important task for us and has high priority.

Expected results: When a loaded document is saved and loaded again charts are not lost. Ideally a roundtrip does not show any difference before vs after.

Knowledge Prerequisite: Qt/C++

Mentor: Sebastian Sauer <[email protected]>

Calligra Active

Calligra Active is a Calligra interface tailored specifically for use with Plasma/Active on tablet devices.

Mailing-list: https://mail.kde.org/mailman/listinfo/calligra-devel

Irc channel: #calligra on irc.freenode.net

Wiki: http://community.kde.org/Calligra/Active

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KWin

KDE's window manager

Techbase page - Mailinglist - IRC channel: #kwin on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Nepomuk

Website- Documentation/Howtos - Ontologies - Mailing list - IRC channel: #nepomuk-kde on Freenode.

(Also see the Nepomuk techbase page for a long list of Nepomuk-related ToDos and ideas.)

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Plasma

Website - Mailing list - IRC channel: #plasma on Freenode.

Project: Lazy/Asynchronous Plasmoid Inititalization

Brief explanation: Plasmoids are currently initialized in a synchronous fashion, meaning the construction of a plasmoid is blocking plasma shells (such as Plasma Desktop) at large. This leads to longer startup times than necessary. Instead plasmoids should be lazy initialized, meaning that their creation has little to no impact at all on the instanciating function(s).

Expected results: Plasma Widgets should be initialized in an asynchronous fashion to reduce overall Plasma startup time.

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Aaron Seigo / Harald Sitter?

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Phonon

Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software.

Website - Mailing list - IRC channel: #phonon on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Solid

Abstraction library for hardware support. Used pretty much anywhere in KDE where there needs to be hardware interaction.

Website - Mailing list - IRC channel: #solid on Freenode.

Project: Easy partitioning in Solid/Dolphin

Brief explanation: Extend the Solid library to support basic partition management, using udisks as a backend for low-level operations; develop a partition manager that uses this new interface, taking ispiration from the work already done for the Chakra Linux installer Tribe; integrate it in a Dolphin plugin.

Expected results: From a user's point of view, Dolphin will provide a quick and easy-to-use graphical interface for operating on drives. From a developer's point of view, Solid will provide a higher level API that will enable programmers to create new disk managers abstracting from the physical details of the hardware they're going to manipulate.

Knowledge Prerequisite: C++/Qt/KDE development, some knowledge about disks and partitions.

Mentor: Dario Freddi <[email protected]>

Kate

Kate is a powerful programmer's editor.

Website - Mailing list - IRC channel: #kate on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Rekonq

Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

ownCloud

An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.

Website - Mailing list - IRC channel: #owncloud on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE Usability

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE SDK

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Okular

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Gluon

Gluon is a Free and Open Source framework for creating and distributing games - supporting the flow of the idea all the way from the author to the player of the finished game, and back.

Gluon Website

Contacting the Gluon team (irc, email etc)

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Telepathy

Telepathy is a cross-desktop framework for real-time communication and collaboration - think IM, Voice/Video Conferencing and Collaborative document editing/gaming/etc.

More information:

Telepathy Framework
KDE Telepathy
We can be found on IRC in #kde-telepathy

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

simon

simon is an open source speech recognition system using many parts of the KDE infrastructure. You can find out more about us on our homepage, blog or the development site.

There is also a demonstration video on youtube.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE on Windows

The KDE on Windows subproject makes KDE applications available on Microsoft Windows, both desktop (XP, Vista, 7) and Windows CE

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE Accessibility

The KDE Accessibility subproject aims to make KDE applications accessible for all.

Project: Focus tracking in KWin and KMagnifier

Brief explanation: Currently the KWin zoom plugin and KMagnifier implement focus tracking using KAccessible. KAccessible uses QAccessible direct to implement focus-tracking. The problem with that is that it only works for Qt/KDE applications. The plan is to change the existing code in the KWin zoom-plugin and KMagnifier to not use KAccessible any longer to fetch the information what application/widget/etc has the focus but to use dbus to connect with AT-SPI2 and fetch all needed informations (means the x/y-coordinates where the focus is atm) from there.

Once done and if we do not lose to much time with unexpected problems there should be enough time left to look at common applications like KWrite, Kate, Konsole, Dolphin, etc. to identify and fix cases where the applications are not sending the proper QAccessible::Focus events so that focus-tracking doesn't work there. See for example the fix I did back then to enable focus-tracking in KWrite/Kate - note that all Qt-widgets and most KDE-widgets are already fine and accessible but that a custom canvas like KWrite/Kate are using them to draw the text are basically not accessible at all what is why the patch introduces new classes to make the canvas accessible including making focus-tracking working.

http://blogs.kde.org/node/4287 describes our current solution for focus-tracking
http://community.kde.org/Accessibility/qt-atspi describes how to setup your environment to get ATSPI2 and Qt working together using the Qt-ATSPI bridge.
See the linked source-code above and grep there for "focusChanged"

Expected results:

The KWin zoom-plugin and KMagnifier are using ATSPI2 rather then KAccessible to implement focus-tracking.
Focus-tracking within KDE works for Qt/KDE applications like it does today with KAccessible (or even better :-) ) and applications using other Toolkits (e.g. GEdit, Firefox and LibreOffice.org) will work too.

Knowledge Prerequisite: C++/Qt

Mentor: Sebastian Sauer <[email protected]>

Project: Screen reader friendly KDE applications

Brief explanation: With Qt at-spi we now have a solution to make KDE applications work with the Orca screen reader from Gnome.

This project is about reaching out to screen reader users in order to find out how to make KDE applications work better with the screen reader. Along with the research is always the writing of patches to implement the findings. This requires good communication skills and some C++ knowledge.

Project: Plasma Accessibility

Brief explanation: Making it possible to use Plasma with a screen reader is the goal of this project. You will have to dive into Plasma in both KDE libs and the desktop shell. It will be necessary to make sure keyboard navigation works and feedback from individual parts of the desktop is good so that the screen reader can make sense of it. This might include working on the screen reader to improve the experience.

KStars

KStars is a Desktop Planetarium for KDE. It provides an accurate graphical simulation of the night sky, from any location on Earth, at any date and time. The display includes upto 100 million stars, 13,000 deep-sky objects,all 8 planets, the Sun and Moon, and thousands of comets and asteroids.

Project: Autoguiding in KStars

Brief explanation: Guiding is process by which a star field is kept stationairy within the field of view of a telescope when performing long exposure astronomical imaging. The telescope mount must keep tracking the selected celestial object during the imaging process as it transit the sky. Due to imperfections in the mechanics of the mount and periodic errors, the star field may drift with time. If the drift is not corrected, the resulting image may contain star trails among other deformities. The guiding process depends on selecting a reference star in the frame and correcting the telescope motion by detecting drifts in the telescope axes, and issuing correction commands accordingly. KStars supports INDI which can operate and control numerous astronomical devices. The goal of the project is to add autoguiding support to KStars Ekos tool. Ekos is a tool to aid amateur astronomers in astrophotography. It enables focusing, guiding, and capture of astronomical images using INDI. It is prefereable, but not necessary, to have an actual telescope and a CCD camera. Students may use the INDI telescope and CCD simulators to develop and test autoguiding as well.

Expected results: Ability to automatically guide a mount using a CCD and a telescope for long exposures.

Knowledge Prerequisite:

C++, Qt.
Basic knowledge in INDI is required.
Some knowledge in astronomy is preferable.

Mentor: Jasem Mutlaq