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 kde-devel@kde.org. 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.

KDE Multimedia

Project: Consistent look and feel

Brief explanation: What we should have is a common, unified appearance of sorts for the kde multimedia apps. Needs to be different from the rest of KDE. Perhaps integrating plasma theming. Dark usually looks good. QML isn't a bad idea either.

Expected results: A consistent look and feel across kdemultimedia apps

Knowledge Prerequisite: Qt, maybe plasma themes, basic UX/UI design

Mentor: Trever Fischer

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!

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. This is not a user interface design project. Not at first, at least. 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 data 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.

Expected results: Amarok's context view, rewritten for QML. The new data models should replace existing Plasma ones, and ideally the data queries should be done in SPARQL where it makes sense.

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

Mentor: Teo Mrnjavac, Bart Cerneels or another Amarok core team member

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.
The new collection backend should be completely independent from the existing MySQL backend, and should not lack any features compared to the MySQL backend. It should be as decoupled from the UI as possible, and it should reuse the existing collection browser UI and other UI elements rather than writing new ones. The student should also be ready to make changes to Nepomuk/Strigi/Tracker... if for some reason it's the best way to implement a missing feature.

Expected results: At least one fully working collection backend based on Nepomuk or Tracker. By "fully working" we mean that the Semantic collection must be able to completely replace the existing MySQL collection if for some reason one wants to.

Project: Social music - 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. Specifically, one of the key features of Tomahawk is the ability to connect to one's Google Talk buddies and share each other's music collections. Amarok already supports various music streaming services so this is a logical next step. 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. Specifically, an Amarok user must be able to view a friend's collection, query it, stream any track from it, and also, if the friend is listening to something, listen along.

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: Teo Mrnjavac or another Amarok core team member

Project: Spotify Collection

Brief explanation: Spotify is a music streaming service. The goal of this project is to integrate it into Amarok so that Amarok can be used instead of the official Spotify client.
Note: Spotify is not available in all countries. Applicants must have access to the Spotify service from their expected place of residence during GSoC.

Expected results: Users can log in to Spotify, access their playlists, search for & stream music

Knowledge Prerequisite: C++, Qt

Mentor: Bart Cerneels

Cantor

Cantor is an application that lets you use your favorite mathematical applications from within a nice KDE-integrated Worksheet Interface. It offers assistant dialogs for common tasks and allows you to share your worksheets with others.

Project: Python backend for Cantor

Brief explanation: The goal of this project is to provide the power of Python (Numpy, Scipy and Matplotlib) to the Cantor software. Python is openly used but a good environment in KDE is still missing.

Expected results: To have a full FOSS KDE-based environment for python and get benefit from Cantor's infrastructure (console, editor from kate, autocompletation, workspace, history, help/documentation...). This has been done successfully with other languages (R, Maxima, Kalgebra, Octave, Scilab), so this should be a feasible project.

digiKam

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.

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.

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

Project: Video Slideshow Generator

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.

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: UPnP/DLNA integration

Brief explanation:
UPnP is a standard which allows discovery of and access to media contents in a home network. It is supported by many modern TVs and media receivers. With large collections of digital photos presentation on a TV is a natural solution but is not easily possible at the moment.

Expected results:
The first step would be to offer digikam's photo collection on the network by providing a UPnP server accessing digikam's database, offering digikam's album structure including all virtual albums, and the files, if necessary, transcoded to the formats specified by DLNA. This will require integration by C++ and on-the-fly provision of contents, and not simply writing a config file for an existing UPnP server application. In the project proposal, we would expect a technical suggestion for the underlying implementation (suggestion: HUPnP, www.herqq.org) with some thought what is already provided by and what is still missing in the chosen low-level library.
The second step would be implementation of a control point integrated into digikam which allows to control the presentation of digikam's photos on the TV from within digikam.

To conclude, step 1: photos from digikam are visible on the network and can be browsed from the TV; step 2: someone sitting on the notebook running digikam controls the presentation on the TV

Knowledge Prerequisite:

C++, Qt. Willingness to acquire knowledge of the UPnP specification including some lower-level implementation details.

Mentor:

Marcel Wiesweg

Project: Extending the presentation view QML UI

Brief explanation:
Organizing pictures is one thing, at some point you will want to show your pictures to others. For this task, we would like to provide a beautiful UI based on QML which allows fine grained control over the presentation. As the next step, this interface can be used to perform basic operations like assigning tags or ratings, making it an alternative to the current main window for certain tasks.

Expected results:
Extend the current basic QML-based presentation view to a full-featured, polished interface for showing pictures, including arranging photos with multiple pictures per screen, storing such presentations for later use. Integrate QML with digikam's library framwork for loading picture files. Work on extending the UI to allow editing of tags, rating, comments etc.

Knowledge Prerequisite:

C++, Qt, QML

Mentor:

Marcel Wiesweg

Project: Auto Noise Reduction

Expected results:
In digiKam, a tool already exist to reduce camera sensor noise, using wavelets algorithm, working on YCrCb color space, and supporting 16 bits color depth images. This tool provide a lots of settings in user interface. In order to speed-up photograph workflow, we need an algorithm able to analyse existing noise type available in image and adjust settings accordingly.

Knowledge Prerequisite:
C++, Qt, imagery

Mentor:
Gilles Caulier

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)

(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

Project: Marble: Natural Earth Vector Map

Brief explanation: The current "Atlas map" is based on the MWDB2 dataset. The data is pretty old and the whole implementation that covers the Atlas map still has a few traces of "historic" code. There's a new proposal that would introduce the high quality Natural Earth data. This would require several changes to the Marble code and its data. See

Expected results: A full optimized rendering of the Natural Earth map as vector rendering by using and extending Marble's existing classes.

Knowledge Prerequisite: A good grasp over C++ and object-oriented programming, and Qt; writing test cases with Qt; should quickly learn how to write libraries; have a lot of patience; ability to solve software design problems

Mentor: Torsten Rahn <rahn@kde.org>

Project: Marble: OpenGL Mode

Brief explanation: Marble currently performs all rendering in software. This works reasonably fast on most devices, but compromises must be made with respect to the map quality. OpenGL, however, offers higher-quality results, is more state-of-the-art and perhaps helps to reduce power consumption on mobile devices. It therefore makes sense to introduce an OpenGL mode in addition to the sotware rendering mode in Marble (the user should be able to choose between software rendering or OpenGL).

The main task is to refactor the Marble codebase such that both the software rendering and the future OpenGL code share as much code as possible. In particular, visibility control (which objects should be rendered according to the current view parameters) should be factored out into separate classes, such that they can be reused in the OpenGL mode.

Knowledge Prerequisite: A good grasp over C++ and object-oriented programming, and Qt; writing test cases with Qt; should quickly learn how to write libraries; have a lot of patience; ability to solve software design problems

Mentor: Bernhard Beschow <bbeschow@cs.tu-berlin.de>

New apps

Duplicate Music Files Finder (nepomuk?)

Brief explanation: A GPL alternative for fuzzy audiofile comparison software called Similarity. It can find mp3 files with identical content but different tags, and it also can find differently encoded versions of the same recording (i.e. ripped from the same CD but with different bitrate).

For example I have used it to find duplicate albums and songs in 70 gb tango music collection (collected from different people’s harddrives).

Already existing audio footprint algorithms can be used for fuzzy comparison, such as ones from musicbrainz and moodbar. taglib for reading tags, and phonon/gstreamer or audio decoding.

Expected results: A standalone app that searches for duplicate files (also detecting duplicate folders), that shows the differences between duplicates (e.g. different tags, different bitrate, slight difference in duration, or 100% if binary identical), and allows to remove selected files.

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.

Project: Dashboard enhancements

Brief explanation: To improve first-start impression and general usability, we would like to offer users a Plasma-based dashboard. The dashboard allows to open projects and shows metadata around projects like recent commits, bugs etc. pp.

Expected results: The work by Aleix is continued and finished up giving us a properly integrated dashboard. The general dashboard allows opening recent files, projects and sessions. It is also possible to create new projects from it. The project dashboard offers notes, rss feeds and maybe other useful features and can be easily customized and shared between developers. Both dashboards adapt their visuals to the color scheme chosen by the user and fit well into KDevelop.

Project: Improving Git Integration

Brief explanation: Adopt some ideas in order to make Git integration in KDE something we all want to rely on by embedding Git features in KDevelop's daily workflow.

Expected results: It should provide different new visualizations of the history, annotations. Also some staging configuration would be good too.

Knowledge Prerequisite: C++, Qt, Git.

Mentor: Aleix

Project: User-Defined Project & File Templates

Brief explanation: Make it easier/possible for users to create new project templates and share them using GHNS. Similarly make it possible to create new files from a template.

Expected results: KDevelop users can create new project templates and upload/download them to/from GHNS. There is a new customizable "create new file from template" wizard, whose templates are also sharable via GHNS.

Knowledge Prerequisite: C++, Qt

Mentor: Milian

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.

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

Calligra Karbon

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

Project: Variable thickness lines

Brief explanation: One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.
This proposal is to create a variable width path shape / tool, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.
As Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.

Expected results: variable width path tool is able to change the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup. The shape needs to be able to save and load in svg/odf.

Knowledge Prerequisite: C++, Qt, SVG?

Mentor: Thorsten Zachmann < zachmann @ kde dot org >

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.

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: First, make the canvas infinite, so the user can paint textures of any size without stopping, and second, a mode for creating tileable textures where painting strokes that go off the canvas, wrap over on the opposite side avoiding texture seams along the edges. Panning in this mode would essentially work as just an offset for the whole canvas to wrap around, allowing artists to check tiled textures for seams.

Expected results:

Two new canvas modes, one 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 image size is fixed, but the canvas can scroll in all directions infinitely, wrapping around and around. Brush strokes extending off a canvas edge would also wrap similarly.

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.

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

Calligra Words

Calligra Words is for creating word processing documents, and not for desktop
publishing. Our focus is to provide a powerful and easy to use experience for
everyone without being the specialized tool for any specific group of users.
That said we try to have enough separation in our code that people (maybe even
ourselves in the future) can create extra plugins or custom user interfaces.

Project: Grammar checking.

Brief explanation:
Calligra Words can check spelling on the fly, but we would like to add support for grammar checking too. There are a few libraries out that that can do that and we want those integrated into Calligra Words. Besides the actual checking we want a visualisation with some underline (needs to be integreted with the red underline of spellchecking). We also want som dialogs to contro the behavious etc.

Expected results:
Working grammar checking as good as the library is capable of. Configurability, and flawlessly integreated visualisation.

Project: Section columns support.

Brief explanation:
Calligra Words have a great new layout library for text, but support for sections and especially sections columns is not yet implemented. We have an algorith for distributing of text and the library is in some ways already prepared for section columns, but it will still take some work. It is going to be a challenge for sure.

Expected results:
No regressions of current layout, and layout of section columns. even sections within tables and within other sections within tables etc recursively

Knowledge Prerequisite:
Qt/C++, Knowledge of Calligra text layout code. Having worked with the code before is a big plus

Mentor:
C. Boemann < cbo at boemann dot dk >

Calligra Stage

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

Project: Add support for modifying shape animations.

Brief explanation:
Currently Stage can only show shape animations it loads from the file. It is not possible to add/edit/remove shape animation form within Stage. The aim of this task is to provide a user interface which let the user easily add/edit/remove shape animations. The UI for that should be timeline based so that it is easy to see at which step which animation is done. E.g. for shapes that get visible at a step and hidden at a later step it should be visible in the UI that the shape is visible between these 2 steps. It should be easy to add/remove animations or change the existing animations.
This can be either done as a dialog using QWidget/QGraphicsView and friends or QML.

Expected results:
Have a nice looking and easy to use UI for managing shape animations. The different kind of animations are all configurable.

Knowledge Prerequisite:
Qt/C++, Knowledge of Calligra code is a plus

Mentor:
Thorsten Zachmann < zachmann at kde dot org >

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…

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 <mail@dipe.org>

Calligra Kexi

Project: Add multimedia support to Kexi

Propose, design and implement multimedia (sound, video) support for Kexi Forms (as an interactive media view widget for video and a slider widget like [1] for audio); phonon or Qt Multimedia can be utilized (propose your extensions and ideas in this area)

presenting the media should be possible in-place, within forms or table views

Reusing the work for Kexi Forms, propose, design and implement support for tables; this part would share most of the code with Forms, since only the presentation is different (i.e. tabular view); for example see the screen shot presenting image embedded within a tabular view (propose your extensions and ideas in this area)

Regarding storage, consider two approaches (both, not one of them):

storing the video/audio data internally in the database as Big Objects (BLOB) exposed in Kexi tables as Object data type; this option is suitable for small data

storing the video/audio data externally in local or remote filesystems and keep only the references as URLs in the database; this option is suitable for large data

propose integration features with the underlying operating system (not just with KDE desktop but also with other desktops, be it GNOME or Windows); example of this is action for opening the video/audio in given external player and/or in default player

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 <mail@dipe.org>

Project: Improve the Formula Shape

Brief explanation:
The Calligra plugin for mathematical formulas makes it possible to load, display, edit and save math formulas within Calligra.
The formula plugin can be used in all Calligra applications including Words (the wordprocessor), Tables (the spreadsheet application) and Stage (the presentation application).

The formula shape loads and saves mathematical formulas using MathML, an XML format specially designed for storing mathematics. It also displays the formulas in a nice way and lets the user edit it inline.

However, it is rather simple and the output does not look the way it could do. There are many ways in which this shape can be improved, and to do it all is probably more than a GSoC's amount of work. Here are some examples of ways to improve the formula shape, and the student should pick some of these:

Add support for so called 'XML entities'. These are inline characters like ε. This is the most important addition.

Increase the number of special purpose characters supported in a formula (see also entities above).

Improve the support for things like large braces, brackets, matrixes, etc.

Improve the general layout of formulas, including kerning, fonts and font sizes.

Improve inline editing of formulas

(possibly) add support for LateX formulas for people who are used to writing those. This would make it easier for seasoned LateX users to use Calligra Words for writing scientific papers.

Add support for the OpenOffice.org formula language.

(slightly off topic) Add support for formula numbering and referencing in the text.

Expected results:
An improved formula shape that lets the user include mathematical formulas in a document and is actually useful for real-world scientific papers.

Knowledge Prerequisite:
Qt/C++

Mentor:
Inge Wallin <inge@lysator.liu.se>

Project: Fontwork Shape/Tool

Brief explanation: Fontwork is a feature where text is drawn accoring to some path definitions that define how the text should look like. This feature might be better know to some as "Wordart".
The aim of this project is to create a flake shape/tool that allows the user

to create fontwork shape

make it possible to modify the text

change the path to modify the look of the text

Support for loading and saving into odf is also needed and should be compatible with OpenOffice.

Additionally it would be nice to enhance the MS Office filters to convert "Wordart" to Fontwork when loading.

Expected results: Shape and Tool working with the above specified features

Knowledge Prerequisite: C++, Qt, Calligra is a plus

Mentor: Thorsten Zachmann < zachmann @ kde dot org >

Calligra Active

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

Project: Document editing support

Brief explanation: Calligra Active was planned keeping in mind two stages, the first one where basic viewing is implemented and the second when it will get editing support. The first stage is almost complete, with CA supporting viewing Text Documents, Spreadsheets, and Presentations. We need someone to work on editing support for CA.

KDE Games

Project: Port games to more modern graphics frameworks

Brief explanation: During the porting from KDE 3 to 4, the new QGraphicsView framework lacked features and performance, so the KDE Games Team rolled their own KGameCanvas instead. Also, most games were rewritten to use vector graphics (SVG) instead of bitmap graphics. After four years, QGraphicsView has matured, and a unified rendering solution for SVG files, KGameRenderer, has appeared. Some games still need to be ported to these new technologies.

Expected results: At least six games should be ported from KGameCanvas and home-grown rendering routines to use QGraphicsView plus KGameRenderer. This is not as much as it sounds: Most games have a quite compact codebase, so a single port can be done in one to two days once you're accustomed with the used technologies.

Knowledge Prerequisite: C++ and Qt. Experience with QGraphicsView is a plus.

Project: Write a KDE game using QML ("Qt Quick")

Brief explanation: Most of our games paint on a QGraphicsView, and libkdegames is prepared for that. Since QML is the next big thing in painting, we want to know how our libraries need to be evolved to allow feature-rich QML-based games to be developed.

Expected results: A new game shall either be written from scratch, or an existing game shall be ported to display the game area on a QML canvas. The codebase should be structured such that those parts which can be shared as part of a library can easily be identified. The game in question should incorporate complex interface elements, such as a score dialog or a chat widget. The game logic is not that important, as long as the basic gameplay works.

KWin

Project: KWin Effect Viewer

Brief explanation: With 4.9 KWin Effects can be written in JavaScript, but there is no convenient way to test the scripts. In this project a viewer application similar to plasmoidviewer should be developed. This could be achieved by using Xephyr and starting a dedicated KWin instance on the embedded X-Server which is just running the effect.

Project: KWin Integration into Plasmate

Brief explanation: With 4.9 KWin became scriptable both through JavaScript and QML. For example window decorations and window switcher can be developed using QML. KWin follows the Plasma package structure for these scriptable elements. For the Plasma Desktop there is Plasmate to easily develop, test and publish packages. This should be extended to develop the various KWin parts.

Expected results: All KWin script types can be developed inside Plasmate

Plasma

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

Project: Global "New document..." menu

Brief explanation: Creating a new document of any kind with no dedicated program already running usually takes a few steps: select the dedicated program e.g. from the menu and start it, wait for program window to appear, in program window select option to create a new document, then finally start editing the document. Or one could create a new file by the "New document..." menu on a filesystem folderview, then open that file in the program.

Instead of that there could be a Plasma widget which provides the possibility to create all kinds of documents from templates and have them automatically opened in the matching program. That way the number of steps needed to actually edit a new document is reduced. Document types which could be created might include emails, notes, etc., not just classic file-based documents.

Expected results:
There will be a spec to define the creation of new documents (like a file template to copy or a program to run, e.g. a script which uses a dialog to get parameters from the user) e.g. by a .desktop file and file template instances or file creating scripts/programs). This spec enables everyone to add new template definitions.
Template definitions with needed file templates or scripts could be installed globally and per user.
There will be a Plasma Widgets which offers to select from the installed template definitions and on selection creates a new object by copying the file template or running the script/program, then starting the assigned editor program if needed (not needed for new email, for example, as this step is usually implicitly asking the email client to create a new email.
Which template definitions are provided in the list should be configurable per activity.

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Friedrich Kossebau?

Phonon

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

Project: Implement unit tests

Brief explanation:
Phonon does not have any unit tests. They were removed some time ago because they never worked. Any decent library has unit tests.

Expected results:
Phonon gets a comprehensive suite of unit tests.

Knowledge Prerequisites:
C++, Qt, unit testing

Mentor:
Trever Fischer

Project: Implement encoding capabilities

Brief explanation:
Applications could use Phonon to do transcoding, or to save videos from recording devices. Currently Phonon can grab images from webcams for example, but can't do anything useful with them. What needs to be done:

create an Encoder media node

define a bunch of common output formats (mjpg, mp4, stuff)

other useful properties for the Encoder (like output resolution, depth?)

Solid

Project: Improve Android devices support

Brief explanation: Creating the needed software to have a good Android support.

Expected results: A few pieces of software should be created in order to have a complete Android support such a kio_smtp to access to the device, and maybe an Akonadi backend to synchronize contacts/calendar if Android supports that.

Knowledge Prerequisite: C/C++/Qt/KDE development, This project will be develop using libmtp so basics about C/C++/Qt/KDE are needed.

Mentor: Alex Fiestas <afiestas@kde.org>

Project: Improve iOS devices (iphone,ipad) support

Brief explanation: Creating the needed software to have a good iOS support.

Expected results: A few pieces of software should be created in order to have a complete iOS support in KDE such a kio_slave to access to the device, an Akonadi backend to synchronize contacts/calendar o a nicely done app (QML?) to organize applications.

Knowledge Prerequisite: C/C++/Qt/KDE development, This project will be develop using libimobiledevice so basics about C/C++/Qt/KDE are needed.

Mentor: Alex Fiestas <afiestas@kde.org>

Project: Finishing and Polishing Printing support

Brief explanation: Finish what is left to be done for having a kickass printing support

Expected results: Have it to display the best (if available) PPD drivers, get missing PPD with PackageKit, get Windows shared printers. Having the best available list of PPD has to be done by trying to integrate with the python system-config-printer which already does that, it uses an xml file but might have some more logic, if there's too much logic the best is to code this as a C Library to be shared later with the python tools so we get this list updated for free.

Knowledge Prerequisite: C++/Qt/KDE development, some knowledge about Samba, CUPS and python are highly desired... Since this is the Add Printer Wizard that will need improvements having a printer that works in Linux is pretty important

Mentor: Daniel Nicoletti <dantti12@gmail.com>

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 <drf@kde.org>

Project: QML plasmoid for Plasma NetworkManagement

Brief explanation: Create a new shiny plasmoid for Plasma NM using QML technology. The backends will remain in C++, just the user interface will be ported to QML.

Expected results: A new user interface with fluid animations and easy to use. We also expect new dialogs to simplify creating new connections and interacting with existing connections.

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.

Project: Aggregator

Brief explanation:

An Atom/RSS reader is a often requested feature for ownCloud. As ownCloud is all about keeping your personal data in sync, this project aims for providing a feed reader that can be synced with Akregator.

Expected results:

At least a working feed reader for ownCloud, in the best case a feed reader that can be synced with Akregator.

Knowledge Prerequisite:

Programming in PHP (ownCloud) and C++ (Akonadi)

Mentor:

Jakob Sack

Project: Mozilla sync integration

Brief explanation:

The popularity of Mozilla sync grows as people tend to have more and more devices with firefox installed. Implementing the well specified storage api enables users not to rely on the Mozilla servers but to use their own servers. Furthermore, the bookmarks could be displayed in ownCloud if the user provides the key.

Expected results:

An ownCloud app that implements mozilla sync. In the best case it would provide an interface to ownCloud apps for using the saved data (if the user provides the key).

Project: Inter OC instance collaboration

Brief explanation:

Clouds are all about sharing content and collaborate with users.
Sharing inside one ownCloud instance is cool but let's take it to next
level and allow users to connect their clouds into one big cooperation
network. Purpose of this project is to build framework for this
cooperation and add this functionality to default ownCloud
applications.

Expected results:

An ownCloud app that allows multiple ownCloud instance to collaborate
in all types of sharing.

Project: Collaboration reach text document editor

An ownCloud app that allows multiple user of single ownCloud instance
to collaborate with document editing

Knowledge Prerequisite:

Programming in PHP/JS, HTML/CSS

Mentor:

Bartek Przybylski

Project: KDE integration for the ownCloud Desktop Client

Brief explanation:

ownCloud has a Qt based desktop client which syncs data from local to the ownCloud and vice
versa. It would be great to integrate some of the great capabilities of the KDE platform for KDE users, such as

integration of kwallet to manage the passwords

synchronize nepomuk meta data

synchronize app data such as bookmarks, feed data etc.

possibly synchronize application config settings

...

Expected results:

the ownCloud desktop client makes good use of the KDE platform capabilities.

Knowledge Prerequisite:

Programming in C++, KDE and Qt

Mentor:

Klaas Freitag

KDE Usability

Project: Usability Survey Framework

Brief explanation:
Continue work on the Usability Survey Framework from GSoC 2011. The USF allows designers and developers to create small user feedback studies tailored to their application. A service component allows developers to create services to listen for activity on features within their applications (such as a click on a new button) and launch a survey tailored to collecting feedback about that feature. A survey component allows developers and designers to create custom feedback surveys to collect information from the user after they experience the features being studied in the application.

Expected results:
The student will work with a Technical Mentor from a KDE project (e.g. Calligra) and develop one or more USF services to help test features within the application. The student will work with a Design Mentor to develop a user feedback survey for the USF service. The student will run a small study using the USF service and survey they created.

Knowledge Prerequisite:
Knowledge of C++, XML, and JavaScript a must. Previous experience with KDE application development and/or services is not required but will be very helpful to the student.

Project: Version control integration in Gluon Creator

Brief explanation:
Gluon Creator is designed to be usable by people who are not programmers, and as such the version management integration has to be simple. There used to be a sprint last June in Randa, Switzerland where the KDevPlatform and Gluon guys sat down together for improving KDevPlatform on to be a usable backend for the Gluon Creator application. There is now a usable backend implementation in KDevPlatform (used for instance in KDevelop) which is powerful and very useful for programmers. This would then be exposed more directly in the user interface in case Gluon Creator, creating a work flow which assists in the use of the version control system.

Expected results:

Integration of the kdevplatform based version control functionality

Creating commits as annotated saves

Revert to earlier commits, with each commit shown in a timeline fashion

Pulling from and pushing to remote repository

Addition of easy selection, deletion and creation of branches in the Project dock, as well as merging from other branches

Knowledge Prerequisite:
Qt/KDE development (includes C++ & git)

Skill level: medium.

Mentor:
Laszlo Papp

Project: Deploy and Integrate Gluon on Mac

Brief explanation:
Description: Gluon build has already been tested on Mac a while ago. Unfortunately, we have mostly Linux and Windows developers, thus nobody tested it recently. It would be nice to get Gluon built on Mac OSX with kdelibs underneath. The most challanging part is to get kdelibs built on Mac. It should be a bit simpler then to get the Gluon Creator built with the assistance of the team. It would also be a great addition to have the building steps documented, and creating screenshots. In addition, CMake/CPack support for Mac OS X packaging. Gluon already has NSIS CPack/CMake support for generating a binary for Windows installation. deb and rpm support are also available for generating binaries for Meego and Maemo installations. The concept is already available by the existing cmake/cpack system. The part of task would be to get that concept adopted for Mac and provide a proper package for Mac installation. That would be the missing bit to cover on desktop machines for game players and developers regarding Gluon.

Expected results:

Successful kdelibs build on Mac

Properly documented steps how to build kdelibs (FAQ and so forth)

Successful Gluon build on Mac along with the Gluon Creator

Documentation how to build Gluon on Mac and some screenshot attracting designers and artists

Easily deployable packaging system for Mac pulling the dependencies automatically for instance and so on

Fresh KDE/Gluon/Mac community member with warm welcome :)

