GSoC/2013/Ideas

See also: GSoc Instructions, Last year ideas

Guidelines

Information for Students

These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.

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

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

If there is no specific contact given you can ask questions on the general KDE development list [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.

Adding a Proposal

Note

Follow the template of other proposals!

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

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

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

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

Ideas

Amarok

Project: Reimplement Amarok 1.4/iTunes import on top of Statistics Synchronization and add more synchronization targets

Brief explanation: Since early 2.x versions, Amarok had an ability to import personal track metadata such as play count, rating and last played time from either Amarok 1.4 database or iTunes datbase. This works fine, but once the data are imported and one still uses the other audio player, the metadata of both players drift away. A new statistics synchronization framework was added in Amarok 2.7. This project would deal with reimplementing the medatada importers on top of the new StatSyncing framework and adding 2 new synchronization targets: one for synchronizing with another Amarok 2.x database and one for synchronizing with another popular audio player of student's choice (which needs to support the personal metadata; perhaps Clementine).

Implementing the import on top of StatSyncing will have following advantages:

• it can be used repeatedly to synchronize data rather than one-time to overwrite them
• it increases code reuse, the code to match tracks by metadata and to visualize the synchronization is already there
• StatSyncing works with any set of collections, not just with Local Collection (useful e.g. if one wants to use just Nepomuk Collection)

Expected results: Importing metadata from Amarok 1.4 or iTunes will work no worse than it does currently (with the exception that matching will be done solely by track metadata such as title and album) and synchronizing with more players (Amarok 2.x and at least one more) will be possible.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers)

The student will need to:

• understand principles of Amarok StatSyncing framework (under src/statsyncing/ in source code repository)
• understand how current database importers work (these are under src/databaseimporter/)
• understand how the other audio player of choice stores personal metadata (this is student's own work, mentors cannot help much here)

...before the coding period starts.

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Rewrite Audio CD Collection so that it doesn't use deprecated technologies

Brief explanation: As of version 2.7, Amarok supports audio CDs, somehow. Somehow means that it isn't reliable, uses technologies (audiocd KIO) in a way they weren't meant to be used and prevents deprecated Amarok frameworks (MediaDeviceFramework) from being ditched. Aim of this project is to rewrite the AudioCD Collection from scratch to use appropriate libraries and to be more reliable. The new AudioCD collection should:

• use KDE's Solid to detect and enumerate CD drives and any CD media present. (it does currently, but it needs to be factored out of AudioCdConnectionAssistant to AudioCdCollectionFactory)
• use MemoryCollection, MemoryMeta and MapChanger components to represent and manage its tracks
• use libkcddb to asynchronously query CDDB information about the CD tracks
• audiocd KIO may be retained just for copying tracks out of AudioCD Collection or replaced entirely (preferable, but harder)
• (bonus point) if CD detection and track enumeration also works on Windows

Note that actual CD playback is handled by Phonon and is out of scope of this project.

Expected results: Reliable audio CD detection and track enumeration with asynchronous CDDB metadata fetching. This is a small to medium size project, so high level of polish will be expected.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers)

The student will need to understand how Amarok represents so-called Meta objects (tracks, albums...), Collections and track providers before the coding period starts. See the HACKING subfolder of Amarok source code, especially HACKING/architecture.

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Improving and modularizing tag guessing

Brief explanation: Amarok has been long able to get track tags (title, artist...) from MusicBrainz using either existing tags or using MusicIP audio fingerprints. In the mean time, MusicBrainz is phasing out MusicIP (PUIDs) in favour of AcousID and more services to guess/correct tags emerged. Goal of this project would be to:

• create generic framework for tag getters (may be similar in design to StatSyncing::Controller + StatSyncing::Provider)
• port existing (tag-based) MusicBrainz tag getter to it
• port and rewrite existing fingerprint-based MusicBrainz tag getter out of ffmpeg + libofa to Phonon + chromaprint (library to compute AcoustIDs)
• create new tag-based tag getter that uses Last.fm web service to get metadata corrections
• make MusicBrains Tagger use the new framework instead of hard-coding MusicBrainz usage. It will just run the invidual getters in parallel (using some kind of Tag Getter Controller) and display the results along with their source and score. Note that there is a pending review request dealing with MusicBrainz tagging and the dialog
• (bonus point) create new tag getter using the Last.fm Fingerprinter

Expected results: Getting tags from MusicBrainz will work the same, albeit with a better UI, using Last.fm to correct tags will get implemented and adding new tag guessers will be just a matter of implementing a documented abstract base class.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers), understanding how Web Services work

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

KDE Telepathy

Project: Add ConnectionManager bindings to TpQt

Brief explanation: KDE Telepathy, the IM client, uses the backend library TelepathyQt to power everything. We have library bindings for writing instant messaging clients in Qt, but not the backend connection manager to write protocols in TpQt. This has been started, but a lot of work is needed to make this finished. This will be a project in collaboration with the Telepathy project upstream at freedesktop.org.

Expected results: At the end of the summer we should have a completely working library for writing connection managers, with full unit tests.

Knowledge Prerequisite: Qt, C++ library design, unit testing, ideally usage of TelepathyQt already.

Mentor: KTp GSOC ML Group

Project: Collaborative text editor powered by Telepathy Tubes

Brief explanation: With Telepathy we can set up P2P DBus session between two contacts without the difficulty of servers and firewalls and low level TCP details. It would be great to use this to create a collaborative text editor that can be used for writing documents, or code.

What I expect to see in your proposal: Knowledge of collaborative text editors, and the main difficulty analysed. I expect to see what libraries you can re-use and a detailed list of what needs to be created.

Expected results: A working telepathy powered collaborative real-time text editor.

Knowledge Prerequisite: Qt, C++, Dbus, Telepathy

Mentor: KTp GSOC ML Group

Project: Finish KTp-Active

Brief explanation: KTp Active is our touch screen version of KDE Telepathy primarily for Plasma Active touch devices. It was started, but needs a lot to be release-able. Please read https://projects.kde.org/projects/playground/network/telepathy/ktp-active) and (http://www.blog.mentero.net/kde/ktp-active/bringing-ktp-active-to-life/

What I expect to see in your proposal: Knowledge of the current state of ktp-active, and a list of everything that doesn't work, and a plan of what needs doing

Expected results: A working tablet IM client that we can release as part of Plasma Active

Knowledge Prerequisite: Qt, C++, advanced QML

Mentor: KTp GSOC ML Group

Marble

Project: Marble meets owncloud

Brief explanation: Marble wants to be your swiss army knife for maps, owncloud brings your data under your control. Let's marry the two and bring cloud storage advantages to Marble without the usual loss of control: Enable Marble to store important data in owncloud and make it accessible (sync) to all Marble versions running on your desktop, laptop, smartphone.

Expected results:

• Marble: Sync bookmarks (and routing targets) with owncloud
• Marble: Save routes to owncloud, load routes from owncloud
• owncloud: View Marble bookmarks and routes on top of leaflet
• owncloud: Manage bookmarks and routes (view as list, delete)

And some possible extensions:

• workout mode: save tracks from jogging and other activities to owncloud
• track sharing: record your favorite bike, motorcycle, hike track along with pictures from your smartphone and share via kml and owncloud

Knowledge Prerequisite: Qt, C++, Javascript

Mentor: earthwings at gentoo dot org

Krita

Krita is a large and complex application. This year's project proposals are all heavy-weight and not suitable for someone who still needs to learn C++ and Qt. We also expect people to fix bugs and start working on Krita code before the summer of code starts. You need to prove that you can find your way around Krita's codebase and that you can code! Contact boud on #krita for more information. Note that these are just suggestions: your own ideas are very welcome!

For Krita projects, contact: Boudewijn Rempt ([email protected])

Project: Rewrite the OpenGL canvas mode

Currently, the OpenGL canvas uses outdated api's and doesn't work on Windows. We need a more modern approach, using the OpenGL 2ES subset to be compatilbe with mobile environments, as well as direct integration of OpenColorIO. There are a couple of issues to keep under consideration:

• integration with both lcms2 and opencolorio color correction
• support for monitors that do 10 bits/channel or higher
• efficient updating the textures that represent the image
• rotation, zoom, pan and image quality
• cross-platform: must work on Windows
• integration with tools that show decorations
• integration with 3D models that can be loaded as painting assistants
• performance: the current canvas limits the rate at which input events can be handled to the display update rate

You need good knowledge of OpenGL for this project, in addition to C++, Qt and a good grounding in multi-threading.

