GSoC/2012/Ideas: Difference between revisions

From KDE Community Wiki

< GSoC | 2012

Latest revision as of 09:19, 30 March 2013

Guidelines

Information for Students

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

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

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

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

Adding a Proposal

Note

Follow the template of other proposals!

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

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

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

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

Ideas

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

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!

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

Project: QMLify Amarok's context view (taken)

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.

Some interesting reading:

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 (taken)

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.

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

Mentor: Teo Mrnjavac, and Vishesh Handa for Nepomuk

Project: Social music - Tomahawk features in Amarok (taken)

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.

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

Mentor: Bart Cerneels

Project: Amarok unit testing

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

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

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

Mentor: Teo Mrnjavac or another Amarok core team member

Project: Spotify Collection (taken)

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

Project: Implement MediaArtStorageSpec

Brief explanation: MediaArtStorageSpec provides a mechanism for applications to store and retrieve artwork associated with media content, like music from an album, the logo for a radio station, or a graphic representing a podcast. The storage medium for artwork is a file system, inside a user's home directory.

Originating from the GNOME project it's already in use by Banshee and tracker on the Nokia N9 smartphone.

https://bugs.kde.org/show_bug.cgi?id=296049

Expected results: If we save album art using this spec it will be picked up by those applications. If we search for album art using this spec we avoid overhead and reduce code complexity.

This can be implemented in the Amarok CollectionScanner, nepomuk and other KDE components where it makes sense.

Knowledge Prerequisite: C++, Qt

Mentor: Bart Cerneels for Amarok, wider KDE developer base for more integration.

Only large scale integration proposals (i.e. more then just Amarok) will constitute a full GSoC Available for Season of KDE

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.

Website

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, Sage, Kalgebra, Octave, Scilab, Qalculate), so this should be a feasible project. To have an example: Scilab backend for Cantor

Knowledge Prerequisite: Cantor, C++ and Python (a plus: Numpy / Scipy / Matplotlib)

Mentor: a mentor from the Cantor Project

digiKam

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

Project: Camera User Interface Revamp

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

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

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

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

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

There also the technical TODO list relevant of this project

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

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

Mentor: Gilles Caulier

Project: Port kipi-plugins and libkipi to KDE XML-GUI

Brief explanation:

digiKam needs to be able to host and manage all kipi-plugins actions into standard application tool-bar. Currently, it's not possible due to use a plugin architecture which do not use KDE XML-GUI API.

See relevant entry in KDE bugzilla about this project :

122454

This project sound simple but it's a little bit hard to implement, due to huge list of code to patch, in libkipi, all kipi-plugins, and all KIPI host applications (digiKam, Gwenview, KphotoAlbum, KSnapShot, etc...)

In digiKam we have 2 plugin architectures : one for Album GUI named as kipi-plugins shared through libkipi with all other KIPI host applications, and one for image editor, not shared with the rest of the world.

In digiKam, KIPI plugin interface have been written 1 year before image editor plugin interface. This last one use already KDE XMLGUI API. libkipi no, and it's the problem...

Typically, image editor plug tools in GUI using KDE XML features, which is very flexible and automatize very well plugins mechanism and plugin host interface.

In opposite, KIPI plugin interface plug tools in GUI using an hard-coded way, which is not flexible. We cannot manage plugin action through menu and toolbar easily without to recompile code. KDE XML-GUI store GUI configuration in XML file which are loaded at run-time. Configuration through KDE setup dialog to customize menu, toolbar, and shortcuts is also trivial to do in source code.

Historically, When KIPI interface have been written, KDE XMLGUI API still under development. We have published libkipi too quickly, and all plugin host applications have implemented a dedicated and hardcoded plugins interface...

Expected results:

To be more powerfull, KIPI interface must be re-implemented using XMLGUI API. This require to patch and branch libkipi into future 2.0 release (currently 1.6). To be compatible with older KIPI host application release, deprecated plugin architecture must still available during a transition time. Also, as each KIPI host application has a dedicated place to store plugins actions in main menu, a solution must be found to provide a way to customize menu for each plugin.

