Jump to content

GSoC/2013/Ideas

From KDE Community Wiki
< GSoC | 2013
Revision as of 15:33, 25 February 2013 by Jkt (talk | contribs) (Adding ideas for Trojita)

See also: GSoc Instructions, Last year ideas

Guidelines

Information for Students

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

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

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

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

Adding a Proposal

Note

Follow the template of other proposals!


Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

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

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

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


Ideas

Amarok

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

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

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

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

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

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

The student will need to:

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

...before the coding period starts.

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

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

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

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


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

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

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

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

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

Project: Improving and modularizing tag guessing

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

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

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

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

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


digiKam

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

Project: Auto Crop Tool

Brief explanation: In some users case relevant of photo workflow, as Panorama assembly for example, digiKam need an algorithm to detect black hole borders of image and crop it automatically, respecting the most largest suitable image area. No adjustment must be require by end user. As JPEG is the most used image format used in photography and as JPEG library support a loss-less crop feature, a specific way must be implemented to process JPEG crop in batch without to lose image quality.

Dependencies: Batch Queue Manager, Image Editor.

Bugzilla entries: 267436, 204135

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

Expected results: new editor and batch queue manager tools to crop automatically images

Difficulty: medium

Lead Mentor: ???

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

Project: Tags Manager

Brief explanation: Moving tags around in the small tags views from right or left digiKam sidebar can be fastidious, especially with a huge collection of items. A new dedicated windows must be created to manage all tags and relevant properties hosted by digiKam database. This tool must support drag and drop, multiple selections, copy/move operations, properties edition and duplication.

Dependencies: : digiKam core implementation

Bugzilla entries: 263299

Knowledge Prerequisite: C/C++, Qt/KDE, GUI

Expected results: new window to edit and manage all digiKam tags

Difficulty: medium

Lead Mentor: Smit Metha <smit dot meh at gmail dot com>

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

Project: HDR Composer

Brief explanation: digiKam already include a tool to make pseudo HDR image through ExpoBlending tool, based on align_image_stack and enfuse programs from Hugin project. This tool is limited to improve a litlle bit exposure latitude of images. It has creativity limitations and cannot reproduce nice HDR images, as Luminance HDR do. The goal of this project is to extend current ExpoBlending tool to add new advanced HDR worklflow. Also, some GUI improvment need to be done to be able to process more that on set of bracketing shots at the same time.

Bugzilla entries: 275364, 273254

Dependencies: ExpoBlending tool

Knowledge Prerequisite: C/C++, Qt, Imagery, math

Expected results: new tool to perform high quality HDR composing

Difficulty: high

Lead Mentor: ???

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

Project: Cloud Integration Export Plugin

Brief explanation: Creating a kipi export plugin for putting the pictures on cloud storage devices like Google Drive, DropBox, Skydrive, etc. Depends on the availability of an open source API. For any cloud storage facility, there are two possibilities, either they give an API in a common programming language, which is freely distributed and is easily implementable in our codebase. Or someone else than the service provider has created an open source API. You should be able to see some examples on github or sourceforge. Some service providers want only their API to be used, some dont mind other tool accessing the cloud using OAuth, etc. The student is expected to go through both the options for a particular cloud storage, identify the solution which is best suitable for already existing kipi-plugins framework, i.e. C++ / Qt, and implement it over the summer for atleast two major cloud services Google Drive and Dropbox.

Bugzilla entries: 300445

Dependencies: APIs from G+, Dropbox, Skydrive tool

Knowledge Prerequisite: C/C++, Qt

Expected results: new tool to import/export items to Cloud web service

Difficulty: easy / medium

Lead Mentor: Smit Mehta <smit dot meh at gmail dot com>

Alternative Mentor: ???

Project: Port Showfoto thumb-bar to Qt model/view

Brief explanation: ThumbBarView is a Qt3Support class based on Q3ScrollView class which will disappear with next Qt5. This class still only used by Showfoto editor. It must be ported to Qt model/view implementation using already existing common classes used in digiKam core.

Dependencies: digiKam core, Qt model view

Knowledge Prerequisite: C/C++, Qt, model/view

Expected results: implement Showfoto thumb-bar to model/view

Difficulty: medium

Lead Mentor: Islam Wazery <wazery at ubuntu dot com>

Alternative Mentor: ???

Project: Port image editor Canvas classes to Qt model/view

Brief explanation: Image Editor canvas classes are Qt3Support classes based on Q3ScrollView which will disappear with next Qt5. This class is used by digiKam Image editor to render lead editor canvas and some tools canvas as ColorCorrection, CurvesAdjust, LevelAdjust, etc. It must be ported to Qt4 model/view implementation using already existing common classes used in digiKam core.

Dependencies: digiKam core, Image Editor, Qt model view

Knowledge Prerequisite: C/C++, Qt, model/view

Expected results: implement image editor canvas to model/view

Difficulty: high

Lead Mentor: Islam Wazery <wazery at ubuntu dot com>

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

Project: Port Greystoration CImg interface to GMic

Brief explanation: digiKam include CImg library to be able to use Greystoration algortihm which give nice fix to image based on Vortex theory, as Restoration tool. Since CImg > 3.0.0, Greystoration algorithm have been move in a new library named GMic with a completely different API. The goal of this project is to adapt digiKam Greystoration interface to GMic library.

Dependencies: digiKam core, Retauration/Inpaint editor tools

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

Expected results: port image restoration algorithm from CImg to GMic API

Difficulty: high

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

Alternative Mentor: ???

Project: Video Metadata Support Improvements

Brief explanation: All recent digital-still camera devices provide video capture. digiKam must be able to manage these files as it do with images, to catalog and sort items (by date, camera name, and all record conditions). Through Exiv2 shared library improvement done at GSoC 2012, digiKam is now able to manage some video metadata from avi, divx, mkv, WebM, mp4, mov, 3gp, wmv, asf, but it lack some important video format metadata as MPEG and VOB used in video workflow. To improve video files support, video metadata management done in background need to be improved, to patch Exiv2 shared library, already used by digiKam to handle metadata.

Bugzilla entries: 164442

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

Expected results: Add missing video files support to Exiv2. Patch digiKam advanced search tool to handle video information.

Difficulty: high

Lead Mentor: Andreas Huggel <ahuggel at gmx dot net>

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

Project: Exiv2 "Cloud Ready" Project

Brief explanation:

Add web protocol support to Exiv2.

Exiv2 is a C++ library and a command line utility to manage image metadata. It provides fast and easy read and write access to the Exif, IPTC and XMP metadata of images in various formats. Exiv2 is available as free software and with a commercial license, and is used in many projects including DigiKam.

This project extends the reach of Exiv2 from the desktop and server to both mobile and the cloud. All Exiv2 clients – including DigiKam will gain from this development.

There are four subprojects:

  • HTTP I/O support (GSoC 2013 Student)
  • exiv2(.exe) to run as a service (daemon) on a web socket.
  • client-side use of the exiv2 service (using the web socket)
  • JSON support

The student is welcome to contribute to any part of the project. However the HTTP I/O Support will be "owned" by the student.

Exiv2 Project Web Site: http://www.exiv2.org

Cloud Ready Specification: http://dev.exiv2.org/projects/exiv2/wiki/GSoC_2013_%22Cloud_Ready%22_Project_Specification

Knowledge Prerequisites:

  • Essential: C++ on Linux
  • Desirable: Web Technologies. JavaScript, http protocol.
  • Desirable: WebSockets. JSON. Scripting Language (Python or Perl)

Expected results:

  1. To read and write metadata on a web URL (http/ftp/ssh)
  2. Test the implementation using the Exiv2 WebSocket Server
  3. An engineering assessment of providing support for other cloud services such as AWS and Dropbox.

Difficulty: High

Mentor: Robin Mills http://clanmills.com and http://clanmills.com/files/CV.pdf and [email protected] [[1]] [[2]] [[3]]

