GSoC/2010/Ideas
Guidelines
Information for Students
These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.
Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.
When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big!
If there is no specific contact given you can ask questions on the general KDE development list [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.
Adding a Proposal
When adding an idea to this section, please try to include the following data:
- if the application is not widely known, a description of what it does and where its code lives
- a brief explanation
- the expected results
- pre-requisites for working on your project
- if applicable, links to more information or discussions
- mailing list or IRC channel for your application/library/module
- your name and email address for contact (if you're willing to be a mentor)
If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.
Ideas
Amarok
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: Playdar integration
Brief explanation: Integrate playdar into Amarok, both as a collection backend, and as a searchable/playable context applet.
Expected results: Playdar is a new "music content resolver" service (http://www.playdar.org/), started by RJ of Last.Fm fame. Its task is to find how to play any song that it is given, using a number of pluggable backends. Please see the website for more information, as well as http://www.playgrub.com/ for an app example. By integrating playdar into Amarok, you will allow users to explore and play tracks from any of the resolvers that playdar has available. Imagine dynamic playlists that can pull tracks from mp3tunes, amazon full track previews, napster, soundcloud, local LAN computers, and more. Imagine browsing the local network and seeing what tracks are seamlessly available for you to play and organize. An implementation would both supply a collection backend, for browsing, and a context applet, for doing a simple search in the context view.
There would be some work required also on the playdar side of things---although it is planned to support browsing collections, it is not implemented yet. Playdar is written in Erlang, so this is also a perfect opportunity to get your feet wet doing functional programming.
Knowledge Prerequisite: Knowledge of C++ and Qt is a requirement. Knowledge of Erlang a plus, but pretty rare. Enthusiasm for trying new things and pushing the future of social music forward a requirement.
Mentor: Leo Franchi <[email protected]> or another Amarok developer.
Project: Dynamic Playlists Overhaul
Brief explanation: Throw out the old dynamic playlist code, and integrate existing backend code for generating user-specified dynamic playlists as well as design a smashing new intuitive UI for controlling them.
Detailed explanation: The current dynamic playlist system is merely decent at best. It fails a lot of expected use-cases, and the UI misleads the user by lying about what it can do. There is already a new advanced playlist generation framework designed by a developer (Soren Harward) that is sitting in a git branch, ready to be merged. However, the UI is severly lacking, and needs to be redesigned. Designing the UI for such a complex piece of functionality will be a significant UI design / HCI challenge, and the main thrust of this project. While there are some mockups already available, most of the design will need to be drawn up by the student.
Knowledge Prerequisite: Knowledge of C++ and Qt is a requirement. Interest in usability and HCI a plus. Interest in UI design is also important.
Mentor: Leo Franchi <[email protected]> or another Amarok developer.
Project: On the Fly Transcoding
Brief explanation: Allow media to be seamlessly transcoded to another format whenever it is copied from one collection to another.
Expected results: Amaroks concept of collections allows media to be easily moved and copied around. In many cases however, the format you want in one collection is not the same as you might want it to be in when copying it to another collection. A common example is having your entire local collection in lossless FLAC, but wanting to copy songs to a mobile device that only supports mp3 (or even if the device supports open formats, you might want to transcode it to ogg to save space). On completion of this project, an option to enable transcodeing should be integrated into the "Move/Copy to collection" flow in a way that it is available whenever this is used between 2 collections. A big part of this project will be to determine the most suited library or application to use as the backend of the transcoding engine.
Knowledge Prerequisite: Knowledge of C++ and Qt is a requirement. Knowledge of media formats and the different available apps and libraries for transcoding them is a bug plus.
Mentor: Nikolaj Hald Nielsen <[email protected]> or another Amarok developer.
Project: Distributed Collections
Brief explanation: Allow several instances of Amarok on a network, each with their own distinct local collection, to seamlessly search, browse music from each other.
Expected results: On completion of the project, it should be possible to allow other instances of Amarok to access your local collection, as well as have access to the collection of other instances of Amarok, if their users allow it. A protocol for searching, browsing and streaming music should be in place, either developed from scratch or based on an existing standard (if a suitable one can be found). Issues such as authentication and auto discovery must be considered and a solution found.
Knowledge Prerequisite: Knowledge of C++ and Qt is required. Knowledge of XML, JSON or other data exchange schemes will be a big benefit, As there are many open question in this project, the student is also required to be capable of independently coming up with ideas for solutions to many issues, so a high degree of creativity and independence is required.
Mentor: Nikolaj Hald Nielsen <[email protected]> or another Amarok developer.
Project: Amarok & KDE UPnP integration
Brief explanation: UPnP is a network auto-discovery and services protocol that among other things allows serving media to connected devices in the local network.
By creating a UPnP KIO slave and supporting infrastructure it becomes possible to access this media directly from any KDE application. In Amarok some extra integration is needed to make the UPnP MediaServer a full Collection. This includes indexing the contents locally when the server has no, or limited support for search.
Expected results:
- A UPnP KIO slave based on an already existing or in development framework for UPnP.
- An Amarok Collection implementation including a functional QueryMaker using UPnP-search or MemoryQueryMaker.
- Optionally a PlaylistProvider implementation for UPnP-native playlists and playlist files found on the server.
Knowledge Prerequisite: C++ and UPnP. KIO-slave or Amarok experience is recommended.
Mentor: Bart Cerneels
digiKam
Photo Management program
digiKam project web site - Mailinglist - IRC channel: #digikam on Freenode.
Project: Non-Destructive Editing
Brief explanation: Non-destructive means that the original image is not overwritten when editing. Instead, the applied changes are stored and a new version of that image is created. Version history can be accessed.
Expected results:
- Define a format to store editing operations - research existing standards or similar free software approaches, or come up with a home-made XML format.
- Adapt the existing image plugins to read and write their settings from this XML format and to re-apply a described operation to a given image (this is a laborious but relatively easy task)
- work together with your mentor on storing version history in digikam's database and the image's metadata. (this is needed to finish the project, but it's not the core of the student's work). Set up a simple file naming scheme to store the original and derived files.
- Implement the user interface changes: No more Save/Save As in the image editor. Instead, saving as current version, forking a new version, or exporting. Stacks of images (original/current version) in the album icon view.
- Build a widget to display version history. Optionally this is a really nice widget, a tree view with buttons to show information. Optionally there is also support to take a set of applied changes, store it and apply it to a different image.
Knowledge Prerequisite: C++ and Qt. Some interest in image editing.
Mentor: Marcel Wiesweg <marcel dot wiesweg at gmx dot de>
KDE Edu
Sabine Emmy Eller suggested the development of a “general conversion tool” for tables to various xml formats and from one xml to another xml format etc. where one can add further formats over time would be great. If this is a good idea we can actually start to think about more detailed specifications for what we need.
Project: Community Integration for KStars
Brief explanation: This feature is expected to be of use to amateur (hobby) astronomers. The idea is that there are aspects of amateur astronomy which are collaborative. For instance, one might want to view observations by other amateur astronomers around the world before making an observation of an object. Again, one would like to share their own observations with everyone else. There are more possibilities, and the student is encouraged to come up with them.
KStars produces observation logs in an XML format that is expected to adhere to the OAL 2.0 schema. The project will involve extending the existing implementation of the OAL 2.x schema and ensuring that it is fully compatible with the schema. The next target would be to make it possible to retrieve observation logs in XML format from the internet and present it to the user in a nicely accessible manner. The user should also be able to (eventually) submit his own logs to a server.
Expected results: Better OAL 2.x compliance in KStars, Ability to retrieve observation logs from the internet, Ability to export one's own observations in XML format to a server.
Knowledge Prerequisite: C++. Familiarity with Qt and XML parsing will help.
Mentor: Prakash Mohan <prakash DOT mohan AT kdemail DOT net> / Akarsh Simha <akarsh DOT simha AT kdemail DOT net>
Project: OpenGL support for KStars
Brief explanation: KStars currently renders graphics using QPainter. To provide a realistic and aesthetic representation of the night-sky, GL functionalities like texture-mapping will be beneficial. The aim of this project would be to use the Qt OpenGL module to render graphics in KStars.
Expected results: More realistic simulation of the night-sky, better aesthetic appeal.
Knowledge Prerequisite: C++. Knowledge of Qt and OpenGL will greatly help.
Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>
Project: Additional Catalogs in KStars
Brief explanation: KStars currently knows about deep-sky objects from the NGC and IC catalogs and stars from the Henry-Draper catalog. Popular objects from many other catalogs are not listed [eg: Collinder] and multiple designations for the same object are not supported. The aim of this project is to implement support for objects from SAO, UGC, PGC, MCG, PK and Saguaro Astronomy Club catalogs. This might involve revamping the way data is stored and accessed in KStars :-).
Expected results: Support for multiple designations, Many more catalogs in KStars.
Knowledge Prerequisite: Database handling will help.
Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>
Project: Rocs - Graph File Formats and Teacher Mode
Rocs is a Graph Theory IDE to study and learn Graph Theory.
Brief explanation: Rocs lacks graphs formats. it currently supports one internally and GML by the amazing work that Wagner is doing on it's plugin system. but we do need more: dot, gml, umbrello files, anything graph - like should be openable by rocs. Also, teacher mode is a mode with various graph scripts ( coloring, smaller path, bigger path, etc. all of the algorithms studied in Graph Theory + a few more )
Expected results: Rocs should be able to open almost all of the graph files around, and also in teacher mode, the student could test if his algorithm is correct by comparing the results with the one in the teacher mode.
Knowledge Prerequisite: Qt - C++ - Javascript are prerequisites. all the rest is optional, but being in a Graph Theory class at university could be cool ;)
Mentor: Tomaz Canabrava
Project: Cantor: Add a new Backend
Brief explanation: Write a new Backend to Cantor, to bring your favourite Mathematical Software, (e.g. Octave, SciLab, XCas or whatever you prefer) to Cantor. Implement needed features in Cantor, to expose the whole potential of the Backend to the user. Implement assistant dialogs for the most commonly used functionalities
Expected results: The user should be able to use the Math package from within Cantor, without (or with very few) limitations, compared to using the standard interface (every important feature should be exposed).
Knowledge Prerequisite: Qt, C++, KDE, are needed to code for Cantor. You should also be familiar with the Math Software you want to write a backend for.
Mentor: Alexander Rieder
Project: KHangMan
Brief explanation: Improve GUI and code refactoring. About the GUI, start with a usability study to redesign the GUI. The menus are to be redone (having an Open Recent Files action for example) and maybe suppress the Categories and Languages menus. Allow an easier management of themes as well, maybe have a GHNS theme manager. For code: refactor the way files are loaded. Allow to start with no file. Separate the data code (about the letters) from the GUI.
Expected results: Makes it visually more attractive for children, give better feedback on result, make the program workflow better
Knowledge Prerequisite: Qt, C++, KDE
Mentor: Anne-Marie Mahfouf
KDE Games
Project: KHighscore2 library
Brief explanation: The KDE Games module features the libkdegames library, which provides common components for games, such as network access and standard UI elements. Among these classes is the highscore system KHighscore, which is starting to show its age. We want you to write a successor based on Qt's model/view framework.
Expected results: The coding work itself should not be too hard, but you need to create a future-proof object-oriented design. The games in the KDE games module have very different requirements for a highscore system, we expect you to evaluate these and come up with a concept that fits most requirements. Backwards compatibility to existing highscore records is desired. When the library is finished, you should port as many of our games to the new classes.
Knowledge Prerequisite: C++ and Qt. Profound experience with Qt's model/view framework.
Mentor: none at the moment (contact [email protected] mailing list for further questions)
Project: New AI for KsirK
Brief explanation: KsirK is a strategy game inside the kdegames module where you must conquer the world country by country. You can also have specific goals. Its current AI, taken from another old implementation of the same game is really no efficient and should be replaced by better one, with a scalable power.
Expected results: You will need to study the theory of AI design for strategy games and the other Free Software implementations of the same game (like TEG for example). You will then develop and integrate the new AI for a release with the next KDE SC version.
Knowledge Prerequisite: C++ and Qt. An experience with strategy games AI would be useful.
Mentor: none at the moment (contact [email protected] or [email protected] mailing list for further questions)
KDevelop
KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages.
Website - Mailing list - IRC channel: #kdevelop on Freenode.
Project: Quanta+ 4
Brief explanation: Quanta+ 4
Expected results: Revive the Quanta+ brand for KDE 4 and provide a usable IDE for webdevelopment. Take advantage of the KDevelop framework and reuse it's plugins and adapt them to give the user a good experience while programming PHP, CSS, HTML and JavaScript.
Knowledge Prerequisite: KDE, Qt, KDevplatform/KDevelop
Mentor: Niko Sams
Project: Community Integration
Brief explanation: Integrate community related workflow, e.g. VCS support, in KDevelop.
Expected results: Integrate a proper VCS support for SVN and Git into KDevelop and see what other aspects of a community related workflow could be integrated.
Knowledge Prerequisite: KDE, Qt, KDevplatform/KDevelop
Mentor: Andreas Pakulat
Project: OBS (openSUSE Build Service) Integration
Brief explanation: openSUSE build service allows developers to create and release open source software for openSUSE and other Linux distributions easily on different hardware architectures.
Expected results: A plugin for KDevelop that would allow a developer to easily check-in source, build, and get OBS status from within a KDevelop project. In other words, it would allow for seamless development to deployment.
Knowledge Prerequisite: KDE, Qt, KDevplatform/KDevelop
Mentor: ?
KDE PIM
KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc.
One of the current challenges is utilizing the new cross-desktop PIM infrastructure called Akonadi.
There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc.
Website - Project Wiki - Mailing list - IRC channel: #kontact and #akonadi on Freenode.
For a list of ideas that are not yet fully spelled out, see the brainstorming list of Summer of Code ideas of the last PIM meeting.
Project: New Kontact summary based on Plasma
Brief explanation: Create a new summary for Kontact that is based on Plasma.
Expected results: The new Kontact summary should be based on Plasma and have every feature that the old summary had. The summary should look nice and have lots of bling. It should be possible to place single components of the summary on the desktop as well, as plasmoids.
Knowledge Prerequisite: C++ and Qt knowledge is needed, Plasma experience would be welcome.
Mentor:
Project: Improved HTML support for KMail's composer
Brief explanation: The HTML support for KMail's composer is currently limited. This should be improved: Replying and forwarding should (optionally) preserve the HTML format. The composer should use WebKit editing so that all HTML is fully supported.
Expected results: Replying and forwarding HTML mails should be fully supported. The QTextEdit-based widget in the composer should be replaced by a WebKit-based widget, to support all HTML instead of a small subset.
Knowledge Prerequisite: C++ and Qt
Mentor: Thomas McGuire
Project: Improved theming support for the message viewer
Brief explanation: In KMail, it is currently possible to chose between different header styles, such as 'fancy' or 'brief'. These header styles currently have to be written in C++.
The goal of this project is to use the Grantlee library to provide better and easier theming support.
Expected results: The viewers of KMail, KNode and Akregator should all be ported to Grantlee. Some defaults themes should be provided, at least replacing the existing 'fancy' and 'standard' themes.
Optionally, Get Hot New Stuff should be used so that the user can easily download new themes.
Optionally, the user should have some sort of control over which header fields of the mail are displayed, see Wish 16270.
Knowledge Prerequisite: C++ and Qt
Mentor: Thomas McGuire, Stephan Kelly(?)
Project: Easy Import and Export of all PIM data in Kontact
Brief explanation: There should be an easy way to import and export all PIM data including the configuration data, to make it easy to exchange data and to move the Kontact data to another installation.
Expected results: There should be a central way in Kontact to import and export all data. Right now, some individual applications have their own ways to import and export data, and this should be unified. The new import and export tool should be able to deal with the following
- Configuration data, such as applications settings and account settings
- The actual data, such as mails, feeds, contacts and calendar entries
- Metadata, such as Nepomuk tags and annotations or Akonadi item flags
- Cached data, such as the cache of an IMAP account, to avoid re-downloading the mails
It should be possible for the user to have a fine-grained selection of the above so that the user can decide what to export or import.
Ideally, it should be possible to export all this to a single archive file which can be later re-imported.
There are several bug reports on [bugs.kde.org the KDE bugtracker] that request something like this, you might get additional ideas from them.
Knowledge Prerequisite: C++ and Qt
Mentor:
Project: Unified account wizard for Kontact
Brief explanation: Provide a nice wizard that can set up all of Kontact in one go and is easily extensible to support new configuration templates. The wizard should set up accounts/resources for all Kontact components.
As an example, let's say the user has a Google account: That includes Google Mail, Google Calendar, Google Contacts and Google Reader. The wizard should only ask for the username and password of the Google account of the user, and then set up Akonadi resources for mail, calendar, contacts and feeds automatically.
This should of course not be limited to Google: The system should be based on configuration templates so that many popular providers can be supported. Writing such configuration templates should require no coding so that many people write them, leading to a broader support of providers in the wizard
Expected results:
- Write and integrate a usable wizard for Kontact that combines setting up accounts/resources for mail, calendar, contacts and maybe more.
- Make it easy to use: The user should only need to input the bare minimum of information, and the wizard auto-detects all the correct settings, based on configuration templates
- Provide as many sample configuration templates for popular services as possible, for example for Google, AOL and other popular providers
- Optionally, integrate Get Hot New Stuff so that it is possible to download new configuration templates.
Knowledge Prerequisite: C++ and Qt
Mentor:
Project: More Nepomuk Integration in Kontact
Brief explanation: Nepomuk provides wide possibilities of doing cool new things. The goal of this project is to come up with interesting ideas on how Nepomuk could improve Kontact, and implement the ideas.
Some possibilities:
- Activity Journal for Kontact
- Project-Centric Views
- Person-Centric Views
Expected results:
Knowledge Prerequisite: C++ and Qt
Mentor:
Project: Personalized email addresses for each contact
Brief explanation:Facilitate usage of a different email address for each contact.
Expected results: For instance, if the user owns the domain mickeymouse.com then when he is communicating with [email protected] he would use the personalized address [email protected], and when he is communicating with [email protected] he would use the address [email protected]. The Thunderbird email client supports this with the Virtual Identity extension. See bugs https://bugs.kde.org/show_bug.cgi?id=72926 and https://bugs.kde.org/show_bug.cgi?id=159251
Knowledge Prerequisite:
Mentor:
Note: This entry was not added by KDEPIM developers. It is not enough for a complete Summer of Code project, and should be extended in case this idea is used as a project proposal.
Project: Kmail filter on Thread
Brief explanation: Facility in Kmail filter to move messages to folders based on thread
Expected results: User can define filters based on the "In-Reply-to:" message-id of a new message (message A) matching the message-id of an existing message in an existing mail folder (message B). On match, option to move Message A to the folder that contains Message B. This will help in continuing threads in the same folder in which they were started.
Please mail me if the problem statement or the requirement for this feature is not clear enough. Raj Mathur, raju at linux dash delhi dot org
Knowledge Prerequisite: Presumably, knowledge of KMail, understanding of the e-mail message RFC, C++.
Mentor: Whoever's interested and thinks this is a good idea.
Note: This entry was not added by KDEPIM developers. It is in general a nice idea. To make this work, threading has to be done independent from the message list. For example, an Akonadi agent could add attributes to the items that contain threading info. The filter and the message list would read these attributes. This requires a significant rewrite of the message list, and writing a threading agent. Also, this potentially requires fixing the Akonadi filtering framework, which is not yet integrated in KMail 2. All of the above certainly makes this enough for a complete Summer of Code project. Having filters that can read threading information would only be a side effect of all those changes.
KDE Finance
KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales...
Plasma Dashboard in Skrooge
Skrooge is a Personal Finances Manager, a part of KDE extragear.
Brief explanation: Skrooge currently has a module called Dashboard that contains several widgets showing various information about your financial situation. However we are reinventing the plasma wheel in many areas, so we'd like to switch it to plasma. The dashboard could become a generic componenet that would also be used by other applications (kontact ?)
Expected results:
- implement a newspaper view that will receive skroogoids.
- write a dataengine providing data from the current skrooge file (which is in fact an SQLite database).
- create some skroogoids that should be displayed in the newspaper view. Ability to display them on the desktop, without skrooge being opened is something to be discussed (a skrooge file may be password protected using QCA, no idea how this could be handled).
- save the dashboard config inside the Skrooge file (currently not supported by plasma, IIRC)
Knowledge Prerequisite: C++, SQLite, optionnally a scripting language supported by plasma
Mentor: Guillaume DE BURE, + someone from plasma team (?)
KOffice
KPresenter: Create animation effects and tidy our framework, ui
Brief explanation: KPresenter has just gained an animation framework but we need lots of implementations for many kinds of effects. And we need a userinterface to manipulate it.
First step would be to implement loading and showing of about 20 different animation effects. That is actually a simple and contained task which should get you into the basic workings. Next step is to create a user interface.
Expected results: About 20 effects to be implemented. Extend and adapt the animation framework as needed to fulfill that. A user interface for creating and manipulating animations.
Knowledge Prerequisite: basic XML knowledge, C++ and Qt-knowledge, being able to understand complex code.
Mentor: Thorsten Zachmann, Casper Boemann
KSpread: Improve saving to ODF
Brief explanation: ODF is the native fileformat of KSpread. As such one of the most important aspects of KSpread is to be able to load and save OpenDocument Spreadsheet files (ODS). While we are working hard on improving the support for loading, saving is not that well tested yet. The goal would be to change that, to improve the saving to ODF as much as possible. This should be done by adding unittests for loading and saving of ODF documents and fixing bugs where they show up.
First step would be to test different cases and to identify problems. As a starting point a look on the wo rk done on the Schedules, the Specs and the Code may help.
Expected results: Loading, saving and reopening a document should introduce as less unwanted changes as possible. Saving should work as good as loading does already.
Knowledge Prerequisite: ODF specs, Qt-knowledge, being able to understand complex code.
Mentor: Sebastian Sauer
Create an exciting new content type (flake shape)
Brief explanation: KOffice allows developers to create so called flake shapes as plugins. Examples of this are the formula editor, the video player and the music notation shape. We invite the GSoC developer to come up with a content type of his / her own choosing and implement that as a plugin for KOffice.
Expected results: Loading, saving and reopening a document with the shape in it should just work. There should be at least a simple way to edit the content inside the KOffice applications (mouse/keyboard handling, some dialogs).
The project is very flexible and we can have many different ones running at the same time, please feel free to submit more than one if you must. A google search for the musicflake will give you the project from a couple of years back. Further quick examples of shape types may be; knitting patterns, graphs & maths, tagclouds, etc. And naturally its possible to continue working on the existing ones. Like the formula shape and the music shape.
Knowledge requisites:
- C++
- Qt
Add support for e-book formats to KOffice
Brief explanation: Add a new export for one or more formats that are specifically tuned for e-book devices.
With the increased popularity of ebook readers there is going to be a need for tools to create ebook content. While most e-book devices can display PDF there are in fact a lot more formats in use. One such format is .epub, which allows reflowable content (unlike PDF). The format itself is based on XML and uses style sheets (CSS) to format content. There are few free software tools that can generate and manipulate this format and those that exist are restricted to command line.
Since most people creating content will most likely want to use an office suite or word processor to make documents it makes sense to add an export option for this format to KOffice.
Knowledge requisites:
- C++
- XML
- CSS
KDE on Windows
DrKonqi on Windows:
Brief explanation: DrKonqi, together with the crash handling classes need to be fully ported to Windows. Currently, DrKonqi can run on windows, but it cannot generate a valid backtrace. So, the next step is to investigate on how to produce valid backtraces, probably using the dbghelp API and libbfd from mingw binutils and how to change the current installation process to support debug packages. On the first part, there should be implementations for a debugger which will give valid results for both compilers (mingw/msvc).
Expected results: The student should investigate & document how to produce valid backtraces with dbghelp API and libbfd. Based on these findings, a debugger should be written which will generate those backtraces.
Knowledge Prerequisite:
- C++ (required)
- win32 API (strong recommendation!)
- Qt (recommended)
Mentor: Patrick Spendrin / George Kiagiadakis
KWin
KDE's window manager
Techbase page - Mailinglist - IRC channel: #kwin on Freenode.
KWin scripting support
Brief explanation:
KWin is customizable, but only using GUI options, which limits the possibilities. Adding scripting support would make the possibilities for customization virtually unlimited. See also http://www.kdedevelopers.org/node/3336.
Expected results:
Wrapping KWin internals in a suitable API and adding scripting using standard KDE/Qt scripting support. It should be possible to control various aspects of windows, query window management data, react on various events and write desktop effects in a usable way (sufficient performance and convenience). Scripting usage should be similar to other places in KDE such as Plasma, as reasonable.
Knowledge Prerequisite:
- C++, Qt, scripting language (required)
- X11 (nice to have, but not required)
Mentor: Lubos Lunak
KWin or Mobile / MeeGo
Brief explanation: Get KWin working on devices such as the N900 or other small devices so that KDE Plasma Mobile can provide the full UI stack with proper integration between plasma-mobile and kwin.
Expected results: Completed OpenGL ES support in KWin for effects, an "expose" effect that is appropriate to mobile systems triggerable by a D-Bus interface
Knowledge prerequisite: OpenGL, window management a plus
Mentor: Martin Gräßlin
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.)
Web Metadata Extractor Framework and Service
Brief explanation:
Currently, the only metadata for files available is extracted by libstreamanalyzer and obviously it's limited to the metadata already present in files. However, there's a lot more metadata that can be mined from web resources such as lyrics, movie plots and bibliographic data.
We need a plugin-based service, which would slowly crawl indexed files in background and let plugins extract additional metadata based on existing metadata. There must be a way to configure the service and plugins.
The project includes writing a number of useful plugins to "field test" the design to make sure it's viable, serve as examples for other plugin writers and provide a visible benefit to users.
Expected results:
Music: lyrics, extra album metadata(year, track count, trivia), artist/band metadata(birth date, gender).
Video: IMDB data
A convenient interface to configure and enable/disable plugins(say, user might want lyrics but doesn't care about artists), configure the service(such as frequency of recrawling to see if new metadata is available)
Mentor satisfied that plugins can be written to use the service for other purposes.
Knowledge Prerequisite:
- C++
- Qt
- SPARQL and Nepomuk or any other semantic background would help
Mentor:
Sebastian Trueg or Eveny Egorochkin
Plasma
Website - Mailing list - IRC channel: #plasma on Freenode.
Grid and Grouping Containments
Brief explanation: Containments that do widget grouping and gridding
Expected results: A desktop and a panel containment which allow widgets to be grouped or put into grids.
Knowledge prerequisite: C++, Qt and Plasma a bonus
Mentor: Aaron Seigo
Plasmoid Data Caching
Brief explanation: Right now when Plasma Netbook does not have a network connection, Plasmoids such as the news/rss, microblogging, etc. plasmoids tend to show nothing in the interfaces. A simple caching system would allow widgets to show the data that was available when networking was last available.
Expected results: Plasmoids / DataEngines relying on network access should cache data for when networking is not available and refresh when networking becomes available.
Knowledge prerequisite: C++
Mentor: Marco Martin
Mobile Status Bar
Brief explanation: Take the system tray used in plasma-desktop and plasma-netbook and make it work properly on mobile devices such as the N900.
Expected results: A functional system tray with battery, networking, etc. plasmoids working along with ability to configure the entries in it.
Knowledge prerequisite: C++, Qt
Mentor: Alexis Menard
Global Menu Bar
Brief explanation: A Plasma panel containment that provides a MacOS-style menu bar
Expected results: The menu bar containment should support showing the application menu and work with Qt/KDE apps as well as Gtk+ apps. See http://frinring.wordpress.com/2009/01/29/mac-style-menubar-for-kde-4-and-others/
Knowledge prerequisite: C++, Qt
Mentor: Aaron Seigo
Plasma Media Center - Media Browser backends and API
Brief explanation: Low level layer to allow browsing media content from web services directly from the media browser applet.
Expected results: Continue what is already there about the media browser backends and dataengine backends and make them cooperate in order to correctly retrieve media contents from web services like YouTube, Flickr, Picasa...
Knowledge prerequisite: C++, Qt, Plasma API is a relevant bonus
Mentors: Alessandro Diaferia, Marco Martin
Plasma Media Center - Ui re-styling
Brief explanation: A re-design of the Media Center Ui in order to guarantee a great user experience.
Expected results: Taking advantage of the QtDeclarativeUi framework the aim is to provide an excellent user experience in accessing local and remote media contents through Plasma.
Knowledge prerequisite: C++, Qt [,Plasma API, QtDeclarativeUi]
Mentors: Marco Martin, Artur Souza, Alessandro Diaferia
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.
This year Phonon projects are going to be hosted under the VideoLAN banner. See their webpage for ideas.
High-Level Capture API for Phonon (read: Webcam Support)
High Level Capture API for Phonon
Project: Project: Phonon-VLC improvements and test
Project: Phonon API for low-level PCM I/O
Project: Phonon API for implementing effects in applications
Phonon API for Effects in Apps
Kate
Kate is a powerful programmer's editor.
Website - Mailing list - IRC channel: #kate on Freenode.
Project: Vim-like Swap File
Brief explanation: Add swap file support, like vim has, to limit the effects of crashes.
Expected results: Kate, KWrite, etc. should be able to recover (most of) what was written after last save in case of a crash or power failure.
- IMHO the dialog presented to the user for recovery could be a bit better than vim's, too: for example, if the file hasn't been modified it doesn't make sense to offer to restore it. A "view diff" option would be extra awesome. --Chani 13:44, 28 February 2010 (UTC)
Knowledge Prerequisite: Knowledge of C++ and Qt is a requirement.
Mentor: Christoph Cullmann <[email protected]>
Project: Kobby (Collaborative editing)
Brief explanation: Add document uploading support, update to use libqinfinity 0.4, allow KTextEditor parts to control undo/redo, infinote server start/stop ability, other UI improvements.
Project Page: http://kobby.greghaynes.net/
Mentor Knowledge Prerequisite: (Preferred but not required) KTextEditor development and or usability experience.
Mentor: Needed.
Konqueror
Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/
Project Page: http://www.konqueror.org/
Project: Integrate Nepomuk in bookmarks
Brief explanation: Make a taggable bookmark system like that of Firefox, taggable and with searching for these tags in the location bar. This should integrate with the KDE semantic system Nepomuk.
Expected results:
Knowledge Prerequisite:
Mentor: ask in the mailinglist kfm-devel
Project: Akonadi-Integration, Syncing bookmarks and history over Internet
Brief explanation: write an Akonadi-modul that enables syncing of konqueror bookmarks from pc to laptop for instance
Expected results:
Knowledge Prerequisite:
Mentor: ask in mailinglist kfm-devel
Project: Mozilla Weave
Brief explanation: Weave is a new Mozilla project / Firefox addon that allows one to synchronize browser tabs, history, bookmarks, passwords & preferences between different computers via a publicly available server. The communications is encrypted and also all data gets encrypted on the client before transferring to the server so privacy is protected. Further it is completely open source so everyone is able to host ones own server, get & modify the code and so on.
Expected results:
Knowledge Prerequisite:
Mentor: ask in mailinglist kfm-devel
Mentor: ask in mailinglist kfm-devel
Mentor: ask in mailinglist kfm-devel
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: #koffice on irc.freenode.net Forums: http://forum.kde.org/viewforum.php?f=136
Project: transform tool for Krita
Brief explanation: While Krita already has two transform tools, neither is sufficient for the needs of digital artists working on concept art, comics or textures. We need a transformation tool that can rotate, scale, shear and freeform transform. This project entails a careful design specification stage in consultation with the Krita developers: the student should contact the krita developers beforehand. The implementation will likely be challenging both from a user interface and from an algorithm point of view.
Expected results: a working, polished transform tool
Knowledge Prerequisite: C++, Qt, digital art, image manipulation algorithms.
Mentor:
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. There will be data structures and gui work.
Expected results: A functioning implementation of resource management and tagging.
Knowledge Prerequisite: C++, Qt, digital art.
Mentor:
Project: Guided Painting
Brief explanation: Krita has the beginning of a guided painting system, with guides, levels of magnetism and plugins for guide types. This project is about finishing the implementation of this system: guide management, guide selection, new guide types. The guides are intended replace the geometric tools, so their usability must be very good. Both algorithm and gui work.
Expected results: A polished guided painting system.
Knowledge Prerequisite: C++, Qt, digital art.
Mentor: