Toggle the table of contents

GSoC/2011/Ideas: Difference between revisions

From KDE Community Wiki

< GSoC‎ | 2011

Latest revision as of 09:21, 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: 2010 ideas. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.

Generic

KDE Demo

*** Accepted for GSoC 2011 ***

Brief explanation:

KDE has developed a number of very interesting and powerful technologies, libraries and components but there is no easy way to show them to other people.

See "A wish a day: KDE Demo" for more details.

Expected results:

Something like Qt Demo but with KDE technologies.

Knowledge prerequisite:

C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better.

This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!).

Skill level: medium

Mentor: Pau Garcia i Quiles as general mentor and someone to ask for directions. Specific help for each technology will probably require help from its developers.

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 - IRC channel: #amarok on Freenode.

Project: Playlist sharing

*** Available for Season of KDE ***

Brief explanation: Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.

Expected results: A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.
A similar extention exists for Banshee: http://nloko.ca/?p=19 Compatibiltiy with this would be big plus.

Knowledge Prerequisite: Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.

Any of these are optional but not all of them.

Skill level: medium to high.

Mentor: Bart Cerneels or Ian Monroe

Project: Self Contained Collection

*** Available for Season of KDE ***

Brief explanation: The self-contained collection is a rough concept where the folders used as the location of tracks are not just plainly put into one Collection, so they would appear as one entry ("Local Collection"). Instead each top level folder configured in the settings would have it's own entry. So let's say the configuration is this: /home/user/music /mnt/nas/music

We would get 2 entries in the Local Music tab:

Local Collection from home folder
NAS Collection

So when not at home so the laptop is not connected to the NAS you won't see #2.

Expected results:

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

Skill level: medium.

Mentor: Someone from the Amarok team with in depth Collection knowledge. Contact Bart Cerneels (Stecchino on #amarok) for details.

Project: per-resource disabling of collections

*** Available for Season of KDE ***

Brief explanation: http://mail.kde.org/pipermail/amarok-devel/2011-March/008779.html

Expected results:

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

Skill level: medium.

Mentor: Someone from the Amarok squad.

Project: Podcast Synchronisation via gpodder.net

*** Accepted for GSoC 2011 ***

Brief explanation: gpodder.net is a Webservice that allows Users to synchronize their Podcast Subscriptions and Episode Status across different Devices. Amarok already contains a basic gpodder Service (used to display a Podcast Directory) and most API Calls of the Webservice can be accessed via libmygpo-qt. Your task would be to synchronise Podcasts & Episode Status in Amarok.

Expected results:

User subscribes to a Podcast via the gpodder.net Webservice. Amarok sees this new Subscription and adds it to the available Podcast Subscriptions.
User listens to an Episode of a Podcast in Amarok, stops Playback, leaves home and continues to listen to the Episode via the gpodder App on his N900
... and many more Use Cases you can think of ;)

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

Skill level: medium.

Mentor: Bart Cerneels (Project/gpodder.net/libmygpo-qt Information & Support via #amarok from HorusHorrendus)

digiKam

Photo Management program

digiKam project web site - Mailinglist - IRC channel: #digikam on Freenode.

Project: Camera UI Revamp

*** Available for Season of KDE ***

Brief explanation: DigiKam features a UI for accessing and downloading pictures from cameras. The 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 frontend, 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 reuse, 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.

UI design: The current interface 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.

Expected results: A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.

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

Mentor: Gilles Caulier? (Marcel Wiesweg)

Project: Presentation View

*** Available for Season of KDE ***

Brief explanation: The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.

The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album. You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.

Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.

Expected results: Something resembling the vision outlined above

Knowledge Prerequisite: C++, Qt

Mentor: Marcel Wiesweg

Project: MacOSX support

*** Available for Season of KDE ***

Brief explanation:

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

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

See relevant entries in KDE bugzilla about MacOSX support :

257679 257773

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

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

Mentor: Julien Narboux ? (Gilles Caulier)

Project: Video metadata support

*** Available for Season of KDE ***

Brief explanation:

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

To improve video file support, video metadata management done in background need to be improved, to patch Exiv2 shared library (already used by digiKam)

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, Andreas Huggel

Project: Clone Tool for Image Editor

*** Accepted for GSoC 2011 ***

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

Project: Panorama Tool

*** Accepted for GSoC 2011 ***

Brief explanation:

With recent digital still camera, it's possible using a tripod to take images to create panoramic view. We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user. Colors and luminosity of each shot must be adjusted automatically too.

See relevant entry in KDE bugzilla about it :

235766

Expected results: add a new tool (as kipi plugin) with auto-panorama feature.

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier

Project: Photo Frame Layouts

*** Available for Season of KDE ***

Brief explanation:

To add the possibility to easily combine photos in different frames to make a collage/composition: a set of different layouts, or even better to make them editable for users. An example from the internet just to see what I mean:

example of photo frame layout

Things that could be included: the background (color, gradient, a photo), the particular frame layout and maybe the possibility to add some text. Once the template is finished, the only thing is to intuitively add photos to the frames (maybe with drag and drop?). Of course the photos don't have to completely fit in the frames, so they would be scaled to fit in one dimension and the final user would have to select the part of the other dimension to crop the photo in the frame, if necessary. This could be a very nice feature also for Gwenview.

Expected results: add a new tool for photo frame layout.

Knowledge Prerequisite: C++, Qt

Mentor: Somebody in the digiKam team or maybe also Gwenview team?

KDE Edu

Project: Marble: Render OpenStreetMap .osm files

*** Accepted for GSoC 2011 ***

Brief explanation: Marble has a framework in ongoing development which allows to display geographical data in a "GeoGraphicsView". The aim is to extend this framework so that small .osm files can be displayed using this framework. The work builds also on top of a prior GSoC project about OSM annotation which was able to create a wireframe display of .osm files. The following steps would probably be part of the project:

Investigate the osm-annotate plugin, make it work again and clean it up so that it meets today's coding standards
Update the existing .osm parser code
Integrate the .osm parser with the current file loading (ideally as a plugin)
Extend the framework to handle proper styling of GeoGraphicsItems (so that outlined streets and colored areas are possible.
On top of that add a color style to the current osm view that turns the wireframe display of .osm files into a colorful one (with mapnik-like colors for streets and areas)
Handle text display in a basic way.

Expected results: Colorful mapnik-style rendering of .osm files. An improved GeoGraphicsView framework that can handle styling.

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: Marble goes Mobile, Part 2

*** Accepted for GSoC 2011 ***

Brief explanation: The "Marble To Go" project during GSoC 2010 has been a big success and these days there are packages of Marble 1.0 available for Maemo5/N900 already. This project would continue the work with a focus done on Marble's Mobile version. The target platform is MeeGo (on the N900 and other devices). The aim is to improve the mobile experience of Marble. Possible subjects include:

QML/Qt Components integration
User Interface improvements
Qt Mobility integration
Performance/Memory improvements
Features for mobile use cases (e.g. Geocaching).

Expected results: A better mobile experience of Marble (e.g. on the N900).

Mentor: Torsten Rahn <[email protected]>

Project: Marble: Natural Earth Vector Map

*** Available for Season of KDE ***

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.

Mentor: Torsten Rahn <[email protected]>

Project: KStars: Decouple computational code from the UI and Database

Brief explanation: KStars has its computational code tightly bound to the rest of the application. The aim of this project is to:

1. Investigate possible replacements for KStars' in-house computation, like libnova. It is important to keep KStars cross-platform. Hence we should look at cross-platform replacements.

2. Decouple KStars' interface and database from its computational code

3. Create a KStars computational engine library which contains all the computational code

4. Write test cases to ensure that the computations are correct.

5. Get KStars to use this library

6. If time permits, write an interactive command-line client / python module / D-Bus interface to use this library.

This is a difficult project, and requires a good deal of patience and endurance ;-). Probably not everything on this is achievable within the time-span of a GSoC, but this is the ultimate goal of a project like this.

Currently, a lot of the computational code is sprinkled across KSPlanetBase, SkyPoint and SkyObject. It would be easier if these were put into a library. I think parts 2 and 3 of the project could be split into stages like this:

1. Move all computational code from SkyPoint and SkyObject into a bunch of classes. Get these object classes to use the new class for all computations. These computational classes should have access to a copy of KSNumbers, KStarsDateTime, GeoLocation and other paraphernalia.

2. The Sun and moon are rather important for a lot of calculations. Create a separate class to answer computational questions about the sun. Replace the current use of KSSun / KSMoon to perform computations in a lot of places in the code by references code that uses this class.

3. More changes [to be worked out later]

Expected results: Clean, restructured code for KStars, which now uses a library that can be re-used in user-written scripts etc.

Mentor: Akarsh Simha <[email protected]>, Victor Carbune <[email protected]>

Project: KStars: Improve the observation planner and logging feature

*** Available for Season of KDE ***

Brief explanation: KStars already has an observation observation planner and logging feature. It requires a lot of tiny and not-so-tiny improvements though. Here's a list of some of the improvements we'd like to see. Not all might be implementable in a single GSoC, so pick and choose! :D

1. "Smart" assignment of observation times to objects (accounting for time taken to observe each object) -- currently, the observation planner can make a timeline of objects to observe during an observing session (Fire up KStars, hit Ctrl + L). However, this is done by just stamping the time of meridian transit. That may not be reasonable in a real observing session, because it takes some time to view each object. A possibly smart way of assigning times would be to account for the time taken to view each object and then assign times by sorting the objects by RA first and then by abs(declination).

2. A time-line view for your observation session plan, on which you can drag objects around to set observing times -- it would be great to have a time-line on which each object to observe is a slider. The time of observation of the object should be changeable in discrete units by moving the slider. The other objects' times should "re-adjust" to accommodate the change.

3. Ensure compatibility with OAL 2.0 XML schema is perfect -- We use the OAL 2.0 XML schema, which is gaining on as a standard format for observation log and observing list exchange. However, OAL compliance is not 100% and needs to be polished and tested.

4. Currently, OAL parsing code is tightly tied to the rest of KStars -- separate it out into a Qt-based OAL library

5. Clean up the Observation Planner interface

6. Clean up the Execute Session interface. Fix bugs.

7. Bring the time-line view of a session into the Execute Session interface

8. Add the ability to export OAL-compliant target lists (removing the 'scheduled time of observation' field, which is not compliant with OAL 2.0)

9. Add the ability to read and edit OAL-compliant observation logs within KStars

10. Add the ability to publish observation logs on a server.

Expected results: A better observation planning and logging feature for KStars.

Knowledge Prerequisite: C++ and Qt; XML parsing, in particular with Qt; be comfortable with desiging UIs using Qt

Mentor: Akarsh Simha <[email protected]>, Victor Carbune <[email protected]>

Project: KStars: Printing support

*** Accepted for GSoC 2011 ***

Brief explanation: KStars can currently print rendered images of the sky. But they are not well-annotated.

The aim of this project is to write code that will print star charts from KStars with explanations and annotation, and also print observing lists.

Here is our idea of the project. Feel free to come up with different feature ideas and different implementation ideas. Creativity is highly encouraged.

The project essentially aims to:

1. Create printed finder charts with Annotations, Multiple Fields-of-View, Legend etc.

Here's an idea of what features we'd like to see in a chart:

Here's an idea of what we mean by "multiple Fields-of-View": http://deepsky.astronomie.info/And/g1/index.en.php

The idea is to produce charts for three different "zoom" levels around the same point in the sky. Or even better, improvize and use the star hopper code (See tools/starhopper.h) to find out the coarse, binocular and fine fields of view.

2. Create printed observation logger forms with slots for writing down details and a representation of the FOV

Like this one: http://faintfuzzies.ca/v/hobbies/astro/KSTARS_OBSERVATION_FIELD_NOTES.PNG.html

3. If time permits, use an OCR library to permit conversion of printed forms into OAL-compliant reports to the best extent possible.

Creating a legend should not be very hard. Look at SkyMapDrawAbstract::exportSkyImage(). This draws a sky image on a QPaintDevice. One way to add details would be to use a QPixmap or whatever is appropriate as the QPaintDevice and then embed that in a larger QPaintDevice with the legend, title etc, and then add annotations.

Creating multiple FOVs could be a challenge. Look at the relevant parts of the code (SkyMapDrawAbstract::exportSkyImage(), SkyMapComposite::draw() etc). We encourage clean solutions to this in the proposal.

Also look at the Star hopper feature which can be accessed by right clicking on the SkyMap. Watch the console for debug output since this feature is still very experimental.

Expected results: Beautiful printed finder charts with multiple "zoom levels", printed observation log forms, and possibly digitized observation log reports using OAL XML schema

Knowledge Prerequisite: C++, ability to quickly learn Qt / KDE Printing libraries, QPainter API

Mentor: Victor Carbune <[email protected]>, Akarsh Simha <[email protected]>

Project: KStars: Make KStars more usable to the scientifically-inclined user

*** Accepted for Season of KDE ***

Brief explanation: KStars is currently good for education and for the hobby sky-observer. For those interested in more scientific aspects of astronomy, KStars does not have features to offer, but definitely does have the right existing framework to support these. The aim of this project is to write those lacking features, such as:

1. Plate solving and mapping of images: Look up astrometry.net. They have a library that can identify and produce the celestial coordinates of all objects in any given photograph of the sky. Use KStars to provide an interface to astrometry.net, and display plate-solved images on the sky-map. Use texture mapping to do this in OpenGL mode.

2. Retrieving scientific data: Make retrieval and visualization of data such as spectra of stars, variable star light curves etc. easy through KStars, via some simple GUI tools that initiate queries on various websites.

3. Astronomy updates: Monitor websites for updates such as comet, asteroid and supernova discoveries and alert the user about such events. (Maybe) keep updated catalogs of currently observable comets, asteroids and supernovae.

Expected results: KStars is more usable for the scientifically inclined user.

Knowledge Prerequisite: C++, Qt, Ability to quickly learn KDE's HTTP API, UI design with Qt

Mentor: Akarsh Simha <[email protected]>, Victor Carbune <[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.

C++0x Support:

*** Accepted for GSoC 2011 ***

Brief explanation: Extend the C++ plugin to support C++0x features

Expected results: All new features that will definitely get into C++0x are supported in the parser. Correct DUChain integration is added and code completion works as expected.

Knowledge Prerequisite: C++, Qt, KDevplatform

Mentor: David Nolden

Test Framework:

*** Available for Season of KDE ***

Brief explanation: Revive the test framework and make it useable

Expected results: Integrated running of CTest suites with all the features one would expect from an IDE. Create a wizard to add new tests, with CMake integratoin and support for QTestLib for starters. Should be extensible in future.

Knowledge Prerequisite: C++, Qt, KDE, CMake, KDevplatform

Mentor: Aleix Pol

KDevelop4 VCS integration

*** Available for Season of KDE ***

Brief explanation: Enhanced VCS integration

Expected results: It would be interesting a project regarding improving VCS integration in KDevelop by improving/providing new visualizations and UI so that the user has a better control on the system.

Knowledge Prerequisite: C++, VCS systems, Qt, KDE, KDevplatform

Mentor: Aleix Pol

Improved PHP Support:

*** Available for Season of KDE ***

Brief explanation: Polish XDebug and it's dependencies, improve PHP language support plugin.

Expected results: Make the XDebug plugin work and bring it and its dependenciees into a releasable state. Improve PHP language support plugin by fixing the Namespace support, adding basic code completion for array keys, and hopefully other things.

Knowledge Prerequisite: C++, Qt, KDE, PHP, XDebug, KDevplatform

Mentor: Milian Wolff

KDE Core

KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.

Project: Support for astronomical calendar systems

*** Accepted for GSoC 2011 ***

Brief explanation: Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.

Expected results: Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.

Knowledge Prerequisite: C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.

Mentor: John Layt, irc: jlayt, email: john at layt dot net

Project: Improvements in KIO File Transfer

*** Accepted for GSoC 2011 ***

Brief explanation: Transferring files in KIO currently has three significant limitations. First, it scans every directory before transferring any files, which is slow for large numbers of files and directories. This process also tends to hang for very large numbers of files. Second, it stops on all errors, which means the user has to monitor the transfer. It also provides no report on the errors at the end or any way to go back and check those files. Finally, transfers happen in parallel, which can lead to excessive disk I/O activity or network traffic, slowing down all the transfers. The purpose of this project would be to fix these problems.

Expected results: Directory scanning and the actual file transfer should happen in parallel. Errors should be handled in a more appropriate manner, with the response depending on the error in question. The exact response to each error should be worked out with the mentor. A report on all errors should be available at the end of a transfer. Finally, there should be some method to merge multiple transfers, perhaps on a per-filesystem basis.

Knowledge Prerequisite: C++

Mentor: David Faure

Project: Integrate OpenPrinting Common Print Dialog into KDE

*** Available for Season of KDE ***

Brief explanation: The Common Print Dialog is an initiative by the OpenPrinting workgroup of the Linux Foundation to build a common fully featured print dialog for the Linux ecosystem. KDE is currently working with OpenPrinting to complete the dialog in a manner suitable for use in KDE and Qt. OpenPrinting is able to offer a number of GSoC slots for working on completing the dialog itself, integrating the dialog into key KDE applications, and integrating the KDE Color Management system into the dialog.

Please see the OpenPrinting GSoC page for more details on these tasks.

Mentor OpenPrinting mentors, with KDE co-ordination by John Layt

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

*** Available for Season of KDE ***

Brief explanation: Social networks are quite popular with many people, therefore KDEPIM should be able to extract data from the social networking sites. One example is the facebook resource, which makes friends and events available in KDEPIM. A vast amount of other social networks exist, many of them, like LinkedIn, StudiVZ and MySpace, use the OpenSocial API to provide access to their data. The goal of this project is to implement an Akonadi resource for OpenSocial networks.

Expected results: A working OpenSocial Akonadi resource that supports at least contacts and messages.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: Improved HTML support in KMail

*** Accepted for GSoC 2011 ***

Brief explanation: HTML mails are used more and more frequently, it is therefore important that KMail has good HTML support. Sorely missing at the moment is the ability to preserve HTML formatting while replying to a mail, which would be one of the main goals of the project. Apart from that, the existing HTML support should be polished.

Expected results: The ability to reply and forward HTML mails and keep the formatting.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor: Thomas McGuire

Project: Improved key management in Kontact

*** Available for Season of KDE ***

See http://ungethym.blogspot.com/2011/02/gsoc-idea-2-improved-more-elegant.html.

Project: VOIP Plugin for Kontact

*** Available for Season of KDE ***

Brief explanation: VOIP installations are used in many places, and need to be managed. One popular VOIP framework is Asterisk. The goal of this project is to provide a Kontact plugin or a standalone application that can manage as many aspects of Asterisk as possible.

Expected results: A VOIP plugin for Kontact

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: KWallet Improvments

*** Available for Season of KDE ***

Brief explanation: The wallet is used in many places in KDEPIM, for example when checking and sending email. Some users disable the wallet, which means in all places there is an implementation of an alternative password dialog. This should be merged with the KWallet API, so that it is possible to always use the same API. Additionally, this project should add a pinentry implementation that uses KWallet. Pinentry is the password dialog program that is used when doing crypto operations in KMail.

Expected results: A unified KWallet API and a pinentry implementation that uses KWallet

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: Communication central plugin for Kontact

*** Available for Season of KDE ***

Brief explanation: There is already a vast information for each contact available in KDE: The addressbook entries, chat logs, tweets, e-mails, Facebook messages and so on. The goal of this project is to create a person-centric view that shows all this information about a person, with a nice way to search and examine the data. It should also be possible to initiate communication with that person in this view.

Expected results: A Kontact plugin that shows all available information about a person and provides communication abilities.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: Metacontacts support in Akonadi

*** Available for Season of KDE ***

Brief explanation: With Akonadi, contacts come from many different sources, for example from your personal contacts resource, from the facebook resource or from the KDE accounts resource. Often, the same person is present in multiple resources, causing duplicates in KAddressbook. The goal of this project is to automatically merge contacts from multiple sources into a metacontact that aggregates all information. A possible implementation concept has been covered during the last PIM meeting.

Expected results: Working Metacontact support in Akonadi

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: Mobile phone syncing

*** Accepted for GSoC 2011 ***

Brief explanation: There are multiple way to sync a mobile phone with a computer, for example SyncML, OpenSync or ActiveSync. The first two already have a first implementation, but are still work in progress. Make one of the solutions fully work.

Expected results: A full solution for syncing mobile phones with Akonadi, which should include a GUI that is easy to use.

Knowledge Prerequisite: C++ and Qt should be known already.

Mentor: Dinesh

Project: OpenChange resource

*** Available for Season of KDE ***

Brief explanation: Exchange is an important groupware server used in many businesses, support for the protocol would make KDEPIM much more attractive. Open source client libraries for Exchange are already available from the OpenChange project, and a prototype OpenChange resource for Akonadi is also available. The goal of this project is to complete the OpenChange resource.

Expected results: A working OpenChange Akonadi resource that supports mails, contacts, events, free/busy support and sending emails.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor: Brad Hards (or others)

Project: PST resource

*** Available for Season of KDE ***

Brief explanation: When migrating away from Microsoft Windows, mail users often have large "archive" folders in PST (Personal Storage Table) format. It would be useful if these could be accessed through Akonadi. There are a couple of libraries available that could support this type of resource.

Expected results: A working PST Akonadi resource that supports mails, contacts, events, free/busy support and sending emails.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor: Brad Hards (or others)

Project: Improved support for Google services

*** Available for Season of KDE ***

Brief explanation: Google provides popular services for mails, contacts and calendars. Those are already supported in KDEPIM, mails are supported with the IMAP resource and there are also resources for contacts and calendars. Yet, these solutions are not fully polished yet, many problems for all three are reported. The goal of this project is to bring support to a prime level that works for users out of the box. Among others, it means supporting Google Mail labels as tags in Akonadi/Nepomuk.

Expected results: Flawless support for Google Mail IMAP and a google data resource that fully works without bugs.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor:

Project: User Interface improvements in KMail

*** Available for Season of KDE ***

Brief explanation: While KMail is powerful, the user interface can be improved in many places to make it easier to use and look more appealing. One of the goals is adding tab support for the preview pane. Apart from that, the student should suggest other UI improvements, for example by taking ideas form the bug tracker or from other mail clients. These UI improvements should not be adding new features, but making the existing UI better.

Expected results: A tabbed message preview pane and various other UI improvements.

Knowledge Prerequisite: C++ and Qt should be known already

Mentor: Thomas McGuire

Project: Conversation view in KMail

*** Available for Season of KDE ***

Brief explanation: The preview pane in KMail should optionally be able to show all messages of a thread at once, which is also known as "conversation view" and popular from the Google Mail web interface. The message list probably needs a special mode that makes it more suitable for using conversation views.

Expected results: A smooth conversation view mode that not only adapts the looks of the preview pane and the message list, but also delivers a good interaction workflow. There needs to be some thought on UI and interaction design behind this to create great usability.

Knowledge Prerequisite: C++ required, Qt recommended

Mentor: Thomas McGuire

Project: Improve support for alternative Calendar Systems in Kontact

*** Available for Season of KDE ***

Brief explanation: KDE is unique in the Linux eco-system in providing support for alternative calendar systems such as Hebrew and Islamic calendars. However, Kontact and all the open standards for PIM only support the Gregorian calendar system. This project would explore ways of supporting alternative calendar systems in Kontact and in the wider open PIM standards world.

Expected results: To research, design and implement support for the following:

recurring calendar events using alternative calendar systems
birthdays and anniversaries using alternative calendar systems
display of an alternative calendar system in the calendar views

Knowledge Prerequisite: Some C++ and Qt recommended. Some knowledge of the cultural use of alternative calendar systems. Strong research and design skills, getting the iCalendar and vCard storage and interoperability definitions correct is the most important part of the project.

Mentor: John Layt

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 modify the path a tool that, 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: Modify path tool is able to scale 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.

Technologies Used: C++,Qt,SVG?

Mentor: Jan H? jaham @t gmx,net (need to ask :P )

Calligra Kexi

Kexi is an open source data management application, long-awaited competitor for programs like MS Access or Filemaker.

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

Project Page: http://kexi-project.org/

Irc channel: #kexi on irc.freenode.net

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

Development Wiki: http://community.kde.org/Kexi

Project: Add Maps Support to Kexi

Brief explanation: Implement maps support for Kexi Forms, for Kexi Reports and for Calligra documents

Propose, design and implement maps support for Kexi Forms (map widget) as explained at [1]
Reusing the work for Kexi Forms, propose, design and implement maps support for Kexi Reports
Based on the work for Kexi Forms and Reports, propose, design and implement maps support for Calligra documents, by providing Flake shape plugin
All plugins have to reuse Marble libraries
Maps for forms and reports should not use Flake technology
Proposals supporting vector graphics for printouts (Reports and for Flake) can be a plus, since it means higher quality
Proposals for using different resources for maps (i.e. in addition to what Marble provides) can be a plus; e.g. online services can be used (if legal) or third party offline map resources can be reused

Used Technologies: C++, Qt, Marble libraries, plus possible web services to accessing maps

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

Project: Add Web pages elements to Kexi

Brief explanation: Implement web pages element for Kexi Forms, for Kexi Reports and for Calligra documents

Propose, design and implement web page support for Kexi Forms (web view widget) as explained at [2]
Reusing the work for Kexi Forms, propose, design and implement web pages support for Kexi Reports (e.g. printing snapshots of web pages)
Based on the work for Kexi Forms and Reports, propose, design and implement web pages support for Calligra documents, by providing Flake shape plugin, so web page snapshots can be rendered dynamically within documents
All plugins can reuse QWebView or QGraphicsWebView technologies or equivalent
Implementations for forms and reports should not use Flake technology

Used Technologies: C++, Qt, Web View (Qt or Qt GraphicsView)

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

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 [3] 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 Words

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

Project: Improve quality of ODF write support

Brief explanation: While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.

Used Technologies: C++, Qt

Mentor: Sebastian Sauer, please contact [email protected]

Project: Implement notes-support

Brief explanation: Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.

integrate into textshape so not only Calligra Words can profit (reuse the notes functionality).
display notes in Calligra Words on the left/right side of the page-textshape.
inline-editing (using a textshape).
anchor to character/word(/paragraph/image/...)
see ODF 1.2 specs "6.3.2 <text:note>" and "6.3.3 <text:note-citation>" and "6.3.4 <text:note-body>" and "7.7.7 <text:note-ref>" and "16.29.3 <text:notes-configuration>"
comment-text, author, date/time
see also the bugs 260138 and 260184 and 260102 and 260127 and "Post-it" area + notes as a GSOC?.

Used Technologies: C++, Qt

Mentor: Sebastian Sauer, please contact [email protected]

Project: Fix and extend LaTEX support

Brief explanation: Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.

Project: PDF-Import and/or PDF-Export

Brief explanation: Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.

Used Technologies: C++, Qt

Mentor: Sebastian Sauer, please contact [email protected]

Project: Integrate with Akonadi

Brief explanation: Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).

Project: References tool

Brief explanation: Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )

Used Technologies: C++, Qt

Mentor: C. Boemann, please contact [email protected]

Project: Layout tool

Brief explanation: Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.

As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.

Used Technologies: C++, Qt

Mentor: C. Boemann, please contact [email protected]

Calligra Krita

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

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

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

Irc channel: #krita on irc.freenode.net

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

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

Project: ABR Brush Support

Brief Explanation: Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.

Mentor: Lukáš Tvrdý

Used technologies: C++, Qt

Resource: http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita

Project: PSD File import/export Support

Brief Explanation: The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt,

Resources: existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd

Project: Flow and drying: real media support

Brief Explanation: As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt

Resources: http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven

Project: 3D Sketching tool

Brief Explanation: When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup

Mentor: Lukáš Tvrdý or Cyrille Berger

Used technologies: C++, Qt,

Project: Text Balloon support for Comics work

Brief Explanation: Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt, SVG

Expected results: a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.

Resources: http://en.wikipedia.org/wiki/Speech_balloon

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: Advanced selection using SIOX

Brief explanation: SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.

Possible mentor: Cyrille Berger (or Sven Langkamp)

Used Technologies: C++, Qt

Resources:

http://www.siox.org/ website describing the algorithm,
https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,
http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,
http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction

Project: Tagging and management for Krita resources