Robin has been a volunteer with Exiv2 project for 5 years and has provided build support for several platforms, and Visual Studio (MSVC) in particular. Via the Exiv2 Forum, he has provided support for many users wishing to build and integrate Exiv2 technology into their products.

Today, Robin is a freelance contractor in Silicon Valley, California and has recently worked on a mobile app which uses WebSockets. He has worked on client and server code in JavaScript and C++. Robin was a Senior Computer Scientist at Adobe for 10 years, and (among many projects) implemented reading PDF and JDF files over http (without copying the complete file).

Calligra Words

Project: Implement Change Tracking Backend

Brief explanation: Implement the change tracking backend (load,save,record, reject, accept). Implementing Ui and visualizing is _not_ part of the project.

Expected results: Fully working changetracking engine as far as the ODF 1.3 standard has evolved (which by now (feb.2013) is just insert and delete characters, but it will grow in scope). We also expect that you contribute to the development of the standard with feedback and suggestions. There needs to be documentation and unit tests as well.

Knowledge Prerequisite: C++, Qt, basic understanding of Operatonal Transform, basic understanding of the ODF spec, Well versed in the Calligra codebase with proven commitment

Mentor: Camilla Boemann you can calso contact us on irc #calligra

Project: Implement Change Tracking User Interface

Brief explanation: Implement the change tracking user interface (visualize changes, buttons). Implementing the backend is _not_ part of the project. A lot of the work will be to work together with the student getting the backend project

Expected results: Fully working changetracking user interface built on top of the backend. It needs to be completely polished with all details taken under consideration.

Knowledge Prerequisite: C++, Qt, usabillity and interaction design experience. Well versed in the Calligra codebase with proven commitment

Mentor: Camilla Boemann you can calso contact us on irc #calligra

KDE Telepathy

Project: Add ConnectionManager bindings to TpQt

Brief explanation: KDE Telepathy, the IM client, uses the backend library TelepathyQt to power everything. This library is also used by Nokia N9's, and soon Ubuntu's phones and much more.

The system consists of two parts; clients which display things to the user and connection managers which do the talking to the various IM servers.

We have library bindings for writing instant messaging clients in Qt, but not the backend connection manager to write protocol support in TpQt. This has been started, but a lot of work is needed to make this finished.

Currently this means the only way to write a connection manager, to a new provider is to use the glib bindings, which is a lot harder for us. We want to have these bindings so we can write our own connection managers to communicate with new services, such as Steam chat.

This will be a project in collaboration with the Telepathy project upstream at freedesktop.org.

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

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

Mentor: KTp GSOC ML Group

Project: Collaborative text editor powered by Telepathy Tubes

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

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

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

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

Mentor: KTp GSOC ML Group

Project: Finish KTp-Active

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

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

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

Knowledge Prerequisite: Qt, C++, advanced QML

Mentor: KTp GSOC ML Group

Marble

Project: Marble meets owncloud

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

Expected results:

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

And some possible extensions:

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

Knowledge Prerequisite: Qt, C++, Javascript

Mentor: earthwings at gentoo dot org


Krita

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

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

Project: Rewrite the OpenGL canvas mode

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

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

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

Project: Painting and Separation of 3D Textures

As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.

Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.

Project: Animation Support

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

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

Project: 3D Material Image Maps

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

  • Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.
  • When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.
  • In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).

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

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

Project: Matte painting

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

  • The ability for Krita to load manually selected sequences of color managed images as frames to be represented as a single layer in Krita. Optionally would be the ability to display playback at reduced resolutions to increase performance and to offset the time at which sequences were inserted.
  • A “Timeline” docker which would display the current frame displayed, and allow clicking and dragging to different points in time, updating the image displayed in the canvas to match. Optional would be the ability to zoom and scroll the timeline, mark modified frames on the timeline, playback the image sequence, forwards and backwards as video (most likely only in the openGL mode of Krita or with an external tool like ffplay) and display times in a range of formate EG SMTP, PAL, NTSC, Secam etc.
  • Updating the paint and transparency layer types, so that when Krita is using a frame sequence and one of these layer types is created, they also represent a series of frames rather than just a single image. This could possibly be a toggle switch on layers, much as visibility, alpha lock etc. are now.
  • The ability to save layers that are displaying frame sequences out as frame sequences also, giving them user definable names (eg where to insert the frame number, how many digits to pad).
  • Keyboard shortcuts to move forwards and backwards 1/10/100 frames, to jump to the start and end of the timeline and forward / backwards play if video playback is supported.

Project: Cartoon Text Balloon System

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

Kexi

Project: Improve stability and packaging of the MS Access driver

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

Expected results:

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

Knowledge Prerequisite: C, basic C++

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

KDE Workspaces

Project: Port plasmoids to plasma2

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

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

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

Mentor: Marco Martin <[email protected]>

Project: Port kde-workspace applications away from XLib

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

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

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

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

Project: KWin Effect Viewer

Brief explanation: With 4.9 KWin Effects can be written in JavaScript, but there is no convenient way to test the scripts. In this project a viewer application similar to plasmoidviewer should be developed. This could be achieved by using Xephyr and starting a dedicated KWin instance on the embedded X-Server which is just running the effect.

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

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Martin Gräßlin

Project: Present Windows/Desktop Grid rewrite in QML

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

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

Knowledge Prerequisite: QML, QAbstractItemModel and QSortFilterProxyModel

Mentor: Martin Gräßlin

Project: Improved KWin effects configuration

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

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

Knowledge prerequisite: QML, usability experience

Mentor: Martin Gräßlin

Project: Integrate Android with the Workspace and vice versa

Brief explanation: Provide a tight integration between the Android platform and our's by making things like Android Notifications be shown in our Workspaces. Expected results: Android platform should integrate seamlesss with KDE's using some kind of connectivity (p2p if possible and going trhough the cloud when not). Knowledge prerequisite: Java, C++/Qt

Mentor: Àlex Fiestas

KDE Games

About KDE games: http://games.kde.org/

Project: Port a KDE game to QtQuick/QML

Brief explanation: QtQuick is the new (well not so new anymore) library for creating user interfaces very quickly with the easy-to-code Qt's declarative language QML. All of our games use the legacy C++ QGraphicsView library to paint the game frontend, aka, the canvas (except KBreakout and few others in the works). Writing UIs in QML is much easier and simpler than the QGraphicsView counterpart. This project is about porting the game canvas of any one of the existing games to QtQuick, keeping the backend code as intact as possible.

Expected results: Port one game completely to QtQuick to display the game canvas using QML. Additional animations over and above that in the original game would be a plus, since QtQuick provides rich and easy-to-use animation capabilities.

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

Mentor: Viranch Mehta <[email protected]>

Trojitá

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

Project: Add support for secure messaging to Trojitá

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

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

Knowledge Prerequisites: Decent knowledge of C++ programming, familiarity with Qt, willingness to use GPG.

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

Project: Android version of Trojitá

Brief explanation: The primary platform which sees most development and takes most attention is the regular desktop, but there is an existing port to MeeGo Harmattan with some limited functionality. This project is about porting that to Andorid and extending the functionality so that the features offered by the mobile port make it possible to effectively work with e-mail on that platform.

Expected results: An Andorid version of Trojitá (with Harmattan backports, if feasible) supporting other features already found in the desktop version -- composing and sending e-mails, searching them, filtering, threading etc.

Knowledge Prerequisities: Candidates shall be fluent in QML and have some Qt/C++ experience.

Project: Integrating Trojitá with KDE's Kontact

Brief explanation: Trojitá a pure Qt application with no KDE dependency. It would be great to add optional integration with the KDE's PIM tools, so that it will work as a part of the Kontact suite, be able to read the KDE's addresbook etc.

Expected results: Make a variant of Trojita which will act as a drop-in replacement for KMail (at least from the user's point of view).

Knowledge Prerequisities: Decent knowledge of C++ programming, familiarity with Qt, lack of alergy towards KDE's classes.

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