Knowledge Prerequisite:
Mac OS X and little bit C++

Skill level: medium.

Mentor:
Laszlo Papp

Project: Bullet integration into Gluon

Brief explanation:
In the summer and fall of 2011, there was a student in Brazil who had some theoritical deal with the task in question, but suddenly disappeared because of some real life issues. We are really greatful for his job, and would like to push it forward on. This project is to take the task on that front, and establish a proper Bullet physics engine integration into the Gluon Engine. On top of that, it would also an invaluable achievement to deal with the exposing in Gluon Creator. It has a lot of potential and as soon as it is in place, game makers could benefit out of it right away. It is a very important task for the Gluon project because the current collision detection is not too advanced for our makers, designers and artists.

Expected results:
Expected results:

New 3D Physics Engine Integration into the Gluon Engine

Exposed funcitonality to Gluon Creator

Properly documented code

etc

Knowledge Prerequisite:
C++/Qt development

Skill level: medium.

Mentor:
Laszlo Papp and Dan Leinir Turthra Jensen

Project: Unit Testing Framework

Brief explanation:
Gluon needs unit tests for quality assurance. While there is a set of unit tests in the Gluon libraries themselves, they are incomplete and only test a fraction of the available capabilities. Extensions and new test classes are needed. As for Gluon Audio for instance, tt will be very important because of a potential backend replacement, but at least extension from a project called "alure" to QtOpenAL, For the smooth transient, it will aid a lot if we can always test the previously working functionalities for regressions. It is also very important from Gluon Smarts point of view because that module was added to Gluon as the result of last GSoC session. It is the newest module requiring test cases to make sure the quality is good enough.

Expected results:

Finish the tests for Gluon Core

Finish the tests for Gluon Audio

Make tests for Gluon Input

Make tests for Gluon Smarts

Make tests for Gluon Engine

Fresh Qt/KDE/Gluon/Test expert, community member with warm welcome :)

Knowledge Prerequisite:
C++/Qt development (QtTest)

Skill level: medium.

Mentor:
Laszlo Papp

Project: Visual Scene Editor for Gluon Creator

Brief explanation
Gluon Creator is designed to be usable by people who are not programmers, and as such visual editing is a core part of the workflow. While it is currently possible to edit object positions and other properties of a Scene's objects through the property editor, this approach does not support visual editing very well. A separate view is needed instead. This task involves creating the initial version of this view, which would provide a separate view of the Scene using a free-moving camera. In addition, it allows selecting and manipulating objects within that scene using so-called "Gizmos".

Expected results

An editor view embedded into Gluon Creator.

Editor view provides a free view of the current Scene.

Editor view allows selecting objects within the scene.

Selected objects can be manipulated using gizmos.

Knowledge Prerequisite
Experience with Qt Development and Graphics Programming.

Skill level
Medium - High

Mentor
Arjen Hiemstra / Laszlo Papp

Notes
There is a technical issue that has so far kept this feature from being implemented properly. Gluon Graphics is currently undergoing refactoring to support this feature properly, but it is not known whether this will be ready before GSoC starts. If it is not ready, there are workarounds possible while waiting for the refactor to become ready.

Project: Telepathy integration in Gluon

Brief explanation:
Gluon Player is briefly the collective name for a series of applications used to download, discuss, rate, play games and so forth created with either Gluon Creator or any another way around. The Gluon Player applications are used by Game Players on a variety of platforms. The integration would begin with certain fundamental functionalities inside the library to make the Gluon Player application authors' life simpler. There used to be a sprint last June in Randa, Switzerland where one of the Gluon contributors sat down together with Telepathy experts for discussing the matter in question. Telepathy is getting more and more mature and seems to be a proper candidate for providing collaboration between the players where OCS is limited, as in for instance: chatting interface, audio or video interactions.

Expected results:

Integration of Telepathy in the Gluon Player library

Establish a well-defined vision for chatting (text messages), and then implementation

Establish a well-defined vision for audio interaction, and then implementation

As a plus establish a well-defined vision for video interaction, and then implementation

Further extra point, if the library work can be integrated into several frontends, like the KDE Desktop Player, or Harmattan, etc.

Knowledge Prerequisite:
Qt/KDE development (includes C++ & git)

Skill level: medium.

Mentor:
Laszlo Papp

Project: Gluon Creator UI Improvements

Brief Explanation
While the Gluon libraries are seeing continued work Gluon Creator has been slightly lagging behind mostly due to a lack of manpower. This project aims to improve that situation by fixing several of the more major issues in the UI. Primarily this involves creating a context system to determine the "context" of certain actions. This system would then be used to merge several of the actions that are currently duplicated due to them being split between files and the overall project. Further issues include creating a proper welcome dialog and cleaning up some of the dock widgets.