Knowledge Prerequisite: C++, Qt, KDE

Mentor: Gilles Caulier and Angelo Naselli

Project: Video metadata support

Brief explanation:

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

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

See relevant entries in KDE bugzilla about video support :

164442 229543

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

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

Mentor: Gilles Caulier and Andreas Huggel

Project: Clone Tool for Image Editor

Brief explanation:

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

See relevant entry in KDE bugzilla about it :

132483

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

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier or Marcel Wiesweg

Project: Video Slideshow Generator

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

See relevant entry in KDE bugzilla about it :

153061

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

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

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier and Angelo Naselli

Project: Face Recognition

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

See relevant entry in KDE bugzilla about it :

271679

Expected results:

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

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

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

More ideas here [1].

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.

See relevant entries in KDE bugzilla about :

269929 160893

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.

See relevant entries in KDE bugzilla about :

242119 257313

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

Brief explanation: Improvement Of Noise Reduction tool adjust settings automatically with image contents.

See relevant entry in KDE bugzilla about it :

166820

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

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

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

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

Knowledge Prerequisite: C++, Qt

Mentor: Torsten Rahn

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

http://techbase.kde.org/Projects/Marble/NaturalEarth

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 <[email protected]>

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.

Expected results:

duty: refactored code that separates rendering from visibility management
"icing": an OpenGL mode

Mentor: Torsten Rahn <[email protected]>

KDevelop

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

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

Project: 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.

Knowledge Prerequisite: C++/Qt knowledge required, QML/Plasma knowledge would definitely help a lot

Mentor: Aleix and/or Milian

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

Project: Ruby Language Support

Brief explanation: Work on the experimental Ruby language support, offer basic navigation and DUChain integration features.

Expected results: Uses of variables, modules, mixins, etc. pp. are reported in Ruby files. Basic code completion works. Navigation using the context browser tools works. Quickopen shows Ruby features. Maybe even a Ruby-specific "create class" wizard is created.

Knowledge Prerequisite: C++, Qt, KDevelop, Ruby

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.

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

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

Project: Improve HTML composing

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

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

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

Mentor: TBD (Torgny Nyblom is available as a co-mentor but does not have the time for full mentorship)

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, QML, C++

Mentor: Kevin Krammer, contact at [email protected]

Project: Improve KOrganizer templates

Brief explanation: The template support in KOrganizer is hard to discover and use. Templates should be able to be managed without having to go into the incidence editor.

Expected results: A new "Manage Templates" dialog should be implemented that allows the user to create, modify or delete templates for calendar events, to-dos and journals. This dialog should be accessible via the KOrganizer menu as well as the incidence editor. Extra features nice-to-have include:

assigning shortcuts to each template
inserting New->from Template-> into the KOrganizer and Kontact menus
modifying the incidence editor to have [Load from Template] and [Save as Template] buttons

Knowledge Prerequisite: C++, Qt

Mentor: TBD

Calligra Karbon

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

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

Project: 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.

Students applying for Krita should start getting into the community around January and should have a really good level of programming competence. The easy things are done, now we've got some real challenges.

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

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

Irc channel: #krita on irc.freenode.net

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

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

Project: Perspective Drawing:

Brief explanation:

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

Expected results:

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

Knowledge Prerequisite:

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

Mentor:

Boudewijn Rempt

Project: Add an infinite canvas/wraparound mode to Krita

Brief explanation:

Krita is a 2D painting application with a focus on texturing, matte painting and comics drawing. For texturing, we need to expand the Krita image model in two ways: 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.

Mentor: Lukáš Tvrdý

Used technologies: C++, Qt

Resources: http://www.krita.org

Project: 3D Material Image Maps

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

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

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

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

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

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

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

Mentor: Boudewijn Rempt

Project: Matte painting

Brief explanation:

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

Expected results:

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

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

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

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

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

Knowledge Prerequisite:

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

Mentor: Boudewijn Rempt

Project: Colour Managed Printing

Brief explanation:

