GSoC 2015 logo

See also: GSoc Instructions, Last year ideas


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

Follow the template of other proposals!


Brief explanation:

Expected results:

Knowledge Prerequisite:


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.


Your Own Idea

Project: Something that you're totally excited about

Brief explanation: Do you have an awesome idea you want to work on with KDE but that is not among the ideas below? That's cool. We love that! But please do us a favor: Get in touch with a mentor early on and make sure your project is realistic and within the scope of KDE. That will spare you and us a lot of frustration.

Expected results: Something you and KDE loves

Knowledge Prerequisite: Probably C++ and Qt but depends on your project

Mentor: Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Freenode IRC.


Amarok is a Music player that helps you organize and rediscover your music.

Project: Port Amarok to Qt5/Kf5/Plasma5

Brief explanation: Currently Amarok still depends on kdelibs 4.x and Qt4.

Expected results: Amarok should compile with Qt 5.x, kdelibs4 dependencies should be replaced with kf5. Port most existing plasma widgets of the Context View to Plasma 5 (at least the most important should be ported). The default system themes should apply to Amarok flawlessly. A very important part of this project is testing the port and adapting the unit tests.

Knowledge Prerequisite: good knowledge of C++/Qt, ideally being familiar with kf 5 and Plasma 5. The student should have some basic knowledge of the Amarok project and its functions as well as its architecture. All relevant information about Amarok, Qt5, kf5 and Plasma 5 can be found online, every suitable applicant should be able to find this documentation on their own.

Mentor: To be determined. All discussions about the project should be held on the mailinglist and/or on IRC


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

Project: Re-write database KIO-slaves as pure Qt5 using multithreading

Brief explanation: Originally, KIO-Slaves have been implemented to run database queries in a separated process to prevent problem with SQlite. Since SQlite support re-entrancy and queries from separated threads, digiKam KIO-slaves used to process complex and long database queries can be re-written as core implementation using Qt thread API. This will improve digiKam availability in time when system is updated in low-level, and permit to adjust finely CPU cores assigned to database process.

Dependencies: : digiKam core from "framework" branch (KF5)

Links: Using Sqlite in multi-threaded application, Bug #146557

Knowledge Prerequisite: C/C++, Qt, database, multi-threading

Expected results: Identify all parts of digiKam core which query database through KIO-slaves mechanism, factorize code in same interface and write a multi-threaded wrapper to run SQlite queries. Write test code to check quickly if database core implementation changes don't affect wrapper functionality. Note : digiKam use internally URL + XML formating to pass data to KIO-slaves and this not be changed.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>

Project: Advanced Metadata HUB

Brief explanation: digiKam has already some options to manage workflow between image metadata and database, through the setup/metadata configuration panel. The goal of this project is to write a more advance setup to control finely the most important metadata field in order to read from image and populate database and vis versa. The list of metadata to drive must be easily extensible and configurable. Also, the metadata workflow to synchronize image with database must be more flexible and must provide a way to synchronize files at end of digiKam session and not only in real time (typical case : editing image tags to write in images).

Dependencies: : digiKam core and libkexiv2 from "framework" branch (KF5)

Links: Bugs list from bugzilla

Knowledge Prerequisite: C/C++, Qt, database, multi-threading

Expected results: Create metadata hub widget for settings panel, adjust current hub and image scanner implementations, add test code.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>

Project: Add WebP and WebM support

Brief explanation: WebP/WebM is new wavelets based image/video format from Google, based on RIFF/MKV container. This format become more popular on the Web and both can be used through an open-source library. We need to support these formats as editable in digiKam (WebP) and manageable by database mechanism through metadata (WebP and WebM).

Dependencies: : digiKam core and libkexiv2 from "framework" branch (KF5), Exiv2 library

Links: WebM format, WebP format

Knowledge Prerequisite: C/C++, Qt, Metadata

Expected results: Patch Exiv2 library to support both formats in read/write meta-data mode and add optional WebP support in digiKam core to be able to edit images (read/write image contents in 16 bits color depth). Write test code to check new functionality in time.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>


Marble is a virtual globe and world atlas — your swiss army knife for maps. Find your way and explore the world!