Expected Results

A context system to manage the context of actions.

Context system used to manage the context of several ambiguous actions within Creator.

If time allows, several other improvements like a new Welcome dialog.

Knowledge Required
Experience with Qt/KDE development.

Skill Level
Medium

Mentor
Arjen Hiemstra / Shantanu Tushar Jha

Project: Profile Support in Gluon Engine

Brief Description
Gluon as engine currently runs on several platforms, including Plasma Active based tablets and the Nokia N9. However, while it runs, it is not yet really playable. One major reason for this is that the games currently do not adapt to the platform. The example games have all primarily been designed with a keyboard and mouse interface, which for obvious reasons does not work well on a phone or tablet. The idea is to implement something called profiles to enable game developers to define what properties should change at which moment.

Expected Results

A usable first version of profiles.

Profiles can modify anything in the project to adapt the game to a certain device.

Profiles can be created and modified from within Gluon Creator.

Knowledge Required
Experience with Qt Development. Some experience with Game programming is a plus.

Skill Level
Low - Medium

Mentor
Arjen Hiemstra

Project: Implement Saving/Loading Gluon Engine's Game State

Brief Description
One important missing feature in Gluon Engine is a way to save and load game state and that way make it possible for players to save their game and continue playing at a later moment in time. The first step in this process is to be able to serialize a game to a user-local folder (i.e. ~/.gluon/games/$game/saves) and restore from that. Once that is in place a system is needed to determine differences between the initial game state and the current game state. With that system, it should then become possible to save and restore only that which changed; greatly reducing the size of saved games.

Expected Results

Gluon Engine to be able to save and load game states.

A system to determine the differences between two game states.

Make it possible to only save changes instead of the entire game state.

Knowledge Required
Experience with Qt Development. Experience with Game programming - in particular Scene Graphs - is a definite plus.

Project: Message Filtering Plugin System

Brief explanation:

Add support like Kopete/Gmail for various message processing tasks, if the URL contains an image, showing this image, same for for youtube links, translating messages, replacing swear words, and any other idea you can come up with.

Expected results:

Student should create a plugin system, which can load plugins, allows configuring plugins, and has an interface for enabling/disabling these. The student should also make a range of plugins, these should be suggested by the student.

Project: Enhancement to peer-to-peer dbus

Brief explanation:

With p2pdbus merged in qt 4.8 and DBusTubes branch that will be released soon, we still have the problem that in peer to peer DBus there is no DBus server, so it is difficult to know when something happens (registering and unregistering of objects and services). It would be really nice if we could have an object that we can register on the connection as the first object and that gives you an interface similar to the DBus server one.

Project: Simon workspace integration (Voice control the KDE desktop)

Brief explanation: The speech recognition system Simon is currently based around the concept of being individually configured for each application that is going to be voice controlled. While this works fine for smaller installations it gets tedious in the many cases where no special configuration is needed and the user "just" wants to browse application menus, select buttons, etc.

The protocol AT-SPI (version 2) exports information about control elements of applications on the DBus interface at a toolkit level (no effort needed from application developers). This system is already used for screen readers like Orca.