Krita supports many colour spaces. On printing currently all colours are converted to sRGB and then send as a print file to the print system. Thus Krita can not use the large colour gamut of modern photo printers or use user selectable colour spaces. As Krita has so many gifts regarding colour management, it would be desirable to make Kritas printing similar good colour managed like displaying.

Expected results:

Detect the actual image colour spaces for tagging image content in the print spool file.

Detect a printer profile by asking the local or remote print device ICC DB according to actual settings.

Provide a user profile selector with entries fitting the make and model of the actual printing device. Adapt print settings according to the selected ICC profile

Allow to print non colour managed for calibration and generating new ICC profiles.

OpenUsability, OpenPrinting and OpenICC outlined a concept on how to best integrate colour management into the Common Printing Dialog (CPD). Use the code resulting from last year and enable colour management inside the print dialog of the Krita painting application.

Generate the standard PDF/X-3 spool file for best cross platform compatibility of print files.

Test the whole print stack and

provide necessary patches upstream.

Write end user documentation that users of the system can generate a own ICC profile. Describe how to share that ICC profile and set the printer up on a different location. Describe some basic means how to check the printing path uses a actual selected ICC profiles from End to End.

Knowledge Prerequisite:

C++, Qt, git, good communication. Some knowledge of the Linux/CUPS printing stack and of ICC colour management terms are very helpful.

Resources:

Concept - http://www.oyranos.org/wiki/index.php?title=Device_Settings#CUPS

libCmpx - print library http://www.oyranos.org/libcmpx/

Oyranos - CMS http://www.oyranos.org/support/

Mentor: Kai-Uwe Behrmann

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.

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

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

Irc channel: #calligra on irc.freenode.net

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

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

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.

Knowledge Prerequisite: Qt/C++, Knowledge of Calligra code is a plus. especially regarding plugins and spellchecking

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

Project: Bbiliography and reference engine integration.

Brief explanation: Calligra Words have the basics for bibiliography but we want it extended so it can use external engines too. All in all we want a complete, high class, fully working system

Expected results: It should "just work"

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

Mentor: Gopalakrishna

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.

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

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

Irc channel: #calligra on irc.freenode.net

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

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

Project: 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…

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

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

Irc channel: #calligra on irc.freenode.net

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

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

Project: Improve OpenFormula-support

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

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

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

Sources are at;

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

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

Knowledge Prerequisite: Qt/C++

Mentor: Sebastian Sauer <[email protected]>

Calligra Kexi

Project: Add multimedia support to Kexi

Brief explanation: Implement multimedia support for Kexi Forms and Kexi Tables

Propose, design and implement multimedia (sound, video) support for Kexi Forms (as an interactive media view widget for video and a slider widget like [2] 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):
1. 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
2. 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 your ideas and extensions regarding the storage, e.g. caching locally previews of the video/audio
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
For information about the way of delivering form widge, see description for similar task

Used Technologies: C++, Qt, Phonon or Qt Multimedia or equivalent

Mentor: Jarosław Staniek, please contact [email protected]

Calligra Plugins

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

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

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

Irc channel: #calligra on irc.freenode.net

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

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

Project: Improve saving of charts to OpenDocument

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

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

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

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

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

Knowledge Prerequisite: Qt/C++

Mentor: Sebastian Sauer <[email protected]>

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 looks of drawn formula components like the square root sign, summary signs or integration signs.
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 <[email protected]>

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.

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

Irc channel: #calligra on irc.freenode.net

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

Project: 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.

Expected results: Editing functionality in CA, with a minimum of-

Basic text selection, insertion, replacement
Cut/Copy/Paste support
Font formatting - Font name, color, size
Font styling - Bold, Italic, Underline
Alignment - Left, Center, Justified etc

Being able to insert Images will be a plus

Knowledge Prerequisite: C++ and Qt. QML and/or familiarity with Calligra codebase is a plus

Mentor: Shantanu Tushar < shaan7in @ gmail dot com >

KDE Games

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

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.

Mentor: Please inquire on the mailing list.

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.

Knowledge Prerequisite: C++, Qt, and basic QML.

Mentor: Please inquire on the mailing list.

KWin

KDE Plasma Compositor and Window manager

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

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

Knowledge Prerequisite: C++/Qt/KDE development - QML/JavaScript knowledge a plus

Mentor: Martin Gräßlin / someone from Plasmate

Nepomuk

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

Project: Testing and Benchmarking in Nepomuk

Brief explanation: While working on Nepomuk we need ways of quantifying our improvements, and require tests that benchmark the frequently used classes and services. Additionally, since we land up optimizing and changing the internals we need a good set of unit tests (there are quite a few), and system tests. Example - Testing it a file is reindexed on modification.

Expected results: Tests for all the frequently used services. Benchmarks for all APIs, probably with some nice graphs showing virtuoso usage and memory consumption.

Knowledge Prerequisite: C++/Qt/KDE development, CMake knowledge (preferable), and some knowledge about Nepomuk would be nice.

Mentor: Vishesh Handa

Plasma

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

Project: Lazy/Asynchronous Plasmoid Inititalization

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

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

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Aaron Seigo / Harald Sitter?

Project: 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.

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

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?)
implement the Encoder in the backends (phonon-vlc, phonon-gstreamer)
design somewhat similar to AudioDataOutput or VideoDataOutput
test by transcoding various media

Expected results: Possibility for transcoding media, encoding video from capture sources with Phonon (with the phonon-gstreamer, phonon-vlc backends)

Knowledge Prerequisite: C++, Qt, basic multimedia

Mentor: Trever Fischer

Solid

Solid is the KDE sub-community of everything related to Hardware support.

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

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Project: Easy partitioning in Solid/Dolphin

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

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

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

Mentor: Dario Freddi <[email protected]>

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.

Knowledge Prerequisite: C++/Qt/QML/KDE development, some knowledge about network management.

Mentor: Lamarque V. Souza <[email protected]>

ownCloud

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

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

Project: 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, Frank Osterfeld

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

Note: this project is about implementing the storage api, not the sync api. In the end ownCloud should be an alternative programm to the sync server.

Knowledge Prerequisite:

Programming in PHP (ownCloud), reading Python code is useful for examining existing implementations.

Mentor:

Jakob Sack

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.

Knowledge Prerequisite:

Programming in PHP/JS, HTML/CSS

Mentor:

Bartek Przybylski

Project: Collaboration rich text document editor

Brief explanation:

Provide simillar functionality to Google Docs wich enabling collaboration, importing, exporting etc of various types of documents doc/xls/etc.

Expected results:

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: Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. AThe 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.

For GSoC 2012, you would continue work on the Usability Survey Framework from GSoC 2011.

Expected results:

Complete the survey question parser and Plasmoid user interface
Work with a KDE project to design a USF study and develop one or more USF services for that project
Lauch a pilot USF study and make improvements to the framework based on results and feedback on the tool
Develop additional survey features such as the ability to customize how often a survey is launched, new types of survey questions, pausing a survey and starting it again, automatically sending study results to the project, or an OpenDesktop subscription service, etc.

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.

Mentor: Technical Mentor: Matt Rogers, project-specific developers? Design Mentor: Celeste Lyn Paul, others?

Gluon

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

Gluon Website

Contacting the Gluon team (irc, email etc)

Project: 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 (not available anymore for mentoring this task)

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: Dan Leinir Turthra Jensen / Laszlo Papp (just only if needed)

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 (if needed)

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 (probably DBus Tubes since the lack of own protocol existing)
Establish a well-defined vision for chatting (text messages), and then implementation
Establish a well-defined vision for audio interaction, and then implementation
Extra: video interaction using the same API as for audio
Further extra point, if the library work can be integrated into several frontends, like the KDE Desktop Player (kde-telepathy/telepathy-qt), or Harmattan (telepathy-qt), etc.
No secure messaging needed at this point, like Off-the-Record (ie. cryptographic protocol) since it does not have proper support yet on the Telepathy side (WIP though).
If there is time remaining: screenshots, introduction videos and blog posts about this feature would be nice.
Meanwhile the situation looked better on Linux about two years ago, it would be nice to get it tested in Windows environment as a plus, if possible (not mandatory though).

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.