(projects to appear here. Please ask in #marble in the meantime)


KStars is a very powerful tool for anyone interested in astronomy. It is part of the KDE Edu suite.

Project: Fix our deep-sky data handling

Brief explanation: Currently, KStars handles data from deep-sky object catalogues in an SQLite database. While this is working well, there are some more features we would like to have, and some that should be implemented in order to sanitize the deep-sky data handling, such as automatic cross-referencing of deep-sky objects across catalogs, organizing deep-sky data better in the database etc using Hierarchical Triangular Mesh, etc.

More details here:

Expected results: Some, or all of the improvements to deep-sky handling suggested above (or maybe even your own suggestions), implemented completely in solid, release-worthy code.

Knowledge Prerequisite: C++, Qt, understanding of astronomical catalogues, some experience with data structures.

Mentors: Rafal Kulaga (IRC: rkulaga)

The student will need to:

  • Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC timeframe.
  • Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2014.

PS: If all this looks daunting, that's because you have not (yet) talked to us. If you're really interested, get onto #kde-kstars and ping the mentors.

Project: Propose your own project

Brief explanation: If you have some interesting ideas about KStars that can be implemented within the GSoC timeframe, you are very welcome to propose them, because we seem to have run out of ideas.

Mentors: Rafal Kulaga (IRC: rkulaga)


Project: Semi-Automatic Generation of Language Lessons for Parley

Brief explanation: Parley is an advanced vocabulary trainer with features like 8 different learning modes, including flashcards, genders of nouns, conjugation of verbs and several more. A lesson for Parley is encoded in kvtml, KDE Vocabulary Training Markup Language which is an XML format for vocabulary lessons of many different types.

But it is a relatively demanding task to create good lessons for Parley. You need to manually edit a list of words in several different languages, add images and/or sound clips to them all, word class, pronounciation, etc.

We would like to create a semi-automatic generator for lessons using the Kexi database in the Calligra suite. The workflow will be something like this.

  1. You use an import script to import a selected part of the word list in, an online wiki dictionary, into Kexi. This will then form the basis for the work on the lessons.
  2. You define a list of words in the so called primary language, which is the language that the lesson is supposed to teach. This list will be the words only and could be created either using the editor inside Parley or a standard text editor and then import it into Parley.
  3. You define which secondary languages you want in your lesson. These languages are the ones that the student is already familiar with. The training session will then consist of translations from one of the secondary languages (most often the native language of the student) and the primary language. At this point you also define which other parameters you want to include in the lesson, like image, sound clip, phonetic text, explanation, etc.
  4. You invoke the automatic lesson generator which will search for the words you have defined in the database, look up suitable translations and add the other fields that you asked for.
  5. If necessary, patch up the newly generated lesson with missing data that wasn't present in the database or add the information to the database and redo the generation.

Goals: The goal is to create software that supports the workflow above. It will at least comprise the following tasks:

  1. Define an efficient database schema for the words and translations. has 3.6 million entries and even a subset of that can take significant amounts of storage.
  2. Implement a script that reads from and enters the data into the Kexi database using the calligradb library. There is already a script for downloading and parsing the contents of Wiktionary at [1] but you will have to adapt it to Kexi.
  3. Implement the code that searches the database and populates the lesson with the data found.
  4. (If time permits) Implement a more advanced lesson editor than is currently present in Parley or a stand-alone editor.

Knowledge Prerequisite: Good knowledge of C++ and Qt, a plus is knowledge of of kvtml and the related C++ classes in the kde edu libraries. Also some knowledge of databases and database searches.

Mentor: Jaroslaw Staniek, the maintainer of Calligra Kexi, with help from Inge Wallin


Project: Integrate Cantor into LabPlot

LabPlot is a KDE-application for interactive graphing and analysis of scientific data.

Brief explanation: The integration is twofold:

  1. currently, for the created plots LabPlot uses either the data provided by hand in a spreadseet or by using data imported from external ascii-files. By having Cantor within LabPlot it should be possible to access the data sets created in a computer algebra session (say Maxima) provided by Cantor. Cantor's session have to be integrated into LabPlot's model-view framework and have to be put onto the same foot as all the other objects managable in LabPlot (spreadsheet, worksheets etc.).
  2. By calling a CAS-specific command for creating a 2D-plot in Cantor, Cantor creates an external process that renders the plot and embeds the result as a pixmap. Instead of such a static pixmap, LabPlot's plots should be embeded. This would provide high degree of control of the plot appearance as provided by LabPlot.

Mentor: Alexander Semke

Project: Integrate VTK into LabPlot, investigate Tulip

LabPlot is a KDE-application for interactive graphing and analysis of scientific data.

Brief explanation:

  1. LabPlot lacks 3D-functionality. In the old KDE3-based LabPlot qwt3D was used for this that is not an option anymore. The task consists of the integration of VTK -libs. Also, the relevant widgets for 3D-plot editting should be created in a manner similar for all the other objects available in LabPlot now.
  2. Investigate whether it's reasonable to use LabPlot as a frontend (or to extend it to be a frontend) to the functionality provided by Tulip yes, how?

Mentor: Alexander Semke

Project: Port of GCompris in Qt Quick

GCompris is a an educational software suite comprising of numerous activities for children aged 2 to 10. Originaly written in Gtk+ it's development team decided to rewrite it from scratch in Qt Quick. It has also been decided that this version will be integrated in KDE which is the reason of the project being here.


  1. Porting several GCompris activities in Qt Quick. There is a page that tracks the porting effort that will help you select the activity set you are interested in.
  2. Creating new activities. There is a list of ideas of activities that have been identified as something we would like to have. You can also propose original ideas not on the list.

Knowledge Prerequisite: By the start of GSoC you should

  1. Be interested in children education
  2. Be familiar with GCompris concept and content
  3. Basic knowledge in a programming language (a 1 year school course is enough)
  4. Be able to build the Qt Quick version of GCompris

Application guide:

  1. Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphishm and the sounds are already available. You can count 1 week of development for a basic activity.
  2. To keep the work interesting it is recommended to propose a mix of porting some activities and creating new one, either from the idea list or from an original idea you come with.
  3. You have to follow the instructions here and provide your exercise as a pull request.

Mentor: Bruno Coudoin (IRC: bdoin #gcompris on freenode)


Kexi is a visual database creator. It can be used for designing database applications, inserting and editing data, performing queries, and processing data.

More info: Developers' wiki, web site for users, mailing list, IRC channel: #kexi and #calligra on Freenode.

Project: Add support for importing tables from LibreOffice Base to Kexi

Status: assigned.

Brief explanation: Add support for importing (Kexi calls it data/design migration) tables from LibreOffice (or OpenOffice) Base (ODB format) to Kexi. This task involves research on ODB format (it's relatively openly defined). Qt/C++ shall be used for the task together with Java engine (HSQLDB) and probably connected via JNI. This could be introduction to later development of complete database import from ODB to a Kexi database.

Expected results: In the GUI the feature shall be put in the same place as the import from MDB: External Data -> Import Tables -> Table Importing Wizard. Then user would see .odb support in the open file dialog, just like it has access to importing CSV or MDB.

Knowledge Prerequisite: C++, some Qt, some databases, some XML, software architecture

Mentor: Jarosław Staniek (Kexi maintainer)

First steps:

  • See [1] for a start.
  • Sample .odb databases are available for this tutorial.
  • Studying kexi/migration/importtablewizard.cpp which is a GUI taking an instance of implementation of a migrate driver derived from KexiMigration::KexiMigrate (in your case - the ODB driver). It's the m_migrateDriver attribute.
  • Implementing plugin (needed methods of the driver) in migration/odb/ by looking how it was performed for other cases, e.g. for mysql (see kexi/migration/mysql/ dir) or other cases such as pqxx, txt, xbase, sybase or mdb
  • In the actual C++ implementation, KoOdfReadStore class from calligra libs can be used to read contents of the .odb.

Other requirements in our way to success:

  • commit changes to student's public branch at least once after each workday, not after a milestone
  • developing wire-frames/prototypes of the software in advance, especially important since the solution is rather hybrid
  • documenting them and developing/designing tests while the development progresses, not as the last step
  • developing both C++/Qt side of the solution as well as the Java side in parallel to catch possible difficulties earlier
  • putting the tasks in calendar (we may use e.g. a public Google calendar for that) so we can track the status

Calligra Author

Project: An Outliner for Calligra Author

Brief explanation: Calligra Author is a tool that will help writers create e-books. The two main target groups are novelists who write very long texts with complex and subtle relationships between different parts of the story and writers of e-textbooks that need features like multimedia and mathematical formulas.

The Calligra Author project has identified four main phases of the writing process, and we intend to support them all in various ways. They are:

  • Concept and Planning
  • Writing
  • Review
  • Publishing

Until now the new features have been mainly supporting the last 3: writing (distraction free writing mode, insertion of separators), review (notes/annotations) and publishing (support for book covers and export filters to epub and mobi formats). This project is about the first phase: concept and planning. What we want to do is an outliner, which is a well-known concept in other writer's tools. See [1] [2] [3] for all necessary details.

Goals: The goal is to create an outliner for Calligra Author. The following requirements will determine the project:

  • There should be user-definable categories in the database, but "Actors", "Items" and "Places" should be pre-defined by default.
  • The main object is the "scene" A scene is defined as a text snippet of any length with connections to the database so that objects, places and items that are used in the scene can be clearly marked as such. Note that this means both items that are actually present in the scene and those that are merely mentioned. Possible metadata for a scene includes a textual description, actors, items and places that appear and/or are mentioned or referred to.
  • The users should have views that identify relationships between these categories, such as "this item is used in this scene by that actor in that place".
  • There should be timing relationships between scenes so that mistakes can be avoided (like events that happen later are mentioned in a scene that happens earlier).
  • The scenes should be groupable to any hierarchy forming chapters, subchapters, and even books. These groups will form an ordered tree.
  • The final text will be created by an ordering of the scenes in the tree with suitable headers entered in between.
  • File format for storing this is still an open question but using the Open Document Format is a big plus. An idea is to use so called ODF sections as the snippets because these are embeddable into each other and RDF triples for the metadata. The database format can also be RDF triples since this database will most likely not very big.

Knowledge Prerequisite: Good knowledge of C++ and Qt, a plus is knowledge of the open document format and the related C++ classes in the kde Calligra libraries.

Mentor: Inge Waliin, maintainer of Calligra Author

[1] [2] [3]

Keyboard Layouts

Keyboard layouts in KDE allow user to use multiple keyboard layouts and switch between them. It consists of keyboard configuration module (in System Settings), keyboard layout widget/applet, and keyboard layout daemon.

Project: Integrating Input Methods with keyboard layout configuration

Brief explanation: Input method and keyboard layout configuration are serving the same purpose - to allow users to type text in non-default language. Currently KDE has integrated system to configure keyboard layouts but IM need to be configured somewhere else. Also when IM is configured it takes over some functions of keyboard layout configuration. So it would be nice if we could have IM and keyboard layout configuration in one place. It seems that IBus has already gained community acceptance so this will be the target for integration into KDE keyboard module.

Expected results: Keyboard configuration module in System settings will include IM configuration and it will be integrated with existing keyboard layout options.

Knowledge Prerequisite: good knowledge of C++, development experience with Qt and KDE, understanding of Input Methods (IBus)


Project: Clang Integration

Brief explanation: Finish the kdev-clang plugin to make it a usable replacement for the existing C++ plugin.

Expected results: Find the still missing features from the KDevelop4's C++ support and port them over to kdev-clang, so it can become the mainstream C/C++ Solution

Knowledge Prerequisite: C++, Qt. Knowledge about Clang is helpful

Mentor: Kevin Funk

Project: Checker Framework

Brief explanation: A generic framework should be created which provides the foundation for other plugins to report errors.

Expected results: Right now we have the problems toolview but it is tightly coupled to the DUChain. This should be changed to use a separate item repository which stores the problems for a given path. The data stored would be: Path and range of where the issue is found, a short error message and optionally a long description. Furthermore, plugins might want to store additional info from which the problem could be fixed (compare to the 'add include path' or similar wizards we have already in the language framework).

This framework should then be used to integrate various tools.

First of all the existing language plugins should show the problems they find there. The existing playground plugins for krazy and cppcheck integration should reuse that framework any other linters could be integrated, such as jslint, pylint, clang-check, etc. pp. runtime checkers could be integrated, such as valgrind's memcheck, ptrcheck, helgrind, drd, ...

Knowledge Prerequisite: C++, Qt. Knowledge of debugging tools is helpful.

Mentor: Milian Wolff

Project: SVN Plugin Rewrite

Brief explanation: Rewrite the SVN plugin to use the C-API directly.

Expected results: The existing SVN plugin uses an outdated kdevsvncpp checkout internally which causes troubles, warnings and licensing issues. Port the plugin to either the C-API of svn or alternatively try to reuse code from current kdevsvn. The result should be a tested, working plugin for SVN integration without licensing issues nor compile time warnings about usage of deprecated API.

Knowledge Prerequisite: C, C++, Qt, SVN

Mentor: Milian Wolff

Project: LLDB Support

Brief explanation: Write a new plugin to support LLDB on KDevelop

Expected results: Come up with a new kdevelop plugin so that LLDB can be used as a debugging solution, especially on Mac OS X and Windows, where gdb support is rather scarce.

Knowledge Prerequisite: C, C++, Qt, debugging intrinsic problems

Mentor: KDevelop team


The KDE PIM community work on a set of libraries and applications for Personal Information Management, including email, calendaring, contacts, and feed aggregation.

Project: OpenHolidays

Brief explanation: The KHolidays library provides KDE applications with information on public holidays around the world, however the file format is very hard to use and maintain and the library features are very limited and restricted to Qt users. The goal of the OpenHolidays project is to develop a new open standard and data repository that can be used by any project that needs the data. See for more details.

Expected results: Define the new JSON file format and port the existing data files to the new format. Develop a shared Qt-only library to parse the holiday files and provide access to them with a iCal style event-based api. Implement an Akonadi resource to access the data. Extended goals: Develop a JavaScript library to use the files. Develop a web site and web service at to provide online access to the data files.

Knowledge Prerequisite: C++ and Qt for core goals, JavaScript and web services for extended goals.

Mentor: John Layt and other KDE PIM community members.

Project: Active Mail

Brief explanation: Active Mail is a QtQuick based mail application, a touch input friendly version of KMail so to speak. Currently it still depends on QtWidget based user interfaces for certain tasks which will have to be replaced before Active Mail can live up to its promise. Such missing pieces are the email composer and the email viewer.

Expected results: Define and implement a general QtQuick API for composing emails. Rework the Active Mail composer UI/UX with the help of our usability expert and make it shine.

Knowledge Prerequisite: C++, Qt, QtQuick

Possible Mentors: Thomas Pfeiffer, Michael Bohlender, Kevin Krammer

Project: QtQuick ToDo API / Plasmoid

Brief explanation: KDE PIM wants to make it's data accessible for applications which use QML to declare their user interfaces, e.g. applications using QtQuick. For that they need data handling objects that are accessible through QML, e.g. item models that have a mapping of string based role names to enum value based roles in C++, etc.

Expected results: Define and implement a general QML API for accessing and creating Akonadis ToDo data. Write / Port a ToDo Plasmoid for Plasma Desktop or Plasma Active to show off the new API. Bonus: Port Kontact Touch Task to the new API instead of, or in addition to the Plasmoid.

Knowledge Prerequisite: C++, Qt, QtQuick

Possible Mentors: Kevin Krammer, Michael Bohlender and other KDE PIM community members

Project: KPeople / Kontact Touch People

Brief explanation: KPeople is a KDE framework for aggregating contact information of people from various data sources, e.g. the user's addressbook and instant messaging programs. For the future KDE would like this to be the main source of data for its address book application.

Expected results: Define and implement a QML API for accessing kPeoples features. Create a pretty QtQuick example App/Plasmoid to show off and prove the API. Bonus: Bonus: Port Kontact Touch Addressbook to the new API instead of, or in addition to the Example.

Knowledge Prerequisite: C++, Qt, QtQuick

Possible Mentors: Martin Klapetek, Thomas Pfeiffer and other KDE PIM community members

Project: Akonadi Commandline/Shellscripting Interface

Brief explanation: Akonadi is a system that enables uniform access to various data formats across a wide range of data sources. Its main clients are graphics end user applications such as KMail. However, in some cases it is advantageous if data manipulation can be automated. Power users or system administrators often employ the multitudes of Unix/Linux commandline tools to achieve such automation tasks. The idea is to provide a tool or set of tools that allow Akonadi operations to be used in such scripts.

Expected results: A non-GUI program able to perform useful tasks on Akonadi provided data, like creating folders, adding/deleting/copying/moving data such as contacts or emails, etc.

Knowledge Prerequisite: C++, Shell scripting

Mentor: Jonathan Marten, Kevin Krammer and other KDE PIM community members

Resources: An early prototype can be found here and there are two, non-Akonadi, clients which are part of KDE PIM: kabcclient (contacts), konsolecalendar (calendar) Contact the kde-pim mailinglist for discussions:


Simon is a speech recognition suite.

Website - Mailing list - IRC channel: #kde-speech on Freenode.

Project: Streamline handling of various resources

Brief explanation: Simon uses a multitude of different components: Scenarios, Base models, Shadow vocabulary, Language profiles, etc.

While many of these components can be downloaded from within Simon, some can't and even for those that are better integrated, end-users still have to read additional documentation to know which components work together and which don't.

The aim of this project is to bring the handling of these resources under a uniform and user-friendly interface. Specifically, the interface should resolve conflicts automatically and deduce an optimal default setup by itself (e.g. based on the system language and installed programs).

Expected results: Much more user friendly setup.

Knowledge Prerequisite: C++/Qt

Mentor: Peter Grasch <peter {+at+}>

Resources: Some work (mostly brainstorming and UI design) was already conducted during Season of KDE 2013. Please contact me for details. This does not mean that this project is already assigned!

KDE Telepathy

Project: Conference Video Call Support

Brief explanation: Our current IM client can handle a 1-1 video call reasonably well. It currently does not support conference calls (>2 people). Our backend Telepathy should support this, but we do not make use of it in our client. This project will involve

  • some UI design
  • some low level GStreamer work
  • fixing parts of the Telepathy stack.

Current code is inside the repository ktp-call-ui.

Expected results: Working multi conference video calls.

Knowledge Prerequisite:

  • C++, Qt
  • Ideally; QML, GStreamer and Telepathy

Mentor: David Edmundson and Diane Trout

Project: Telegram Network Support

Brief explanation: Telegram is an upcoming network that aims to replace WhatsApp. Unlike whatsapp it has an open protocol ( and is gaining popularity.

We want support in our IM client. This should be done by creating a connection manager using TelepathyQt service bindings.

When this is complete, not only will we get Telegram support, but due to the distributed nature of Telepathy it will also work for Jolla, Ubuntu Phone and Empathy.

Expected results: Working single and group chats using KDE Telepathy over the Telegram network

Knowledge Prerequisite: C++, Qt, Reading Protocol Documentation

Mentor: David Edmundson


Project: iOS Integration

Brief explanation: Integrate the iOS platform with the Plasma desktop using libraries like libimobiledevice and kdeconnect.

Expected results: Have an iOS application that is able to talk to KDE Connect and desktop integration using libimobiledevices.

Knowledge Prerequisite: C++/Qt, Objective C

Mentor: Àlex Fiestas <afiestas {+at+}>

Resources: libimobiledevice, kdeconnect, plasma

Project: Improve KDE Connect encryption

Brief explanation: We want to implement better encryption algorithms in KDE Connect, as discussed here:

Expected results: Have a secure encryption algorithm implemented in both KDE (C++/Qt) and Android (Java) clients.

Knowledge Prerequisite: Deep knowledge about encryption and security.

Mentor: Albert Vaca <albertvaka {+at+}>

Resources: kdeconnect

Project: Make Libbluedevil Async

Brief explanation: Extend libbluedevil to have an asynchronous api, and port bluedevil to it.

Expected results: libbluedevil should have an asynchronous api, and bluedevil should be ported to them.

Knowledge Prerequisite: basic Qt and DBus

Mentor: Àlex Fiestas <afiestas {+at+}>

Resources: libbluedevil, bluedevil, afiestas

Project: Improve sharing experience

Brief explanation: Improve the content sharing experience in Plasma by extending and improving Samba share, implementing other ways of sharing and write new ways of discovering other people's shares.

Expected results: It should be possible to discover "shares" using dolphin (possibly via a new kioslave?) and it should be possible to share a folder between two Plasma computers really fast and easy (possibly implementing an http server plus discovery via avahi).

Knowledge Prerequisite: C++/Qt, extra points for KIO experience.

Mentor: Àlex Fiestas <afiestas {+at+}>

Resources: avahi, http, kdenetwork-fileshare


Project: Better support for your distribution

Brief explanation: Muon needs to be ensured to work perfectly on any distribution, this project should target one of the (major) distributions, enumerate the problems to solve and propose solutions.

Expected results: Muon users of your distribution will be happy ever-after.

Knowledge Prerequisite: C++/Qt, the technology required for the platform

Mentor: Aleix Pol

Plasma Media Center

KDE's Plasma Media Center (PMC) is aimed towards a unified media experience on PCs, Tablets, Netbooks, TVs and any other device that is capable of running KDE software. PMC can be used to view images, play music or watch videos. Media files can be on the local filesystem or accessed with KDE’s Desktop Search.


Unless explicitly noted, one of the follwing will mentor for the selected proposals-

  • Shantanu Tushar
  • Sinny Kumari

Please use plasma-devel AT to discuss your ideas and proposals.

Project: Integrate with Simon

Brief explanation: Simon is an open source speech recognition program that can replace your mouse and keyboard. The system is designed to be as flexible as possible and will work with any language or dialect. This project aims at integrating it with Plasma Media Center to control it.

Expected results: Using Simon, the user should at least be able to use voice to -

  • Control playback of media (images, music, videos)
  • Navigate in the media browser (next page, previous page, "goto the 3rd item")
  • Home Screen navigation
  • Ability to switch to the player, image viewer, or playlist
  • Play a media file in the browser (or the playlist, when its shown) using its name

Knowledge Prerequisite: Basic C++, Qt and QML

Co-Mentor: Peter Grasch <peter {+at+}>

Project: Integrate with Plasma Next

Brief explanation: Plasma Next is the refreshed Plasma workspace written using the new KF5, Qt5 and QtQuick2 frameworks. Plasma Next is able to switch to different modes/formfactors on-the-fly (such as desktop, netbook, tablet). We want to be able to make Plasma Next able to switch into a media center mode.

Expected results: After the project is complete, the Plasma Next shell should be able to switch to a Media Center mode and offer every feature that the standalone Plasma Media Center application provides. Examples are ability to browse media, playback, playlists etc.

Knowledge Prerequisite: Qt, QML is required. Understanding of Plasma Next is a huge plus

Resources: Some info about Plasma Next

Project: DVB Support for TV

Brief explanation: is a KDE media player which supports playing TV using DVB. Our users have ben requesting for this support in PMC as well so that it becomes possible to watch TV as well.

Expected results: Once the project is completed, Plasma Media Center should be able to play streams from a TV card with DVB support. There should be feature parity with Kaffeine.

Knowledge Prerequisite: Basic C++, Qt and QML. Access to DVB hardware and signal availability in student's region is mandatory for testing

Mentor: Mentor wanted with DVB knowledge for the DVB bits.


Project: KDE Reports

KDE reports is a project started during GSoC 2013. It currently displays reports about bugs, commits, mailing lists and IRC Channels. Website: source code:

Brief Explanation: The app currently uses Rails 3.2. The test suite needs to be completed and the project should be upgraded to use Rails 4. Also, more reports are to be added. For example, forum activity, social media activity, blog activity( and and others.

Expected results: Upgraded reports app with a complete test suite and more reports.

Knowledge Prerequisite: Ruby and Rails

Mentor: Ben Cooksley (bcooksley at


Trojitá is a fast IMAP e-mail client. Since late 2012, it is a part of KDE's extragear. The project focuses on delivering a usable, fast, standards-compliant, cross-platform and reliable e-mail client which can scale from cell phones to huge e-mail archives without annoying slowdowns.

Project: Add support for secure messaging to Trojitá

Brief explanation: It would be cool to have support for encrypted and signed messages, both with GnuPG and S/MIME (X.509). The QCA library provides the required infrastructure, but this task would still require a fair bit of hacking, including working on a client-side MIME parser in Trojitá.

Expected results: Add support for creating, reading and verifying the GnuPG and X.509-wrapped messages.

Knowledge Prerequisites: Decent knowledge of C++ programming, familiarity with Qt, willingness to use GPG. Being able and willing to work with the community.

Must-have checklist: Get in touch with the developers, subscribe to the mailing list, learn how to use Trojitá. Perhaps there are some features that you find lacking -- go and add them. Perhaps there's a bug which is annoying -- fix it! Get involved in Trojita's development. It is a prerequisite to have at least one patch in Trojitá in order to be considered for application.

Mentor: Jan Kundrát <[email protected]>

This page was last edited on 9 March 2016, at 10:38. Content is available under Creative Commons License SA 4.0 unless otherwise noted.