Simon should be able to parse this information of running programs, generate the necessary vocabulary, grammar and commands to trigger any on-screen buttons, menus, etc. This gives Simon control of running Qt and GTK applications without any specific configuration. Work on this has already begun last year and resulted in a working prototype: http://www.youtube.com/watch?v=mjVc8bKRdqA

This project would be to extend the given prototype to a fully functional system.

As AT-SPI 2 (and especially the Qt bridge for it) is very new, this also involves working together with the developers of that technology as well as colaborating with developers of Qt and Gtk to ensure full functionality across a wide array of applications.

Expected results: Better AT-SPI support from Qt and Gtk resulting in more Widgets being exposted correctly. A Simon plugin that listens to AT-SPI messages on DBus and can take advantage of the new information (see the video of the prototype linked above).

Project: Support SPHINX

Brief explanation: Internally, Simon uses the HTK to handle acoustic model compilation and adaption. As a recognizer, the Julius reconition engine is used.

While those components have proofed to be reliable and work quite well, their development is not very active and both have complicated licenses. The HTK license for example, does not allow redistribution and requires a registration to download the HTK source code.

CMU SPHINX from the Carnegie Mellon University can replace both the HTK and Julius, is licensed under the permissive BSD license and included in most major distributions. Additionally, it's actively developed, widely supported and a lot of free acoustic models are already available.

Expected results: A fully functional Simon using SPHINX (no HTK and no Julius) including support for (SPHINX) base models.

Project: Face Detection and Face Recognition for Simon

Brief explanation: A major obstacle for command and control speech recognition systems is to differentiate commands from background noise.
Many system solve this by requiring physyical buttons or certain key phrases to activate the speech recognition.

This project explores the use of computer vision to determine when to activate / deactivate the recognition using visual cues.

For a media center or robot applications for example, it would make a lot of sense to only activate the recognition when the user is actively looking at the screen / robot. This also matches a natural "human to human" communication.

Furthermore, face recognition could be employed to provide different speech models for different people. That way a media center could adapt to different people in one household.

Expected results: A face detection / recognition context condition that activates or deactivates a microphone / acoustic model in Simon based on the presence of a user.

Knowledge Prerequisite: C++, Qt; Knowledge of opencv or other computer vision libraries a plus but not absolutely required

KDE Accessibility

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.