Brief explanation: Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.

Expected results: A functioning implementation of resource management and tagging.

Used Technologies: C++, Qt, digital art.

Mentor: Boudewijn Rempt

Project: GPU-acceleration for Krita

Brief explanation: Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming. Expected results: optimized composition operators, transformation code Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding

Mentor: Lukáš Tvrdý

Project: GPU-backend for OpenGTL

Brief explanation: Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements. There are two possibilities to implement such a change:

Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend
The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library

The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.

This is a very challenging task!

Resources: http://www.opengtl.org

Expected results: OpenCL AST generator, report on the possibility to interface OpenGTL with mesa

Used Technologies: C++, GLSL, OpenCL (possibly LLVM)

Mentor: Cyrille Berger

Project: Substrate simulation

Brief explanation: Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings. Expected results: an optional substrate simulation that works with all current Krita tools

Used Technologies: C++, Qt, OpenGL

Mentor: Boudewijn Rempt

Project: Color Mixing

Brief explanation: Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.

Expected results: a color mixer that works, layer composition and painting.

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

Mentor: Boudewijn Rempt

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: Shift drag sensors

Brief explanation: Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.

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

Mentor: Boudewijn Rempt

Project: Tools to manipulate Krita files (.kra)

Brief explanation: The Krita file format is quite simple: a zip container with XML describing the image and easily parsable binary data for the layers. This project entails creating commandline tools to change colorspace and channel depth of krita files, split out krita files into the component layers, apply icc profiles, transpose layers, and compose files from other krita files and more.

Used Technologies: C++, Qt

Mentor: Boudewijn Rempt

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: Plasma-based Presentation View

Brief explanation: The presentation view in presentation applications is used in multi-monitor displays to display information about the presentation on one screen while the full slides appear on another screen. This provides information to the presenter that is not visible to the audience. This information often includes a preview of the current and next slide, timing information, notes, and a list of slides for navigation.

Stage already has a basic presentation view, but it is fairly limited in its capabilities and rigid in its layout. This project would be to design a new presentation view for Stage using plasma, ideally using QML-based plasma widgets. It would involve developing a plasma containment for the presentation view and plasma widgets for the individual elements needed by the view, as well as an interface for setting up the view. These elements would, at a minimum, include: a preview of the current slide, a preview of the next slide, a list of slides, notes for the current slide, next and previous slide buttons, and a timer. Users would need to be able to place, position, and resize the elements. The presentation view would also need to support multiple different views that could be easily switched between during a presentation.

Used Technologies: C++, Qt, QML, Plasma

Mentor: see mailing list: https://mail.kde.org/mailman/listinfo/calligra-devel

Project: Single-canvas Presentation Mode (like Prezi or Zippl)

Brief explanation: Unlike normal slide-based presentation tools, single-canvas presentation tools have a single infinite canvas. Parts of that canvas are set of as frames, and the presentation progresses by moving from one of these frames to another in a pre-defined or arbitrary manner. Alternate routes between frame scan be defined, as well as branch points where the presenter can select between multiple different ways to proceed from a given frame. This allows for a non-linear presentation.

This project would involve implementing a single-canvas presentation mode in Stage. Users would need to be able to set up a canvas, set aside parts of that canvas as frames of arbitrary size, set paths between those frames (including a default path and alternate paths selected by clicking on elements in the presentation), zoom out to view the entire canvas, and zoom in on arbitrary parts of the canvas.

See here for examples of other implementations:
http://lizards.opensuse.org/2010/06/11/zippl-a-lightweigth-presentation-tool/
http://prezi.com/

Used Technologies: C++, Qt

Mentor: see mailing list: https://mail.kde.org/mailman/listinfo/calligra-devel

Project: Unified Slide Manager

Brief explanation: Stage currently has three different, independent tools for managing slides: the Document Panel, the Slide Sorter, and the Custom Slideshow Editor. These use completely different interfaces and have different capabilities (for instance only the Slide Sorter has drag-and-drop). However, they are all used to manage slides in your presentation.

This project would be to combine them into a single interface. The interface would normally reside in a docable panel similar to the existing Document panel. By pressing a button, it will expand to take up most of the window, behaving as the Slide Sorter. In this mode, there should be an additional, normally hidden panel at the bottom that the user can use to create add and remove slides from custom slideshows.

In the process, the existing Document Panel and Slide Sorter should be modified to take better advantage of features provided by KDE and to provide better consistency with other KDE programs. Changes would likely include: overlay buttons when you hover on a slide, drag-and-drop interfaces, menus on drag-and-drop, and selection effects similar to those seen in KDE-based file managers.

See here for descriptions and mock-ups:
https://bugs.kde.org/show_bug.cgi?id=254685
https://bugs.kde.org/show_bug.cgi?id=254687
https://bugs.kde.org/show_bug.cgi?id=254696
https://bugs.kde.org/show_bug.cgi?id=254705

Used Technologies: C++, Qt

Mentor: see mailing list: https://mail.kde.org/mailman/listinfo/calligra-devel

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

Used Technologies: C++, Qt

Mentor: Thorsten Zachmann

KWin

KDE's window manager

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

Project: Modularization of Workspace

Brief explanation: The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.

Expected results: A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.

Knowledge Prerequisite: Qt/C++ and general understanding of window management. Plus for X11 knowledge

Mentor: Martin Gräßlin (mgraesslin)

Project: Unit Testing Framework

Brief explanation: Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.

Expected results: An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented

Knowledge Prerequisite: Qt/C++, JavaScript, QTest

Mentor: Martin Gräßlin (mgraesslin)

Project: Initial Support for Wayland Clients

Brief explanation: Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.

Expected results: KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).

Knowledge Prerequisite: Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge

Mentor: Martin Gräßlin (mgraesslin)

Nepomuk

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

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

Project: A "real" query parser and Query Builder Widget

Brief explanation: Nepomuk has a query parser which is used to handle input from the user in such situations as the KRunner interface or the Dolphin search bar. Currently this parser is one big HACK and in dire need of reimplementation.

In addition we have no dedicated widget for query input which provides good auto-completion. The idea is fancy auto-completion in the search line-edit that proposes types, properties, and other resources. It should take usage frequency of properties, types, and property values into account (when that does not mean too big a performance downer). It could even try to use some built-in thesaurus allowing to match "nfo:Audio" from "audio", "music", "song", and others.

Expected results: A desktop query parser which is based on an actual grammar including support for nested terms (important when it comes to querying a graph), quotes (used to group keywords into one search term), resource URIs (it should be able to detect that a string is a resource URI and not a full text search term), namespace abbreviations ("nao:hasTag" should match exactly the one property while "hastag" can match multiple properties), as well as property and type expansion (this means that in "hastag:xyz" "hastag" should be expanded to an actual property URI.)

The query parser should support the syntax supported by the current query parser and build upon that. One could think of extensions like mapping localized terms like "today" or "yesterday" to QDate or QDateTime values (depending on the range of the queried property), excluding unused properties altogether, supporting a deeper nesting of query terms like "author:(related:(hastag:nepomuk))", and so on.