Skill Level
Medium - High

Mentor
Arjen Hiemstra / Dan Leinir Tuthra Jensen

Telepathy

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

More information:

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

Project: 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.

Knowledge Prerequisite:

C++, Qt and KDE libs.

Mentor:

David Edmundson <[email protected]> Discuss on our mailing list <[email protected]>

Project: Telepathy setup for KDE multiplayer games

Brief explanation:

Telepathy can set up TCP connections (streamtubes) between contacts, multiplayer games in KDE Games could use this for easy setting up multiplayer games.

Expected results:

Porting KsirK/KBattleShip to use Telepathy
Implement multiplayer in one "static" game (board/card game)
Writing some sort of gaming library for measuring latency over telepathy for "dynamic" games (ksnake or similar) and implement multiplayer in another game

Knowledge Prerequisite:

C++, Qt, KDE Libs

Mentor:

Daniele Domenichelli <[email protected]> Discuss on our mailing list <[email protected]>

NOTE: We need to discuss this with KDE Games.

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.

Expected results:

Knowledge Prerequisite:

Qt and serious mad Dbus skillz,

Mentor: Daniele Domenichelli <[email protected]> Discuss on our mailing list <[email protected]>

Project: Collaborative editor

Brief explanation:

A simple text editor demonstrating collaborative features of Telepathy streams. This collaborative editor should allow two or more people to edit the same plain text document.

This could be expanded into a collaborative version of basket.

Expected results:

A working collaborative editor.

Knowledge Prerequisite:

C++, Qt, Operational Transform

Mentor: David Edmundson <[email protected]> Discuss on our mailing list <[email protected]>

simon

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

There is also a demonstration video on youtube.

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

Knowledge Prerequisite: C++, Qt

Mentor: Peter Grasch <[email protected]> (simon) Frederik Gladhorn <[email protected]> (Qt)

Contact: [email protected] or through the forum on forum.kde.org: http://forum.kde.org/viewforum.php?f=216

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.

Knowledge Prerequisite: C++, Qt

Mentor: Peter Grasch <[email protected]>

Contact: [email protected] or through the forum on forum.kde.org: http://forum.kde.org/viewforum.php?f=216

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

Mentor: Peter Grasch <[email protected]>

Contact: [email protected] or through the forum on forum.kde.org: http://forum.kde.org/viewforum.php?f=216

KDE Accessibility

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

Project: Focus tracking in KWin and KMagnifier

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

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

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

QDBusConnection::sessionBus().connect("org.kde.kaccessibleapp", "/Adaptor", "org.kde.kaccessibleapp.Adaptor", "focusChanged", this, SLOT(focusChanged(int,int)));

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.

Links:

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

Expected results:

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

Knowledge Prerequisite: C++/Qt

Mentor: Sebastian Sauer <[email protected]>

Project: Screen reader friendly KDE applications

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

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

Project: Plasma Accessibility

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

Project: Adding support for HTML5 Text to Speech and Speech Recognition

Brief explanation: HTML5 provides introduces a new HTML elements that allows plain HTML sites to take advantage of accessibility technologies like TTS (text to speech) and ASR (automatic speech recognition): http://www.w3.org/TR/voice-tts-reqs/ http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html

While the new elements are still only part of a draft, some of the functionality is already implemented in e.g. Google Chrome.

With Jovie and Simon both TTS and ASR (resp.) exist and could be used to implement the proposed HTML tags.

Expected results: Working, basic ASR and TTS in Konqueror (using the Webkit kpart) and Reqonk.

Knowledge Prerequisite: C++, Qt

Mentor: Webkit: ? Simon: Peter Grasch <[email protected]> Jovie: Jeremy Whiting <[email protected]>

Contact: [email protected] or through the forum on forum.kde.org: http://forum.kde.org/viewforum.php?f=216

KStars

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

Project: Autoguiding in KStars

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

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