Project: Painting and Separation of 3D Textures

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: Animation Support

Animations are a hot topic among Krita users. There is already a start of animation support, but the author did not finish his work. Either you continue his work, or (better) start from scratch. This entails working with animators in our community to design and implement

• a new file format for storing animations based on Krita's native file format
• a gui for creating and manipulating animations
• a system to render animation frames

Project: 3D Material Image Maps

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:

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

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

Project: Matte painting

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. What's needed here is the following:

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

Project: Cartoon Text Balloon System

Krita already has two text tools, but neither is suited for creating cartoon balloons. The system should allow the creation of vector-based balloons in different styles. The balloons can contain styled text. The text and balloons should be translatable and a system to select the current language should be created. It should be possible to save the balloon text to a separate file that can be used as input for translations. Finally, care must be taken to support right-left languages.

Kexi

Project: Improve stability and packaging of the MS Access driver

Brief explanation: Current mdbtools sources included with Kexi for MS Access support are long outdated. Importing an mdb on a 64bit machine, crashes Kexi. Mdbtools sources should not be in Kexi, so that they can be updated separately. Mdbtools project is back on the run, and the user should be able to use the installed libraries. Trying to get people to move to Kexi from Access at some point, means the should be able to move their existing data/design also. This wish has been filed at https://bugs.kde.org/show_bug.cgi?id=277583.

Expected results:

• Use the newest mdbtools code from https://github.com/brianb/mdbtools and merge patches made by the Kexi project.
• Provide the patches upstream for the mdbtools project, which would improve packaging.
• Prepare Kexi buildsystem and/or code to switch to the original mdbtools package.

Knowledge Prerequisite: C, basic C++

Mentor: Jarosław Staniek (staniek at kde.org)

KDE Workspaces

Project: Port plasmoids to plasma2

Brief explanation: The plasma workspace is being rewritten on top of Qt5, Frameworks5 and Qml2. Some plasmoids are still in C++, some are already ported to QML1 (some to pure QML some mixed QML and C++). Some work will be needed both to port old c++ plasmoids (needing a complete rewrite) or QML1 plasmoids, that will need adaption in the parts where the plasma api changed.

Expected results: Production/port of at least 3-4 plasmoids loading and all their features working on the plasma2 shell prototype.

Knowledge Prerequisite: Good knowledge of QML, basic knowledge of C++ and some experience Qt programming

Mentor: Marco Martin <[email protected]>

Project: Port kde-workspace applications away from XLib

Brief explanation: In Qt 5 the XLib integration got dropped and (partially) replaced by XCB. The KDE workspaces have a tight integration with X11 and use many of the removed features like for example QPixmap::handle(). Most of these usages can be changed already now in the Qt 4 world which reduces the actual porting overhead. Another important area is the XEvent handling which is no longer possible. For easier porting this should be abstracted as much as possible. A summary of common problems can be found in http://community.kde.org/KWin/Qt5

Expected results: Kde-workspace is free of problematic code.

Knowledge Prerequisite: C++ idioms like RAII should be known. Knowledge about the X11 protocol is a clear plus

Mentor: Martin Gräßlin <[email protected]>

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.

Expected results: Effect Viewer application to test effects including simulation of all possible Windowing events

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Martin Gräßlin

Project: Present Windows/Desktop Grid rewrite in QML

Brief explanation: Present Windows and Desktop Grid are two KWin effects which could nowadays be better implemented using a QML based KWin Script. From the QML site everything is there except providing KWin's Clients as a model. Part of the project would be to write this model and some filter models to get e.g. Clients for just one desktop and the QML view to be shared between desktop grid and present windows on top of Plasma Components.

Expected results: Present Windows and Desktop Grid rewritten in QML, Model for KWin Clients added

Knowledge Prerequisite: QML, QAbstractItemModel and QSortFilterProxyModel

Mentor: Martin Gräßlin

Improved KWin effects configuration

Brief explanation: Provide a better user interface for managing KWin effects, so that a user can see which effects are mutual exclusive, which work together and which hardware is required for an effect. The module should be written with Qt 5's desktop components for QML. It should be possible to embedd only content to e.g. get a video preview.

Expected results: A new compositing configuration module supporting use cases like "effect for minimizing" and "effect for closing window" should be implemented.

Knowledge prerequisite: QML, usability experience

Mentor: Martin Gräßlin