This parser should be used to implement auto-completion in a line-edit. Ideally this auto-completion would work well (only propose used properties, give preference to type, and so on) and look good (give multiple propositions in one widget, maybe with a result count). Examples include a simple expansion of "hastag:" to existing tags (sorted by use and not the complete list) or an expansion of "music" to "Query all music files" (ie. giving an explanation of query terms in the completion widget.

Knowledge Prerequisite: Previous experience with a parser generator would be good but is not required. A bit of Qt experience would be nice but again, is not required.

Mentor: Sebastian Trueg <[email protected]>

Project: Project Integration

Brief explanation: One lands up working on various different projects. It would be beneficial if Nepomuk could keep track of Projects. This would include remembering which files were involved, the people involved, TODO lists, etc. One of the most important aspects would be a form of browser integration, as research for a project is primarily done through a browser. There should be ways to annotate web pages, bookmarks, and even selected parts of a web page.

A simple use case for a web-scrapping project in Python -

Create a project by the name of web-scrapper.
Create its git repository. Nepomuk should understand that this is a coding project and here is where the source code would be. Maybe it can even store the source code management software's name.
Read up about Python web-scrapping and bookmark some pages. These pages are given tags like "Python, Web-Scrapping, Manual, Talks" and are associated with the project.
Download and watch one talk related to Python. Again Nepomuk should link the video file with the project.
Add TODOs and other stuff for the project.
Maybe this project is being done with someone. The project should be linked to that person.

Expected results: A backend for project management, and a nice GUI to manage them.

Knowledge Prerequisite: Qt and KDE development experience. Some knowledge about RDF and NRL would be nice.

Mentor: Vishesh Handa or Sebastian Trueg

Project: Fancy Bookmarking

Brief explanation: Classical bookmarking means to simply put a link with a name into a hierarchy of links with names. The idea is to bookmark web pages by linking them to projects, tasks, persons, files, by tagging them, by commenting on them, and so on.

Expected results: The result is two-fold:

A simple way to annotate web pages in Konqueror or rekonq, to tag them, to relate them to resources and so on. This could be realized with a side panel, a popup menu, toolbar buttons, hotkeys, whatever.
A way to open web pages by finding them through the annotations. A side panel seems a good first approach but there might be better ways. The side panel could provide two ways to find pages: 1. a simple search and 2. a display of pages related to the currently browsed page. The latter could be based on existing relations but also a keyword search of the current page using Scribo.

Knowledge Prerequisite: Qt and KDE development experience.

Mentor: Sebastian Trueg or Vishesh Handa

Project: Real Digikam Integration

Brief explanation: Currently Digikam uses its own database to store image metadata, ratings, and their own brand of tags. In addition it comes with a Nepomuk service that syncs some of the information with Nepomuk. The idea is to take full advantage of Nepomuk, store all information in Nepomuk, and implement additional fancy features on top of it.

Expected results: The result of the project should be two-fold: 1. a replacement for the current Digikam database with Nepomuk, 2. additional features based on Nepomuk. The latter includes listing of all photos from Nepomuk instead of the configured folders (or a combination), photo album creation through Nepomuk resources instead of folders (Each Album is a resource in Nepomuk with links to the photos in it - this allows for one photo to be in several albums without physical copies or symlinks), commenting of albums, and listing of albums or photos by other criteria though Nepomuk queries.

Knowledge Prerequisite: KDE experience would be preferred.

Mentor: Sebastian Trueg and hopefully someone from Digikam

Project: Metadata Writeback

Brief explanation: Nepomuk allows to store all kinds of metadata for files. Some of this metadata like id3 tags of mp3 files could be written back to the files. See also the corresponding wish item.

Expected results: A service or an extension of the Data management service that allows to write back certain information to the files. This writeback should be triggered by the metadata change in Nepomuk. It would be nice to have a plugin system that allows to add new formats for writeback easily.

Knowledge Prerequisite: C++, basic Qt or KDE is always nice but not necessary.

Mentor: Sebastian Trueg

Plasma

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

Project: QML QtComponents set

Brief explanation: The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.

Expected results: A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)

Knowledge Prerequisite: both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way

Mentor: either Marco Martin and/or Artur De Souza

Project: Educational desktop

Brief explanation: The flexibility of the Plasma Desktop shell can bring desktops fine tuned to a particular use case: With the KDE edu project, KDE has a strong offering of educational software. To further leverage the stength of the KDE platform, a customized Plasma desktop for the educational environment can make KDE the obvious choice.

Expected results: A set of plasmoids and a custom plasma layout (with eventual modifications to the desktop shell itself) to do a strong customization. In designing those plasmoids, the mobile use case has to be taken into account as well.

Knowledge Prerequisite: Qt/C++, probably QML

Mentor:

Project: Plasma media center first release

Brief explanation: The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml

Expected results: a basically working media center at least with an index of local media files (videos, pictures and music)

Knowledge Prerequisite: Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way

Mentor: Marco Martin

Project: QML-ify Plasma widgets

Brief explanation: The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether. All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.

Expected results: At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)

Knowledge Prerequisite: Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps

Mentor: Marco MArtin

Project: Move Plasma Functionality in Compositor

Brief explanation: Plasma uses lots of functionality which are better served in the window and compositing manager (KWin). For example Plasma uses an own glow animation before showing a hidden panel. This could be OpenGL accelerated when moved into KWin. Other examples involve Wallpaper rendering or Tooltips.

It would be the task of the project to identify these areas and to discuss strategies with the Plasma and KWin community how to better handle these areas and to implement the solution.

Expected results: Rendering functionality moved from Plasma to KWin with fallback for legacy (non-composited) and other window managers.

Knowledge Prerequisite: C++/Qt, basic understanding of X, OpenGL useful but not required.

Mentor:

Project: Helping in libplasma2 development

Brief explanation: There are several things that needs to be done in both designing and preparing libplasma for the next major redesign.

Expected results: A thing can be building a working branch on git that doesn't have any derecated class of functions and is completely without widgets (so will be unable to load classic c++ plasmoids) but that can still load qml based ones.

Knowledge Prerequisite: C++/Qt

Mentor:

Project: Plasma mobile components

Brief explanation: Develop (and polish the ones already started) components for a classic mobile ui, such as application laucher grid, plasmoids container, notifications and systemtray plasmoid and so on.

Expected results: A quite classic mobile shell at a near production quality, while alternate containments and plasmoids will make posible to experiment new and more radical user interfaces.

Knowledge Prerequisite: C++/Qt, QML

Mentor: Marco Martin

Project: Integration of home automation system in desktop

Brief explanation: Home automation services need and can be very powerfull with an integration in desktop, this project aim to provide UIs and configuration tools for an home automation server like Domogik¹ with the help of Plasma technologies. This project need to identify and discuss how to implement these concept and do links with Plasma Media Center or others part of desktop.

Expected results: A set of plasmoid dedicated to supervision and contorl of a house, a way to ajust advanced parameters (perhaps with an abstraction layer for help future implementation of other automation server).

Knowledge Prerequisite: ... & basics skills in home automation

Mentor: Marco Martin or Aaron Seigo

Project: Spread activities to applications

Brief explanation: Activities are growing up to bi much more than different 'desktops'. Programs (from KDE and 3rd party) should start talking with the activities service to provide the info about the documents (and web pages, filesystem locations, etc.) they access, modify.

Expected results: Patch all main KDE apps to do the above (including KRunner and similar). Modify Places, Bookmarks models to show different stuff when in different activities. Provide a KIO for browsing files per activity and date/time, and a runner which will favour apps/documents with high rating calculated from the usage stats.

Knowledge Prerequisite: C++, Qt. Nepomuk and Zeitgeist a plus.

Mentor: Ivan Čukić

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: QML/QGraphicsScene Video Painting

Brief explanation: QML is the new declarative user interface description language for Qt. Unlike the traditional widget based design approach it works on an underlying graphics scene requiring painting within that scene. Phonon however depends on the presence of a widget to do video painting. An alternative painting architecture needs to be introduced to permit tight integration with QML and QGraphicsScene based applications such as Plasma. Ideally using different approaches (e.g. paintaing using OpenGL shaders and surface painting using QImage/QPainter).

Expected results: Phonon gains a VideoGraphicsItem for use in QGraphicsScenes (plus for actual QML package)

Knowledge Prerequisite: Qt/C++, plus for QML, OpenGL, GStreamer and libvlc.

Mentor: TBA

Project: Encoding

Brief explanation: Phonon currently has the capability to easily read any audio or video format known to the backend. This results is a very large number of supported formats. Many of the decoders in the backends also have a corresponding encoder. Phonon also recently acquired the ability to record from audio/video devices. It then makes sense that someone would want to use Phonon not only as a playback framework, but as a recording framework. A use case for this would be writing a simple application to use Phonon for recording a video from a webcam and microphone and immediately writing a .ogg file for later upload to a website such as Youtube. Alternatively, the encoded .ogg data can be sent to libshout and on to an icecast server for internet radio.

Expected results: Phonon gains a new kind of MediaNode that accepts media data as input and generates an encoded stream available as a QIODevice. Essentially, the inverse operation of an AbstractMediaStream.

Knowledge Prerequisite: Qt/C++, plus for GStreamer and libvlc.

Mentor: TBA

Project: Multi-Channel Audio KCM Module

*** Available for Season of KDE ***

Brief explanation: With the increasing availability of multi-channel sound cards (more than 2 channels) and the popularity of surround-sound movies, having a tool to properly configure and calibrate surround-sound speakers is essential. However, Linux in general lacks a good surround-sound configuration GUI. This project would be to implement such a GUI in KDE, at the very least supporting pulseaudio but optionally supporting ALSA or other audio frameworks as well. It would be part of the multimedia KCM module.

The tool would include two components. First would be a multi-channel calibration tool, with test sounds and individual volume controls for each channel in the same interface. Once the channels have been calibrated, the ranges for the kmix volume sliders for the channels would be automatically re-scaled to hide these changes in the normal kmix interface. KDE already has a KCM module for testing surround-sound speakers, but this tool doesn't allow you to configure the channels. It also lacks features found in other such tools, like being able to play sounds from all speakers in sequence.