Knowledge Prerequisite:

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

Mentor: Jasem Mutlaq

Project: Improved 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.

Expected results: Reliable and configurable star hopping feature in KStars with possibility to print star hopping instructions.

Knowledge Prerequisite:

Good knowledge of C++, Qt and KDE libs.
Basic knowledge in astronomy would be a plus.

Mentor: Rafal Kulaga (rl.kulaga - at - gmail.com, IRC: rkulaga)

Project: Sky guides feature in KStars

Brief explanation: This feature is targeted particularly at beginners in the field of amateur astronomy. The idea is to create XML file format that will enable anybody to create guides which can be then published in the same way as custom star catalogs are. In the longer perspective, a feature that will enable creation and editing of such guides directly from KStars (without the need to manually edit XML files) should be implemented.

On the technical side, sky guides could be implemented as a neat QML-based side panel of the KStars' main window. Mockups are welcome in project applications.

This feature has been partly developed as a part of SOCIS 2011 project. It hasn't been finished as we have decided to focus on other issues. Currently only XML file format for sky guides and classes that represent guides, slides etc. are mostly finished. Code related to sky guides feature is located mainly in the socis2011-skyguides branch. XML schema definition file for sky guides is /kstars/data/skyguides.xsd.

Extensions and other ideas are welcome.

Expected results: Aesthetically pleasing and complete sky guides feature, optimally with a few example files.

Knowledge Prerequisite:

Good knowledge of C++, Qt and KDE libs.
Basic knowledge in astronomy would be a plus.

Mentor: Rafal Kulaga (rl.kulaga - at - gmail.com, IRC: rkulaga)

Project: Improve 'What's up tonight' feature in KStars

Brief explanation: Currently, 'What's up tonight' feature, although working, might not be optimal for observation planning. The idea is to extend it with the option to filter out objects which can't be observed with the equipment that user possess and ones that are not interesting for the user for other reasons. Resulting objects should be then presented as a chronological list with possibility to print it (integration with KStars printing features would be a great plus).

Extensions and other ideas are welcome.

Expected results: More functional 'What's up tonight' feature, integrated with KStars printing features.

Knowledge Prerequisite:

Good knowledge of C++, Qt and KDE libs.
Basic knowledge in astronomy would be a plus.

Mentor: Rafal Kulaga (rl.kulaga - at - gmail.com, IRC: rkulaga)

Project: Improve data storage in KStars

Brief explanation: Currently, KStars uses CSV (Comma-Separated Values) files to store data, both created by user (e.g. annotations) and sky objects data (e.g. satellites, supernovae, stars). This approach is not only hard to manage, but can cause bugs (as in bug #279026). The idea is to migrate this data to SQLite database, although it is not clear if all sky object data should be stored this way, including huge star catalogs like USNO NOMAD.

This project has already been approached in the past - unfinished version is available in gsoc2010-carbonix branch of the KStars repository. Successful project application should describe what data will be stored in the database and outline database structure.

Expected results: Robust and flexible data storage in KStars.

Knowledge Prerequisite:

Good knowledge of C++, Qt and KDE libs.
Good knowledge of SQL.

Mentor: Rafal Kulaga (rl.kulaga - at - gmail.com, IRC: rkulaga)

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

Current Spec Draft Version

Social Desktop

Attica

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

Project: QML interface for GHNS

Brief explanation: Get Hot New Stuff (or KHNS) was designed with KDE desktop in mind. Meanwhile it is a powerful util and project, we are in an urgent need of similar paradigm for mobile platforms. The current user interface needs a complete overhaul since it does not fit well for the handset and tablet world. Many application depends on such requirements that GHNS provides currently on desktop. For instance, KHangMan or the Kanagram educational games inside the KDE Edu module. These applications are (being) ported to mobile platforms like Harmattan (N9), Nemo/Mer or Plasma Active (Spark/Vivaldi). Unfortunately, they have lost the feature set they used to have on desktop. Virtualized environment is enough for developemtn and testing purposes, thus no worries about gadgets not available.

Expected results: Create new reference implementation for the aforementioned mobile platforms or even for desktop based upon the QML technology. The more integration with the platforms, the better. The main goal is to make the functionality super simple and intuitive for usage and touch friendly for sure. The backend implementation is more or less available, but might need more minor adjustments (ie. khns currently lacks the ability to define a developer account so that in-app purchases can be associated with a proper developer).

Knowledge Prerequisite: C++/Qt/QML development

Skill level: medium.

Mentor: Laszlo Papp (not anymore for this, saturated with other students very early :/)

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

Knowledge Prerequisite: You should know C++/Qt and you also shouldn't be afraid of native Windows API. You must be able to set up a build environment for KDE on Windows.

Mentor: Patrick Spendrin (SaroEngels on #kde-windows)

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.

Expected results Support for higher zoom levels and reduced memory consumption.

Knowledge Prerequisite C++, Qt

Mentor Albert Astals Cid

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!

Website - Identica group - IRC channel: #choqok on Freenode.

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)

Some sources:

Expected results: Fully functional and usable Facebook website replacement plugin for Choqok

Knowledge Prerequisite: C++, Qt and KDE development. and JSON data format

Mentor: Mehrdad Momeny

Kate

Kate is a powerful programmer's editor.

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

Project: Script IDE

Brief explanation: Kate supports versatile scripting in its part. This is for example used for the indentation scripts and some of the commands available in the kate command line. Still missing is any real integration into the Kate GUI which allows easy creating of new script, debugging them and for example binding the interactively to shortcuts. The goal of this project would be to implement a Kate application plugin which provides the user with the means to edit, debug and run scripts for the kate part. In addition the interfaces to the kate part should be extended to allow access to the scripting features. For example the plugin could provide auto-completion for the scripting API or/and a own highlighting for kate js scripts could be done.

Expected results: A Kate plugin providing some scripting IDE to create and debug kate part scripts.

Knowledge Prerequisite: C++/Qt, high motivation

Mentor: Dominik Haumann / Christoph Cullmann

Project: Further Improve Kate's Vi Input Mode

Brief explanation: Kate supports a Vi input mode that allows one to use modal editing with Vim commands. This support is already quite good and most common operations in normal, visual mode and insert mode are supported. However, there are still some rough edges in the integration with Kate. These include missing support for using search as a motion (e.g. delete to the next occurrence of “foo”: d/foo), and integration with folded code being sub-optimal.

There is an open list of bugs/feature requests against the Vi Input mode at https://bugs.kde.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=vi%20input%20mode&list_id=8960

A candidate should plan to fix some of these bugs. The three aforementioned bugsmissing features are considered quite important.

Expected results: An improved Vi input mode with some of these features implemented (with tests).

Knowledge Prerequisite: C++/Qt, high motivation, being a user of Kate's Vi mode or Vim

Mentor: Erlend Hamberg

Kooka/Skanlite

Project: DejaVu Generator with OCR support for Kooka or Skanlite

Brief explanation: See this thread in kde-devel

Expected results: Having a standalone program which would allow the user to create DejaVu files scanning paper documents.

Knowledge Prerequisite: C++/Qt

Mentor: Jonathan Marten

KDE Edu

KAlgebra/Analitza, improve equations support

Brief explanation: Improve further the support of equations solving in Analitza, by making it possible to support more types of functions like ax**2+bx+z=0

Expected results: More unit tests and more unit tests that pass :)

Knowledge Prerequisite: Qt, algebra, some understanding of what is an AST

Mentor: Aleix Pol

KAlgebra/Mobile, a mobile keyboard

Brief explanation: Design and implement a keyboard to be able to use it on a mobile system such as Plasma Active or Android.

Expected results: A touch-friendly on-screen keyboard that appears when an input field is selected.

Knowledge Prerequisite: Qt, some mathematics and some idea of how to implement a touch friendly UI

Mentor: Aleix Pol

Retrieved from "https://community.kde.org/index.php?title=GSoC/2012/Ideas&oldid=30951"

Category:

Mentoring