Plan:
I would suggest to setup atspi2+qtatspi and try if Orca/Accerciser are working ( http://community.kde.org/Accessibility/qt-atspi ). atspi2 provides a dbus-service (qdbusviewer) and what we would try to begin with is to write some small qt/kde test-application that connects with that dbus-service and provides us the information when the focus changed. What we need is something like

means an signal/event to connect with and that is emitted if the focus changed and the x/y screen-coordinates where the focus is now. Once we have such a test-application a big part of the work we would do within the gsoc is done. Adapting kmag and kwin comes after that.

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 <mail@dipe.org>

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.

Many small patches in order to emit the right signals to the accessibility framework

Implementation of QAccessibleInterfaces for custom widgets used in KDE

Knowledge Prerequisite:

C++/Qt

Python is a bonus as it will make understanding Orca easier

Reading code - you will look at code from many different applications and try to fix small issues there

Build applications, kdelibs and Qt

Mentor:
Frederik Gladhorn <gladhorn@kde.org>

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.

Project: Improve star hopping feature in KStars

Brief explanation: Star hopping is a technique that is often used by amateur astronomers to locate objects in the sky. It uses brighter objects as a guide for finding fainter ones. Many good star hopping tutorials are available on the web.

KStars currently has an experimental implementation of star hopping (tools/starhopper.cpp and tools/starhopper.h) that uses A* algorithm. It's currently not configurable - it would be good to give user the possibility to specify equipment used during session and then use this information to create better star hopping lists by adjusting cost function. Also, changing the way star hopper feature is enabled by the user is worth considering. The option to print star hopping list together with instructions and basic information about intermediate objects would be desirable. Classes that comprise extended star hopper feature should come with proper unit tests.

Please note that this is relatively simple project, so extending it with other ideas and tasks is welcome.

Open Collaboration Services

Aim of the Open Collaboration Services API (OCS API) is the integration of web communities and web based services into desktop and mobile applications. It's free, open, scalable, secure, privacy protected and vendor independent. It was designed by openDesktop.org and was defined as an independent standard by freedesktop.org. It is an open and vendor independent modern REST based API

Project: Extend attica (OCS client lib) with JSON interface support of the Standard

Brief explanation:
There has just been a very fresh discussion on the OCS mailing list about standardizing the JSON output. We came to the conclusion, as you can read in that thread, we definitely support it, but there is a demand for reference implementations. Attica has already been existing for a while having XML output support. The task would be to extend attica and the KDE support of that in kde-runtime to support the JSON bits of the Standard. It would be a great addition for GamingFreedom, OpenDesktop.org, Apps4Meego, Plasma, Get Hot New Stuff and so forth.

Expected results:

Integration of the JSON parser into the attica client library code

Extend the functionality of the KDE runtime attica operation used by plasma, GHNS and so forth

Properly documented code

Unit testing framework extension

Feedback about the attica codebase in general, and also about the standard

Knowledge Prerequisite:
C++/Qt development

Skill level: medium.

Mentor:
Laszlo Papp

DrKonqi

Project: Improve DrKonqi's bugzilla integration

Brief explanation:
DrKonqi, our crash handling and reporting tool, has the ability to communicate with the bugzilla at bugs.kde.org, but currently it uses html parsing techniques to do that. This is generally bad as it doesn't guarantee that drkonqi will continue to work with future bugzilla versions. The aim of this project is to port DrKonqi to use bugzilla's XML-RPC API, which is the standard and stable way of communicating with bugzilla.

In addition, there is another junior-job that could probably be done in the same time frame. To find out which product to report bugs to, DrKonqi currently uses a simple map file that maps executable names to products on bugzilla. This file is bundled together with DrKonqi and updating it on the users' machines requires the users to update their whole KDE SC to a newer version. A better idea would be to have some simple server-side service on bugzilla that provides these mappings and have some logic inside DrKonqi to fetch new mappings from there if possible.

Expected results:
Drkonqi should be fully capable of fetching, reporting and manipulating bug reports through bugzilla's XML-RPC API and if time permits it, it should also be able to fetch product mappings from some server.

Project: Improvements to keyboard layout configuration and display

Brief explanation: 1. Currently when user adds/configures the keyboard layout he can only follow the layout/variant name to tell how the keys are laid out, or apply the config and try it in the text field. It would be nice to be able to display the chosen keyboard layout graphically. Note similar functionality already implemented in virtual keyboard applet so we can borrow some ideas if not code from there.
Note: Gnome keyboard layout configuration UI does it already.

2. Currently when user has multiple keyboard layouts and types in some text he often must look at the tray icon to tell which layout is current. With multiple windows opened for different tasks that use different languages this may be quite a burden to what the tray for layout. Also sometimes the task bar is minimized adding more burden on the user. Often user will start typing and then realize the wrong layout is selected.
It would be much nicer if text input cursor (AKA caret) would display current layout - this way when user fixes his eyes on the text field he'll be typing in he can tell right away which layout is active. This can be as simple as color or the caret or more complex, like a flag, or layout label.

Expected results: 1. When keyboard layout is selected/configured in system settings display it graphically so that user can see what he chooses.
2. New option to indicate current keyboard layout with text input cursor. Potential solutions: configuring color of the caret for each layout; allowing flag or label to appear on the caret. Note: this display should not be intrusive so it may need to be of small size, semi-transparent etc.

Knowledge Prerequisite: C++ and Qt

Mentor: Andriy Rysin

Project: Automatic layout switching based on text input context

Brief explanation: Currently when user switches to the input field he always have to switch keyboard layout. Remembering last layout per application window helps a bit but even the same window may have different languages to accept. It would be nice if we can use the context of the text input to try to switch layout automatically. E.g. if user enters text in the browser we could check the language of the html page and adjust the keyboard layout accordingly.
Note: this might be not a short term project but we could lay out some foundation in GSOC.

Expected results: There is a lot of research in this feature. We need to find out what input contexts are detectable, what information about the language we can extract, which additional options we need (e.g. automatic choice might work poorly in some environments so we might need to let user disable it for some applications/windows etc), also if automatic choice was made and user had to switch manually to correct we may try to remember that and adjust the automatic switching accordingly next time. If we can have good description of potential contexts, their language tags, and some code to detect those contexts and languages that would be a good result for this project. If we can do more that would be fantastic.

Knowledge Prerequisite: C++ and Qt.

Mentor: Andriy Rysin

Forum

Project: Plasmoid and Data Engine to interact with forum.kde.org

Brief explanation: KDE should make it as easy as possible to get support. For this it would be great to have e.g. a Plasmoid on the default desktop just saying "Get Help". This could be a lightweight interface to forums.kde.org. The user does not need to know that he uses a forum behind the scenes. But also for supporters it could be a great help to have a dedicated application to do the support instead of having to use the web browser.

Expected results: A Data Engine for forum.kde.org is implemented which uses the xml resources provided by OCS. A QML based plasmoid is written which can be used both on mouse driven devices as well as a fullscreen application on tablets. The UI should be tailored to make it as easy as possible to get help but also allow more advanced usage for supporters. At least browsing forums, reading threads and replying should be possible.

Knowledge Prerequisite: C++ and Qt.

Mentor:' Martin Gräßlin, maybe a forum admin?

KDE on Windows

Project: make a usable kdevelop

Brief explanation:
One of the interesting but complex applications is KDevelop. KDevelop so far can be build and also doesn't crash right away, but most features do not work. There are two big issues that need to be addressed: There is no debugging plugin (the gdb plugin is not build) which makes kdevelop less usefull. Building inside kdevelop has several disadvantages since you cannot set up a specific environment from inside kdevelop - you currently must run kdevelop inside the environment you want to build with. This also means that some of your settings can change the behaviour of kdevelop.

Expected results:
a simple debugger with some basic features and a way in kdevelop to handle different build environments.

Okular

Project: Tile based rendering in Page view

Brief explanation:
When displaying a document, Okular currently renders complete pages at once. At higher zoom levels, this simple approach to rendering requires large amounts of memory to hold the rasterized pages. The maximum zoom level in Okular is therefore currently capped at 400%, but users frequently report a desire for higher zoom levels to be supported. Your project will be to answer these requests and improve Okular's general memory efficiency by implementing a new, tile-based approach to page rendering: Instead of rendering a full page at once, the page is to be divided into smaller tiles, and only the tiles intersecting the viewport are then actually rasterized. As the viewport moves over the document new tiles need to be rasterized, and no longer visible tiles need to be evicted from memory.

Choqok

Choqok is a feature rich KDE based microblogging client for Linux with an intuitive interface. It makes keeping in touch with friends and communities through microblogging services like Twitter and StatusNet joyful and easier than ever before - and it looks good doing it!

Project: Facebook support in Choqok

Brief explanation: Support for microblog services in Choqok implemented through special plugins, and it's easy to extend Choqok to support more services via developing new microblog plugins. And now we have a large demand on supporting Facebook in Choqok.
There's a library wrote to use in Akonadi Facebook resource, that implemented some functionalists of communicating with Facebook website. This task needs extending that library to our needs, and then using it as the plugins backend to communicate with Facebook. then implementing and extending Choqok UI to have facebook like posts inside Choqok, such as sharing links, images, videos, adding like or comment under a post, seeing other users comments and likes. (except Facebook chat functions)