The second component would be a point-and-click interface for connecting software sound channels to physical sound card channels, as well as connecting sound card channels to other sound car channels or software channels to other software channels. This would be particularly useful for people with custom speaker set-ups or that are using multiple 2-channel sounds cards to implement surround sound. It would also be useful, for instance, for routing microphone devices directly to speakers, routing stereo sound to multiple speakers in a surround-sound setup, combining channels from multi-channel sound for stereo speakers, or routing sound from production software directly to recording software. There is currently no GUI for this in Linux at all that I am aware of, so this would be a big help.

Expected results: An interface for calibrating surround-sound speakers, and a tool for connecting audio channels to other audio channels.

References: See "Speaker Setup Now or Forever Hold Your Peace" for the work already done in this area

Knowledge Prerequisite: Qt/C++, plus for pulseaudio

Mentor: Colin Guthrie

Project: Cross-backend Equalizer support with PulseAudio

*** Available for Season of KDE ***

Brief explanation: The git master version of PulseAudio (to be released as 1.0) contains an "Equalizer" sink that acts as a filter on top of a hardware device. By extending how the existing PulseSupport class works in Phonon it should be possible to provide access to such equalization to any backend. At present, when PulseAudio is in use, Phonon will already bypass the backend when dealing with volume changes, utilising PulseAudio's per-stream volume controls. It is expected that presenting the equalizer sink would be done in a similar way.

Expected results: When present, equalization will be presented to the user via Phonon.

References: pulseaudio-equalizer qpaeq

Knowledge Prerequisite: Qt/C++, Knowledge of PulseAudio would be a plus. Knowledge of Asynchronous programming principles would also be desirable but not essential.

Mentor: Colin Guthrie

Project: Testing Framework

Brief explanation: Phonon has a very distributed project structure. Playback capability is actually provided by so-called backends which act as plugins to the Phonon library. Every supported multimedia framework has its own backend. This causes an interesting situation with regards to automated testing and quality assurance. While there is a set of unit tests in the Phonon library itself, they are incomplete and only test a fraction of the available capabilities. A new more scalable testing framework/setup is needed to ensure all backends act according to the expected behavior outlined by the Phonon library.

Expected results: A testing framework to quality assure backends.

Knowledge Prerequisite: C++, plus for Qt

Mentor: TBA

Kate

Kate is a powerful programmer's editor.

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

Project: Code Folding

Brief explanation: Kate supports code folding for multiple languages. The current implementation has the drawback that it is no longer maintained and that many bugs have accumulated over the last years. Goal of this project would be to inspect the current implementation and design a new one based on the knowledge gained from that. (or, if needed, reimplementation from scratch)

Expected results: A new well documented implementation of the code folding. Main design goals should be maintainability, performance and simplicity.

Knowledge Prerequisite: C++/Qt, high motivation

Mentor: Dominik Haumann / Christoph Cullmann

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

Brief explanation: Kate supports modelines, also called document variables. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.

Expected results: A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.

Knowledge Prerequisite: C++/Qt, Qt-Designer, high motivation

Mentor: Dominik Haumann / Christoph Cullmann

Project: Further improve the Vi Input Mode

Brief explanation: Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:

A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)
More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”
A thorough test suite
[your favourite feature]

Expected results: An improved vi input mode for kate

Knowledge Prerequisite: C++/Qt, high motivation

Mentor: Erlend Hamberg

Project: Elastic Tabstop support

Brief explanation: Elastic tabstops are a way to visually align code automatically. Current ways of indentation are a relic from the typewriter era and it is time to try new concepts. Elastic tabstops

Put an end to the “tabs vs spaces” debate
Save the programmer from tinkering with alignment
Allow the use of proportional fonts
Degrade gracefully for non-supporting editors

Apart from implementing the feature itself, one should care about the following:

the option “align dynamically wrapped lines to the indentation level” has to be extended to allow the setting “align dynamically wrapped lines to the last tabstop”
A way has to be found to integrate existing options such as tab width and indentation step width.

Expected results: A working option to use elastic tabstops instead of traditional alignment.

Knowledge Prerequisite: C++, Qt

Mentor: Joseph Wenninger

Rekonq

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

Project: Adblock improvements & elements manipulation

Brief explanation:

Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)

Expected results:

An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.

Knowledge Prerequisite:

C++ programming and hopefully Qt

Mentor: Andrea Diamantini

Project: Plasma KPart for Rekonq

Brief explanation:

Rekonq provides a specific webpage displayed when the user clicks on the "new tab" button. This webpage has features like: previews of favorite pages, previews of closed tabs, an history list, a bookmark list, and a download list. The goal of this project is develop the same features as this webpage but using plasmoids displayed in a Plasma KPart. Additional plasmoids, eg. RSS feeder, could be integrated.

Expected results:

Customizable new tab page.
Plasma theme integration
Same plasmoids inside Rekonq and on the desktop

Mentor: Lionel Chauvin

Project: Tab Grouping using sessions and Panorama-like view

Brief explanation:

When tabbed browsing was introduced, it was a revolution. Since then, people have evolved different patterns of using tabs. Many people use tabs to remember web pages that they want to check out later. Many people who work on 2-3 projects often need to group their tabs separately to avoid confusion. Many users have more than 30-40 tabs open at a time, and this proves to be a clutter with Rekonq's current tab browsing system. The "Tab grouping" to implement here aims to be merged with the "sessions" concept, being a "session" a particular window state (with a list of tabs opened). Users can organize and save the sessions trought a Firefox 4 panorama-like view and reload them independently

Expected results:

Improve the actual session manager (actually just used to restore tabs on crash or on startup) to support the session saving mechanism.
Implement a system to reload session at startup and at runtime. (kate-like?)
Panorama-like view to organize and save tabs groups (GraphicsWidget based?)
Add support for pinned tabs that are visible accross sessions.

Knowledge Prerequisite:

C++, Qt. Appreciated will be experience with the Qt Graphics View Framework and HTML/CSS/Javascript.

Mentor: Andrea Diamantini

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: Local sync client

Brief explanation: Build a client to sync your ownCloud files with your local disc to enable offline use.

Expected results: Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:

"The client should:

1. read a configuration file so see which folders to sync and which owncloud server to use.
2. mount the owncloud server via fuse or a different tool into a hidden directory.
3. call a syncing tool like csync to sync between the local directory and the mounted directory
4. unmount owncloud
5. write a log-file about the synced files and potential conflicts which the user has to solve.

The client should be as portable as possible of course."

Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.

Knowledge Prerequisite: Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.

Mentor: Kyle Cunningham? Robin Appleman? Frank K?

Project: PIM web interface

Brief explanation: Create a web interface for viewing and editing PIM data stored in ownCloud.

Expected results: Creation of a web interface that integrates in ownCloud, the interface should provide read/write access to calendar and contants that are stored on the ownCloud server (probably as vcard/ical files). It should provide a feature set as closely to desktop clients as possible.

Knowledge Prerequisite: PHP, HTML, CSS and javascript. Enthusiasm free software cloud solutions and trying new things.

Mentor: Kyle Cunningham? Robin Appleman? Frank K?

Project: Sharing

Brief explanation: Create a method of sharing files and other things with users on the same ownCloud server.

Expected results: Creation of a way for users to share their files with other users and provide a generic way for plugins to provide sharing of other things (eg. pim data). The file sharing part should at least provide a way to view and edit permissions of files and folders and a simple way to view things shared with you

Knowledge Prerequisite: PHP, HTML, CSS and javascript. Enthusiasm free software cloud solutions and trying new things.

Mentor: Kyle Cunningham? Robin Appleman? Frank K?

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. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time.

For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.

A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.

Expected results: The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.

Possible features:

Uses XML for survey design to make it easy to create and launch new surveys
Uploading or emailing data at end of study
Can be a single survey, or a survey study over a period of time
Configured to open on a specific event

Knowledge Prerequisite: JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.

Mentor: Celeste Lyn Paul, someone else?

KDE SDK

Project: Umbrello UML Modeller QGraphicsView Port

Brief explanation: Umbrello UML Modeller uses the old and limited Q3Canvas class. There is an unfinished port to QGraphicsView that should be completed.

Expected results: A stable Umbrello using QGraphicsView.

Knowledge Prerequisite: Programming Qt. Basic understanding of UML.

Mentor: Jonathan Riddell

Project: Umbrello UML Modeller Port to Calligra Flake

Brief explanation: Umbrello UML Modeller uses the old and limited Q3Canvas class. Flake Calligra Flow [4] (formelly Kivio) has very much similar graphics capabilities as UML Modeller.

Expected results: A stable Umbrello using Calligra Flake, sharing code with Calligra Flow.

Knowledge Prerequisite: Programming Qt. Basic understanding of UML.

Mentor: Calligra developers

Project: A Mercurial plug-in for Dolphin

Brief explanation: At the moment, KDESDK includes Dolphin plug-ins for the version control systems Subversion and Git. They provide a GUI to access the basic functionality of these VCSs via context menu entries. The current versioning state (e.g. "locally changed" or "conflicting") is also displayed through icon overlays.

To complement support for the major systems, this project aims to implement such a plug-in for Mercurial.

Current plug-ins: KDESDK/dolphin-plugins
The interface to implement: kversioncontrolplugin.h
A corresponding feature request: Bug 164732

Expected results: Version states are displayed correctly. Basic Mercurial functionality is accessible via the context menu. Intuitive dialog design.

Knowledge Prerequisite:
Profound knowledge of Mercurial concepts, commands and workflows.
C++, Qt (mostly QtGui)
No knowledge of Dolphin source code required.

Mentors: Sebastian Dörner <[email protected]>, Peter Penz <[email protected]>

Okular

Project: Advanced text layout recognition engine

Brief explanation: Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.

See relevant entry in KDE bugzilla about it: 161324

Expected results A better text selection experience for the user.

Knowledge Prerequisite C++, Qt

Mentor Albert Astals Cid

Project: Annotation writing in PDF documents

Brief explanation: Okular currently can read the annotations in PDF documents, but it cannot change in any way the ones in the documents -- meaning add, remove, and edit. This is due to to limitations in the Poppler library, which lately got very few annotation editing capabilities, with none of them being exposed through the poppler-qt4 frontend (and so usable by e.g. Okular). The task is to work on either Poppler to allow to edit annotations in poppler-qt4 (possibly enabling more editing options in the poppler core), and to make Okular able to make the changes in the PDF documents, taking also care of the annotations currently stored externally.

Expected results The possibility to change/edit the annotations in a PDF document, and to edit more annotation options in Okular.

Knowledge Prerequisite C++, Qt

Mentor Pino Toscano

Knights

Knights is a chess program for KDE, it resides in Extragear/Games. It supports local plays, playing against a computer engine, an opponent on a chess server, and also watching two computers. It uses the KDE technologies to provide a consistent look-and-feel with Oxygen colors and Plasma clocks.

Knights web site

Project: Saving, loading and analyzing games

Brief explanation: Knights currently does not support any form of storing and analyzing games, expect for simple undo and redo. This suffices for casual play, but for serious play something more powerful is needed.

One part of the project is to enable saving board positions to a file, and reading from it at a different time. This should be done using a standard format (PGN), so that external games can be analyzed with Knights and vice-versa.

Another part is an "analysis" mode, where a playerc can freely move both his and the opponent's pieces. The interface should rate the current board position, provide hints, maintain alternative timelines for comparison, etc. The student should be in contact with chess players (could be on a forum or IRC) to know the other important features of such a mode.

Expected results: Ability to save move history to a file, and read from it at a later time. An advanced 'analysis' mode for direct manipulation and interaction with a chess engine, with tools to help the player.

Knowledge Prerequisite: Qt, C++. Knowledge of Chess rules is not needed, but some contact with chess players is preferred.

Mentor: I will try to participate as a student this year, so I can't be a mentor and I'm looking for someone else. Knights' current codebase is quite small and not complicated. I'm available at Miha Čančula.

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: Code completion in Gluon Creator

Brief explanation: Gluon based games have game logic written in ECMAScript, and while it uses the powerful katepart for editing the scripts, it lacks completion beyond simple word completion. KDevelop has a powerful code knowledge system which can be used by other projects through the kdevplatform libraries. This project is about taking the beginnings of ECMAScript/javascript support in KDevPlatform and extending it, and then integrating it into Gluon Creator.

Expected results:

The completion of ECMAScript/JavaScript support for KDevPlatform
The integration of this support into Gluon Creator

Knowledge Prerequisite: Qt/KDE development (includes C++ & git). Knowledge of KDevPlatform an advantage, as is knowledge of ECMAScript

Skill level: medium to high.

Mentor: Arjen Hiemstra and Dan Leinir Turthra Jensen, with assistance from someone on the KDevelop team

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. Aleix Pol has created a system used in KDevelop which is powerful and very useful for programmers, which we suggest is used for advanced version handling in Gluon Creator. This would then be exposed more directly in the user interface, creating a work flow which assists in the use of the version control system.

Expected results:

Integration of Aleix Pol's kdevplatform based version control integration, or similar
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: Arjen Hiemstra and Dan Leinir Turthra Jensen

Project: Achievements/statistics system

Brief explanation: Many digital distribution platforms, such as XBox Live, PlayStation Home and Steam, have a system by which players are granted certain trophies by performing certain tasks in the games they play. Even though they can be, these tasks are not necessarily a part of the normal game-play: For example it might be that you have played a certain level a specific number of times. The Open Collaboration Services have, since version 1.7, contained a generalised system for storing achievements and the progress a user has made on them.

This project is to integrate the OCS Achievements module into Gluon, and to create a general system by which statistics required for tracking progress in a game can be generated.

Expected results:

A set of Components and Assets for storing and tracking statistics of game interactions
Same for handling the Achievements themselves

Knowledge Prerequisite: Qt/KDE development (includes C++ & git). Knowledge of achievements systems a plus.

Skill level: medium to high.

Mentor: Arjen Hiemstra and Dan Leinir Turthra Jensen

Project: Dynamic Shader Generator

Brief explanation: Gluon these days features a completely shader-based graphics library. One of the issues with this is that you need to create shaders, which is not trivial for most people. This project would alleviate that problem by creating a system similar to many professional graphics applications, where shaders are created by linking small elements - nodes - together. If time permits, this would also be exposed in the interface properly through a node-based editor.

Expected results: A system that is able to create basic shaders and can be extended to create more advanced shaders.

Knowledge Prerequisite: Qt/KDE development (includes C++ & git), OpenGL/GLSL and a general knowledge of graphics programming is a definite must.

Skill level: medium to high.

Mentor: Arjen Hiemstra and Dan Leinir Turthra Jensen

Project: Integrating SMARTS Game AI system

Brief explanation: In the fall of 2009 and spring of 2010, three students at Aalborg University created a game AI system based on the simple Behavior Tree concept for use with Gluon. As this was an educational project, however, while the project was completed, the code was never merged into Gluon. This project is to take the project code, clean it up and adapt to new Gluon APIs, and if time permits to create a more pleasantly built and better integrated editor for the behavior trees.

Expected results:

A new sub-module in Gluon containing the standalone parts of the SMARTS AI system (gitorious)
Cleaned up integration of the SMARTS components and assets
Optional: An editor KPart for integration directly in Gluon Creator

Knowledge prerequisite: C++ development experience, Qt/KDE development experience an advantage but can be disregarded if knowledgeable of other modern OOP frameworks.

Knowledge of the Behavior Tree concept in general an advantage, but this can be gained in a reasonably short amount of time (as both video tutorials on the concept as well as the reports from the university projects SMARTS resulted from are available, containing descriptions of this).

Skill level: Novice to medium.

Mentor: Dan Leinir Turthra Jensen and Arjen Hiemstra

Project: XInput2 Backend for Gluon Input

Brief explanation: The Gluon Input system is designed to support multiple back-ends for optimal integration with the underlying system. Since its inception, a system based on evdev has been used. This system proved to be cumbersome due to evdev devices only being accessible by the root user. A fallback system was created using the input handling in Qt. However, Qt does not distinguish between multiple devices and also does not support specialised game input devices like joysticks.

The primary goal of this task is to create a back-end for Gluon on Linux that uses the XInput2 extension for X for device access. This extension provides support for multiple devices to X windows and is currently being built upon for multi-touch support in X. Ideally, this back-end would expose all available input devices to the Gluon Input system and support adding and removing devices based on connect/disconnect events. A secondary goal would be to have this input information available in Gluon Creator and games built using Gluon.

Expected results:

A Gluon Input back-end based on the XInput2 extension.
If time permits, enhancements to the user-facing side of the input system that enable multiple devices to be used by game developers.

Knowledge prerequisite: C/C++ development experience using Qt. Experience with development using X and related libraries is a definite advantage.

Skill level: Medium to High.

Mentor: Arjen Hiemstra and Dan Leinir Turthra 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
Telepathy-KDE
We can be found on IRC in #kde-telepathy

Project: Distributed Shared-State system based on DBus tubes for KDE apps

Brief explanation: Telepathy DBus tubes provide an easy way for collaborative applications such as KWhiteboard to be built. However, a common issue is the need of applications wishing to use DBus Tubes is the need for a way for participants to keep their application states synchronised in the absence of a single "server". This is an intellectually challenging project as well as requiring coding, so please ensure you join us on IRC and get to know us and the project before submitting a proposal for this project.

Expected results:

A distributed-state mechanism generic enough to be used by any KDE application wishing to build a serverless collaborative system on top of DBus tubes.
A sample implementation using this state layer, either by adding basic functionality to KWhiteboard or another application of your choice.

Knowledge Prerequisite:

Qt/KDE development (includes C++ & git).
Telepathy development
As a minimum, a basic understanding of how DBus works
A desire to take on a challenging project

Skill level: high.

Mentor: George Goldberg

Project: Amarok Playlist Sharing

See [5]

Project: Innovative new UI/Interaction Methods

Brief explanation: Telepathy allows real-time communication to be integrated far deeper into the computing experience. Come up with some interesting novel ideas for how to make this integration happen (new ways of displaying information, novel plasma integration methods, you name it), and implement them.

Expected results:

This project is very open ended, but we would expect to see a series of deliverables outlined in the proposal along with some justification for why they are interesting ideas. Sufficient research should be undertaken at the proposal stage to ensure the deliverables are suitable and achievable within the context of the rest of the KDE Software Compilation and Workspaces.

Knowledge Prerequisite:

Qt/KDE development (includes C++ & git).
At least basic Telepathy development
A good imagination and a keen interest in innovative interaction design.

Skill level: medium.

Mentor: George Goldberg

Project: Multi-Player gaming in KDE games

Brief explanation: Telepathy tubes allow collaborative features to easily be added to any application. This project is to develop multiplayer support on top of telepathy for the KDEgames suite of games. If you wish to propose this idea, it is important to discuss your proposal both with the KDE games team and the KDE Telepathy team.

Expected results:

Infrastructure for Telepathy Tubes based multiplayer gaming in KDE games.
Support for one or more games being played multiplayer over Telepathy Tubes.

Knowledge Prerequisite:

Qt/KDE development (includes C++ & git).
At least basic Telepathy development

Skill level: medium.

Mentor: Someone from KDE Telepathy and someone from KDE Games.

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 could parse this information of running programs, generate the necessary vocabulary, grammar and commands to trigger any on-screen buttons, menus, etc.

This would give simon control of running Qt and GTK applications without any specific configuration and greatly enhance the use of simon in a full-fledged desktop.

Expected results A simon plugin that listens to AT-SPI messages on DBus and exports the necessary vocabulary / grammar / commands.

Knowledge Prerequisite C++, Qt, Motivation

Mentor Peter Grasch <[email protected]>

Contact Besides myself personally ([email protected]) you can also contact us at [email protected] and through the forum on our developer page.

Resources The command infrastructure is heavily documented (an older snapshot can be found online).

Project: Context dependent speech recognition

Brief explanation As speech recognition is at its core a statistical analysis, recognition accuracy decreases as more "candidates" need to be considered. Therefore a system that only distinguishes between the numbers from 1-9 will always work better than the same system trying to differentiate between hundreds of words. In short: It's easier to separate "One" and "Nine" than "One", "Con", "Oh", etc. In a speech control scenario only a couple of commands are relevant in each context. simons scenario system could be used and combined with a newly developed context recognition system (probably based on running applications or even the current activity as exposed by KDEs activity system) to deactivate words when they are not needed at the moment.

Expected results Context recognition system and an extended simon / simond protocol to relay context information. The scenario format and UI would also need to be adapted to allow the user to define in which contexts the scenario should become active. The result would be a greatly improved recognition performance in almost any practical use case.

Knowledge Prerequisite C++, Qt, a lot of motivation :)

Mentor Peter Grasch <[email protected]>

Contact Besides myself personally ([email protected]) you can also contact us at [email protected] and through the forum on our developer page.

Project: Voxforge integration

Brief explanation The voxforge project aims to create GPL acoustic models. Using these models, simon does not need to be trained at all to work. The models are speaker independent and - at least for English - are already good enough for fairly accurate recognition.

To further improve the Voxforge models (especially for other languages), the Voxforge homepage provides a Java applet to submit new speech by recording voice samples. However, users do not get a direct benefit from contributing voice to the project.

By integrating Voxforge in simon, users could train their local Voxforge copy and submit the collected samples to Voxforge. They would directly improve the recognition for them personally but also help to further improve the general Voxforge model.

To sum up: A lot of users already train their acoustic model locally. If we could gather all that data in a convenient way for the end user, the general model would rapidly improve and end-user training wouldn't even be necessary in most cases anymore.

Knowledge Prerequisite C++, Qt

Mentor Peter Grasch <[email protected]>

Contact Besides myself personally ([email protected]) you can also contact us at [email protected] and through the forum on our developer page.

KDE WWW / KDE Sysadmin

The KDE WWW encompasses not only the KDE Forums, but also Userbase, Techbase, the Community Wiki, Documentation, many International Web Pages, Mail lists, News, the Planet, Git, and others, housed on multiple servers. More details here.

Project: Single login through Identity.KDE.org Integration

Brief explanation: Create a username mapper with some form of a UI on the identity and wiki/forum, etc. sides. The most generic way to do it would probably to have special ldap properties for each of the various properties that already has its own user db (wikis, dot, forum), then have an agent running on those servers which can access their dbs. Users would then go to identity, open a "username mapper" module, the agent would then check to see if the username was in use. If it is, the user then gets to select a username from a list of available generated names or map to a pre-existing username if the emails match.

Expected results:

KDE users will be able to manage logins to all KDE web resources using Identity. Users would also be able update emails and other user details when they change as well.

Knowledge Prerequisite

Knowledge of how KDE Identity works, plus the software it bridges with, coupled with how to write a daemon (probably in a scripted language) which has to accept possibly invalid user input.

Mentor

Ben Cooksley <[email protected]>
Another mentor who knows daemons

Contact

IRC channel: #kde-www on Freenode
Mailinglist: kde-www See http://kde.org/mailinglists/ for details

KDE on Windows

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

Project: single applications

Brief explanation:

When the KDE repository was on Subversion, applications and libraries were organized in modules: kdelibs, kdeworkspace, kdegraphics, kdeutils, etc. Think of a module as a "suite" of somehow-related applications, libraries, and everything that was needed to build them (build system checks, configuration, etc).

In order to build an application belonging to a module (for instance, KSnapshot, which was in kdegraphics), it was necessary to checkout the source for the whole module and run CMake against the module. Building a single application initially impossible, although later it was made somewhat possible through certain tricks Alexander Neundorf implemented in the build system.

Now that KDE is moving to git, most applications and libraries are easy to build standalone: they have clear dependencies and include all the checks, definitions, etc in each build system

KDE on Windows uses its own package manager (emerge) to build and install KDE and the third-party dependencies KDE needs. At the moment, it builds and installs modules, not individual applications (save for some exceptions).

Your tasks:

make all the changes required in emerge so that building individual applications is possible
update all the recipes in portage accordingly: we want individual applications, not modules
update the current installer to install individual applications instead of modules

Expected results:

KDE on Windows users and developers will be able to build and install standalone applications (the dependency chain will of course be kept!)

This task is important to achieve best results in the next proposed task.

Knowledge Prerequisite

This is actually a fairly easy task and even if you only have a general knowledge of computers and software development, you can probably learn what you need in a couple of weeks.

Desirable knowledge includes svn, git, Python, Windows, build systems (CMake, qmake, etc), compilers (gcc/mingw and Visual C++) and cross-platform concepts (esp. Linux-Windows)

Mentor

TBA. Patrick Spendrin? Pau Garcia i Quiles?

Contact

IRC channel: #kde-windows on Freenode
Mailinglist: kde-windows See https://mail.kde.org/mailman/listinfo/kde-windows for details
Website: http://windows.kde.org

Project: new KDE on Windows installer

Brief explanation:

Currently, KDE on Windows can be installed using two ways:

The installer is Cygwin-like, whic is very different from the normal InstallShield, NSIS, MSI, etc installers.

Your task: create a new installer, something which looks much more appealing and easier to use. The Apple Mac AppStore is a good example.

This new installer will assume sensible defaults (we'll discuss when it's time), use the Oxygen style, etc

You can probably re-use most of the download and package management intelligence from the current installer.

Expected results:

A new, installer. It should consist on a SINGLE executable, i. e. it needs to be statically compiled.

Knowledge Prerequisite

Software development with a compiled language

Desirable knowledge to understand why emerge and the current installer do what they do includes svn, git, Python, Windows, build systems (CMake, qmake, etc), compilers (gcc/mingw and Visual C++) and cross-platform concepts (esp. Linux-Windows). You can probably learn about this and how KDE on Windows works in a couple of weeks.

As for the implementation itself, it does not really matter as long as you get the job done. The sensible option, and consistent with the rest of KDE, seems to be Qt (QtWebKit, QML, etc) but if you are a C#, F#, C++ CLI, etc ninja, we'll gladly accept you.

Mentor

TBA. Patrick Spendrin? Pau Garcia i Quiles?

Contact

IRC channel: #kde-windows on Freenode
Mailinglist: kde-windows See https://mail.kde.org/mailman/listinfo/kde-windows for details

KDE Accessibility

The KDE Accessibility subproject aims to make KDE applications accessible to all users no matter the disability.

Project: You decide

Brief explanation:

I haven't got any particular projects in mind, but if you can think of something there is lots to do. Use your imagination

Your possible tasks:

Take an application, make it fully accessible (Actions, menus, text, ensure it follows kde color scheme, etc.)
Update the website with current information.
Test and debug crashes in qt-atspi bridge itself.

Expected results:

This task is important to help get KDE usable by anyone with disabilities.

Knowledge Prerequisite

This is actually a fairly easy task and even if you only have a general knowledge of computers and software development, you can probably learn what you need in a couple of weeks.

Desirable knowledge includes svn, git, dbus, QAccessible, etc.

Mentor

Jeremy Whiting <[email protected]>

Contact

IRC channel: #kde-accessibility on Freenode
Mailinglist: kde-accessibility See http://kde.org/mailinglists/ for details
Website: http://accessibility.kde.org

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

Category:

Mentoring