GSoC/2016/Ideas

GSoC 2016 logo

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

Your Own Idea

Project: Something that you're totally excited about

Brief explanation: Do you have an awesome idea you want to work on with KDE but that is not among the ideas below? That's cool. We love that! But please do us a favor: Get in touch with a mentor early on and make sure your project is realistic and within the scope of KDE. That will spare you and us a lot of frustration.

Expected results: Something you and KDE loves

Knowledge Prerequisite: Probably C++ and Qt but depends on your project

Mentor: Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Freenode IRC.

Calamares

Calamares is a distribution-independent installer framework (code).

Calamares is participating to Google Summer of Code with KDE as umbrella organization. We are a young project, we are developing quickly, we are working with state of the art technologies (C++11, Qt 5, KDE Frameworks 5, Boost.Python) and we are solving exciting problems.

Calamares is already shipped or is about to be shipped as the default system installer for several Linux distributions, including KaOS, BBQLinux, Fedora KDE, Manjaro, Netrunner Rolling, OpenMandriva, Tanglu, and others.

See this post for instructions on how to structure your Google Summer of Code proposal for Calamares.

Project: Python interface refactor + Python view modules

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Installer pages are also provided by Calamares modules. These modules can currently be written in C++11 (as Qt plugins) or Python. The Python interface *works*, but it is slightly different from the C++ one, and it only supports jobs, not installer pages. This Google Summer of Code project is one of several that start with the same initial subtask, and then branch out in different directions.

0) Refactor the Python interface so that writing a job module is not just implementing a function that expects globals, but rather inheriting from Calamares::Job or a wrapper thereof. Port all the Python modules to this updated interface. PythonQt 3.0 has just been released with support for Qt 5, so this is an option too, as a replacement for Boost.Python. The student should investigate all alternatives, consult with the mentor and propose a design.

1) Further improve the Python interface to allow writing view modules (i.e. installer pages) in Python. The student should do some research on the strengths and weaknesses of different approaches and produce a detailed action plan on what to wrap, how to wrap it, and which technologies to use to achieve said goals.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python and C++ module interfaces, for both job modules and view modules.

Knowledge Prerequisite: At least some C++ experience is required; experience with CMake, Python, Boost.Python and other language binding solutions (PyQt, SWIG...) is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode

Project: Python interface refactor + Ruby modules interface

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Installer pages are also provided by Calamares modules. These modules can currently be written in C++11 (as Qt plugins) or Python. The Python interface *works*, but it is slightly different from the C++ one, and it only supports jobs, not installer pages. This Google Summer of Code project is one of several that start with the same initial subtask, and then branch out in different directions.

0) Refactor the Python interface so that writing a job module is not just implementing a function that expects globals, but rather inheriting from Calamares::Job or a wrapper thereof. Port all the Python modules to this updated interface. PythonQt 3.0 has just been released with support for Qt 5, so this is an option too, as a replacement for Boost.Python. The student should investigate all alternatives, consult with the mentor and propose a design.

1) After completing subtask 0 for Python modules, achieve the same level of support for Ruby. The student should research technologies such as SWIG, RubyInline, FFI and Rice and produce a detailed action plan on how to deliver a Ruby interface for Calamares job modules. The latter (Rice) seems to be the most promising for the kind of embedding we need and most similar to Boost.Python, but this must be further ascertained. Packaging and deployment should also be taken into account.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python, Ruby and C++ job module interfaces.

Knowledge Prerequisite: At least some C++ experience is required; experience with CMake, Ruby, Python, Boost.Python and other language binding solutions (PyQt, SWIG...) is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode; Rohan Garg <[email protected]>, shadeslayer on Freenode

Project: Python interface refactor + Python testing mechanism

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Installer pages are also provided by Calamares modules. These modules can currently be written in C++11 (as Qt plugins) or Python. The Python interface *works*, but it is slightly different from the C++ one, and it only supports jobs, not installer pages. This Google Summer of Code project is one of several that start with the same initial subtask, and then branch out in different directions.

0) Refactor the Python interface so that writing a job module is not just implementing a function that expects globals, but rather inheriting from Calamares::Job or a wrapper thereof. Port all the Python modules to this updated interface. PythonQt 3.0 has just been released with support for Qt 5, so this is an option too, as a replacement for Boost.Python. The student should investigate all alternatives, consult with the mentor and propose a design.

1) Our Python testing facilities are currently limited to a single script (src/modules/testmodule.py). The student should present an action plan for a more comprehensive testing mechanism, which may or may not be based on testmodule.py, and may or may not involve libcalamares instead. This testing mechanism could further be integrated with our Jenkins continuous integration system.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python and C++ job module interfaces, and a comprehensive testing mechanism for Python job modules.

Knowledge Prerequisite: At least some C++ and Python experience is required; experience with CMake, Boost.Python and software testing is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode

Project: Debian installer support

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Some of these modules are common for most Linux distributions, and some might be heavily distribution-specific.

Calamares is already capable of installing a Debian-based system, simply by unpacking a squashfs image like most other distributions, but this is less than ideal: Debian already provides a sophisticated install system (debian-installer), and Calamares should take advantage of it.

The student should propose a detailed action plan, with the ultimate deliverable being one or more job modules that implement a system install procedure based on debian-installer. Additional changes to the user interface (view modules) may or may not be needed for this, depending on the feature set proposed by the student. From a top-down point of view, Calamares should behave like a debian-installer frontend, not unlike Ubiquity, but without compromising its distribution-agnostic design.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Expected results: Calamares should be able to install a Debian based system using debian-installer as backend.

Knowledge Prerequisite: The student should have experience with a Debian based distribution and C++; experience with Python, debian-installer and Debian packaging is a plus.

Mentors: Rohan Garg <[email protected]>, shadeslayer on Freenode; Teo Mrnjavac <[email protected]>, teo- on Freenode; Jonathan Riddell <[email protected]>, Riddell on Freenode

Project: LVM and LUKS support

Brief explanation: KPMcore (the library used as a partitioning backend in Calamares and KDE Partition Manager) currently only has very basic support for opening/closing LUKS volumes. Full LUKS support is needed, with all operations exposed in an interface, and this then needs to be used in Partition Manager and Calamares. LVM support should also be researched and added to Calamares.

A work in progress of this task is available in the luks-decorator branch of KPMcore. Depending on schduling, it could also happen that the LUKS feature is implemented by someone else outside of GSoC, in that case the prospective student should rather plan for LVM and RAID features. Btrfs subvolumes is also a feature to consider.

The student should propose a detailed action plan, with the ultimate deliverable being full LVM and LUKS (or RAID) support in Calamares and KDE Partition Manager. Intermediate deliverables must be listed in the proposal, with as much granularity as possible. If LUKS support is already in place, the student should immediately focus on LVM and possibly RAID.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Expected results: Calamares should be able to install a system on one or more LVM and/or LUKS volumes, and both Calamares and KDE Partition Manager should offer a full set of LVM and LUKS operations to the user.

Knowledge Prerequisite: The student should have experience with Qt and C++. Previous experience with partitioning application development is a plus.

Mentors: Teo Mrnjavac <[email protected]>, teo- on Freenode; Andrius Štikonas, stikonas on Freenode

digiKam

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

• digiKam project web site
• Exiv2 project web site
• digiKam port to KF5 status
• Mailinglist
• Google+ page
• #digikam IRC channel on Freenode

Project: digiKam MySQL / MariaDB Database support

Brief Explanation: Since a while, the MySQL database support in digiKam was not completed and unfinalized. The digiKam database interface is modular and new kind of database type can be added. Currently Sqlite support work fine since a while, but it’s limited to a local storage with a single user. SQlite is not adapted to be used in photo agency workflow where more than one digiKam need to access to a remote and common database storage located on a remote server. This typical use case can be resolved by using MySQL/MariaDB database.

Expected results:

• Review current whole database implementation including database schema hosted as XML.
• Review current dysfunctions and missing features in database interface and schema.
• Review of all use cases in photo agency with a centralized database storage.
• Implement/Rewrite code/schema for MySQL support and MariaDB.
• Write unit tests for database interface and documentation.

Knowledge Prerequisite:

• Database, MySQL/MariaDB, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Marcel Weisweg

Project: digiKam MetadataHub improvements

Brief Explanation: while GSoC 2015, a new metadata wrapper have been introduced to digiKam core. This one work as a hub between image metadata and database. The user can route which kind of metadata can be used to populate the database by priority order when items are parsed. In inverse way, the hub will define which image metadata will be populated by digiKam database when user will synchronize images. At previous GSoC, a low level hub have been implemented with a configurable graphical interface. Only few metadata types are currently supported as rating comment and tags. The goal of this project is to implement more metadata types in the hub rules, as GPS info, tags from proprietary photo management software, Copyrights, etc...

Expected results:

• Review current whole metadata hub implementation including current metadata rules supported.
• Review all missing cases to wrap metadata with database and vis versa (bugzilla include a lots of uses cases reported by end users).
• Implement new low level rules in hub with relevant settings in configuration panel.
• Write unit tests for metadata hub and documentation.

Knowledge Prerequisite: Metadata, database, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Marcel Weisweg

Project: digiKam automatic Red Eyes detection and correction

Brief Explanation: digiKam include a basic tool to fix red eyes in image editor. there is no automatic mode (detection and fix). The goal of this project is to review code write a low level code to detect and fix red eyes automatically, and include this tool in image editor and Batch Queue Manager. The tool must be able to support 8/16 bits color depth images and must be multi-threaded on multi-core CPU.

Expected results:

• Review current code from older RedEyes Removal kipi tool which include some interesting algorithms.
• Check all features required by the tool in all use cases. Select best algorithm (OpenCV).
• Implement low level filter for red eyes detection and fix.
• Implement GUI and integration into image editor and BQM.
• Write unit tests and documentation.

Knowledge Prerequisite:

• Image processing, OpenCV, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Maik Qualmann

Project: digiKam database export to DLNA/UPNP

Brief Explanation: In the past, Kipi-plugins provide a way to export KIPI host data to DLNA/UPNP by a plugin using HUpnp library for Qt. Since Qt5 port this tool do not work anymore as HUpnp project is dead and code is not ported to Qt5, even if we have tested some implementation from GitHub ported to Qt5. The goal of this project is to find a new way to restore this feature in digiKam core directly (not as a plugin), using a suitable solution to support UPNP/DLNA in the long term.

Expected results:

• Review old plugin code DLNAExport. Review all required features to export digiKam contents through a DLNA server.
• Implement a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server must have the capability to be restored at each digiKam session.
• Implement the server configuration panel in digiKam setup.
• Test the new implementation with DLNA compliant devices, as smartphones, tablets, TVs.
• Write unit tests and documentation.

Knowledge Prerequisite:

• DLNA/UPNP, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Maik Qualmann

KDE Edu

Gcompris

Project: Add educational activities to GCompris (In Qt Quick)

Brief explanation: GCompris is a an educational software suite comprising of numerous activities for children aged 2 to 10. Originally written in Gtk+ it's development team started to rewrite it from scratch in Qt Quick.

Expected results:

• Porting remainings activities from the Gtk+ version to Qt Quick. You can find missing activities to port that will help you select the activity set you are interested in (tasks start with ”Port of Gtk+”).
• Creating new activities. There is a list of ideas of activities that have been identified as something we would like to have. You can also propose original ideas not on the list.
• Adding core features
• Refining current activities: some can be improved, whether improving the animation, adding sounds, tutorials...

Knowledge Prerequisite: By the start of GSoC you should Be interested in children’s education Be familiar with GCompris concept and content Basic knowledge in a programming language (a 1 year school course is enough) Be able to build the Qt Quick version of GCompris

Application guide: Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphics and the sounds are already available. You can count at least 2 weeks of development for an activity. To keep the work interesting it is recommended to propose a mix of porting some activities and creating new one, either from the idea list or from an original idea you come with. You have to follow the instructions here and provide your exercise as a pull request.

Feel free to contact us either on irc or by mail ([email protected])

Mentors: Bruno Coudoin (IRC: bdoin #gcompris on freenode), Johnny Jazeix (IRC: JohnnyJ), Bharath M S (IRC: brat197), Sagar Chand Agarwal (IRC: sagaragarwal94)

Minuet (Software for Music Education)

Minuet will become part of KDE-edu suite of educational applications in version 16.04 and aims at supporting students and teachers in many aspects of music education, such as ear training, first-sight reading, solfa, scales, rhythm, harmony, and improvisation. Minuet makes extensive use of MIDI capabilities to provide a full-fledged set of features regarding volume, tempo, and pitch changes, which makes Minuet a valuable tool for both novice and experienced musicians. Minuet features a rich set of ear training exercises and new ones can be seamlessly added in order to extend its functionalities and adapt it to several music education contexts.

Additional Information:

• Website (minuet.kde.org)
• Blog posts
• (watch in HD) Demonstration video
• IRC channel: #kde-edu
• Mailing list
• Contact: sandroandrade AT kde DOT org

Project: Student’s Performance Metrics and Flexible Exams

Brief explanation: Minuet currently provides a set of exercises for some aspects of music education. Such exercises are defined in JSON files, which indicate the available answers for a given exercise category and how to play each answer. Users are able to choose an exercise and execute it many times, getting a 'correct' or 'wrong' result in each attempt. This project aims at implementing a flexible mechanism for defining customized exams and gather some performance metrics after finishing the evaluation. Some mechanism for storing answers and, potentially, sending them to the teacher afterwards is also expected.

Expected results:

• Implementation of a flexible mechanism for customizing exams.
• Implementation of a set of performance metrics (hit rate, average answer time, etc).
• Implementation of a mechanism for storing and sending answers to the teacher.

Knowledge Prerequisite:

• C++/Qt/QML.
• No music background required.

Mentor: Sandro Andrade (IRC: sandroandrade)

Project: Minuet Mobile

Brief explanation: Minuet has reached a stable status in Linux but having it running in mobile platforms like Android is of paramount importance. This project aims at implementing a functional version of Minuet for Android platform. That requires investigate the use of MIDI capabilities in Android and check whether the current ALSA-based solution currently adopted in Linux can be reused. Also, a proper MIDI backend (akin to TiMidity++/Freepats) for Android should be devised. Another possible path, is to get rid of MIDI capabilities and built the playing features upon another sort of technology.

Expected results:

• A working version of Minuet for Android, featuring the basic exercises presented in its Linux version.

Knowledge Prerequisite:

• Android development.
• C++/Qt/QML/Material Design.
• MIDI/ALSA.

Mentor: Sandro Andrade (IRC: sandroandrade)

Project: Singing and Clapping Capabilities

Brief explanation: current Minuet human-interaction mechanism comes down to the use of mouse clicks to point out the answer for a given ear training exercise. Obviously, singers and drummers/percussionists wouldn't have any valuable benefit of using Minuet unless it provides some mechanism to get exercises' answer from singing and clapping data captured from a computer-connected microphone. This project aims at implementing the features for recognizing pitch from voice data and hits from clapping data, both acquired from the computer microphone.

Expected results:

• A reliable (to some extent) mechanism for detecting pitch from voice data.
• A reliable mechanism for detecting clapping from audio data.
• Both mechanisms may require calibration.

Knowledge Prerequisite:

• C++/Qt/QML.
• Digital Signal Processing.

Mentor: Sandro Andrade (IRC: sandroandrade)

Project: Multiple-Instrument View Framework

Brief explanation: Minuet is currently able to visually represent intervals, chords, and scales only on the piano keyboard. Supporting other musical instruments, with the accurate handling of their particular idiosyncrasies, is a feature of paramount importance. Aspects such as fingering and execution techniques are highly dependent on which musical instrument they were created to. A flexible architecture should be designed to allow the seamless integration of new musical instruments as Minuet plugins. Minuet's core should not only provide all information generally required by all musical instruments, but also support the handling of instrument-specific information, when available.

Expected results:

• Design and implementation of a multiple-instrument visualization framework.
• Refactoring of piano keyboard view as a framework plugin.
• Implementation of a framework plugin for a new instrument (e.g. guitar or bass).

Knowledge Prerequisite:

• C++/Qt/QML.
• Minimal music background for a instrument other than the piano.

Mentor: Sandro Andrade (IRC: sandroandrade)

LabPlot

LabPlot: application for interactive graphing and analysis of scientific data.

Project: add support for the FITS format

Brief Explanation: FITS is an open standard widely used in the astronomy: https://en.wikipedia.org/wiki/FITS Currently LabPlot lacks any support for this format. The goal of this project is to add the support for this project and to provide basic editing and navigation features similar to those available in e.g. FITS Liberator (https://en.wikipedia.org/wiki/FITS_Liberator) or other similar programs. Have a look at the handling of FITS in kstars and investigate how much of kstar’s code and ideas can be used in LabPlot.

Expected results:

• Use NASA’s libcfitiso to add the support for this format
• Import datasets and images from FITS like it is currently possible for other supported formats (assii, binary, netCDF, HDF5)
• Write documentation

Knowledge Prerequisite: C++, Qt

Mentor: Stefan Gerlach ([email protected])

Project: extend the 3D-plotting part

Brief Explanation: During GSoC2015 basic 3D-functionality was added to LabPlot. This part needs to be extended, core features needs to be finalized and prepared for a release. The summary of what was already achieved can be found here https://minh.fedorapeople.org/2015/08/21/gsoc-last-report.html

Expected results:

• Finalize the plotting of points, curves and surfaces in 3D based on the already existing infrastructure and features in the code
• Write documentation

Knowledge Prerequisite:

• C++, Qt, VTK

Mentor: Alexander Semke ([email protected])

Project: import data from SQL-databases

Brief Explanation: Currently, the data can only be imported from external files. The goal of the project is to add the ability to import from SQL-databases.

Expected results:

• Implement a “connection manager” to create and to store connections to different SQL-databases
• In the sql-import dialog provide features to define which columns to import and with wich filters
• Alternatively, the user should be able to select the data via a SELECT-statement. For this a text editor with syntax highlighting and code completion for SQL should be added.
• Import from a database to LabPlot’s spreadsheet should be done similar to the import from external files
• Write documentation

Knowledge Prerequisite:

• C++, Qt, basic SQL and QtSql knowledge

Mentor: Alexander Semke ([email protected])

Project: theme manager for plots

Brief Explanation: LabPlot provides many features for editing the appearance of the plot. Though it is helpful in many cases to modify the appearance in great detail, it is also useful to have a set of predefined themes like “black curves on white background”, “white curves on black background”. With the help of such themes the user should be able to achieve nice looking results more easily.

Expected results:

• Implement a theme manager: it should be possible to save the current appearance as a new theme and to load one of the already saved theme
• Provide couple of nice themes that will be delivered with the application
• Add support for KDE’s “Get Hot New Stuff”
• Write documentation

Knowledge Prerequisite:

• C++, Qt, some taste for good looking plots

Mentor: Alexander Semke ([email protected])

Artikulate

Project: Create Artikulate on Android App

Brief explanation: Artikulate is a pronunciation trainer that helps improving and perfecting a learner's pronunciation skills for a foreign language. It is currently a desktop application consisting of a trainer and an editor. In this project, you create an Android application for the trainer part.

Expected results:

• Port application to be built on Android devices (most groundwork already finished regarding the libraries and cross-compile toolchain)
• Create new app layout (inspired and similar to the desktop one's) that fits to mobile devices; have a look at Subsurface, the KDE HIG for mobile devices, Marble Maps and the Kirigami project for inspirations
• At the end of GSoC, the app should work fine at the phone \o/

Knowledge Prerequisite: By the start of GSoC you should

• Good knowledge of C++/Qt/QtQuick (moderate knowledge of QtQuick is fine, but you have to learn it on the way then)
• Be interested in language learning
• Be interested in app development for Android
• I want to see your previous work (e.g., commits to KDE projects, your GitHub page,...) that justify your knowledge asserts

Mentors: Andreas Cord-Landwehr ([email protected])

Cantor

Cantor is a KDE Application aimed to provide a nice Interface for doing Mathematics and Scientific Computing. It doesn't implement its own Computation Logic, but instead is built around different Backends. It offers assistant dialogs for common tasks and allows you to share your worksheets with others.

Ten backends are curently available: KAlgebra, Lua, Maxima, Octave, Python 2 and 3, Qalculate, R, Sage, and Scilab.

Project: Backend for Julia

Brief explanation: This project aims to add support for Julia in Cantor. The support must to implement the basic features of other Cantor backends: syntax highlithing, tab-complete, variable management, support to show plot figures in the worksheet, support to some extensions like linear algebra and plot generation, and more.

Expected results: A backend for Julia.

Knowledge Prerequisite: C++, Qt, and some inter-process communication technology

Mentor: Filipe Saraiva (filipe at kde.org)

KDE Partition Manager

Project: LVM and LUKS support

Brief explanation: KPMcore (the library used as a partitioning backend in Calamares and KDE Partition Manager) currently only has very basic support for opening/closing LUKS volumes. Full LUKS support is needed, with all operations exposed in an interface, and this then needs to be used in Partition Manager and Calamares. LVM support should also be researched and added to Calamares.

A work in progress of this task is available in the luks-decorator branch of KPMcore. Depending on schduling, it could also happen that the LUKS feature is implemented by someone else outside of GSoC, in that case the prospective student should rather plan for LVM and RAID features. Btrfs subvolumes is also a feature to consider.

The student should propose a detailed action plan, with the ultimate deliverable being full LVM and LUKS (or RAID) support in Calamares and KDE Partition Manager. Intermediate deliverables must be listed in the proposal, with as much granularity as possible. If LUKS support is already in place, the student should immediately focus on LVM and possibly RAID.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Expected results: Calamares should be able to install a system on one or more LVM and/or LUKS volumes, and both Calamares and KDE Partition Manager should offer a full set of LVM and LUKS operations to the user.

Knowledge Prerequisite: The student should have experience with Qt and C++. Previous experience with partitioning application development is a plus.

Mentors: Teo Mrnjavac <[email protected]>, teo- on Freenode; Andrius Štikonas, stikonas on Freenode

KDE Utils

Ark

Ark is an advanced archive manager, well integrated with KDE technologies.

Additional Information:

• IRC channel: #kde-utils
• Phabricator project: https://phabricator.kde.org/project/view/46/
• Mailing list: https://mail.kde.org/mailman/listinfo/kde-utils-devel
• Contact: [email protected]

Project: Implement advanced editing of archives

Brief explanation: Ark currently provides basic support for archives editing. It can add/delete files to/from an archive and it can also update the content of an existing file in the archive. However advanced editing features are not yet supported:

• it’s not possible to add new files in a given subfolder of an archive
• it’s not possible to move or rename an entry (file or directory) in the archive
• it’s not possible to copy an entry in an archive to another subfolder of the archive

In order to implement the features above, the student will start with a deep refactoring of the ArchiveModel class and the ArchiveNode/ArchiveDirNode hierarchy.

In the second step, the requested features can be implemented by starting from this patch (which only partially covers the rename feature): https://git.reviewboard.kde.org/r/120337/

The student is also expected to write documentation and unit tests for both the refactored code and the new features introduced.

Expected results:

• Ark can move, rename or copy entries within an archive
• Ark can create new files in any subfolder of an archive

Knowledge Prerequisite:

• C++, Qt
• Knowledge of the Model-View-Controller pattern is a nice bonus.

Mentor: Elvis Angelaccio (IRC: elvisangelaccio on #kde-utils)

Project: implement extraction to remote destinations

Brief explanation: Ark is well integrated with many KDE technologies, but the KIO slave system is not one of them. Ark can currently extract archives only to local destinations. This is due to design limitations or just a lacking implementation:

• For CLI-based plugins (e.g. zip or rar archives), Ark currently changes the working directory to

the destination selected by the user for the extraction. Then it executes the underlying CLI tool (e.g. unzip or unrar) to perform the actual extraction of the archive. This is a design flaw because we cannot change the working directory to a remote destination.

• For libarchive-based archives (e.g. tar or rpm archives), the student just needs to implement KIO

support in the libarchive plugin.

The tricky part is about the CLI-based plugins. The student is required to redesign the way the cliplugins are handled by Ark:

• The plugins must be used in a non-interactive way. The student will have to adapt the existing cli

plugins which are currently used in an interactive way. See this task (and the linked patch) for more details: https://phabricator.kde.org/T1686

• The extraction must be performed in a temporary directory so that we can use the KIO api to move

the unpacked files to the remote destination. This is the simplest possible implementation, but more efficient alternatives can be explored and tested by the student.

Expected results: Ark can extract any kind of archive to a remote destination such as ftp://

Knowledge Prerequisite:

• C++, Qt
• Knowledge of the KIO and libarchive api is not required, but is a bonus point

Mentor: Elvis Angelaccio (IRC: elvisangelaccio on #kde-utils)

KDevelop

Project: KDevelop: LLDB Support

Brief explanation: Write a new plugin to support LLDB on KDevelop

Come up with a new kdevelop plugin so that LLDB can be used as a debugging solution, especially on Mac OS X and Windows, where gdb support is rather scarce. Bonus points for making sure your plugins works on other platforms than Linux, i.e. Windows and OS X.

Expected results: LLDB support in similar feature-completeness as KDevelop’s GDB support

Knowledge Prerequisite: C, C++, GDB/LLDB, Qt, debugging intrinsic problems

Mentor: KDevelop Team, Kevin Funk <[email protected]>

Project: KDevelop: Compiler Kits

Brief explanation: Extend KDevelop in a way it can help users select their intended compilers/Qt versions/debugger versions, etc. Let’s face it, we want something very similar to what QtCreator offers: http://doc.qt.io/qtcreator/creator-targets.html This should be especially pave our way on Windows, where we currently cannot select a Visual Studio or MinGW compiler environment from within KDevelop. Bonus points for making sure this all works super smooth on other platforms than Linux, i.e. Windows and OS X

Expected results: Compiler selection / Qt version selection / Debugger selection/ Kit selection features

Knowledge Prerequisite: C, C++, Qt, software architecture

Mentor: KDevelop Team, Kevin Funk <[email protected]>, Milian Wolff <[email protected]>

Project: KDevelop: Improve QML/JS integration

Brief explanation: Extend the QML/JS plugin we started a while ago, cf. http://steckdenis.be/post-2014-08-18-google-summer-of-code-2014-qmljavascript-language-support-for-kdevelop-4-and-5.html We’d like to extend it as much as possible, including the following features: Be able to specific import paths for QML plugins Proper handling of QRC imports Add navigation capabilities to import statements Integrate https://www.kdab.com/kdab-contributions-qt-5-4-qmllint/ Probably many more which I cannot think of right now

Expected results: All above bullet points resolved, and probably more

Knowledge Prerequisite: C, C++, Qt, QML/JS

Mentor: KDevelop Team, Milian Wolff <[email protected]>

Project: KDevelop: Enhanced support for working with microcontrollers

Brief explanation: List of things I can think about which would maybe be useful (feel free to add more / remove the ones you don’t think are useful): First of all, a controller-specific debugger would be cool. As the debugger backend, you usually use gdb; but what commercial IDEs do and which is really nice is having a tool view which allows to inspect the controller's hardware registers without typing all the addresses, in a kind of table. The addresses and structs could probably be parsed out of the headers in the project, using some simple heuristics. In the debugger, somewhere display the current stack pointer and program counter, and maybe stack size. Maybe allow launching a debug server with openocd. An action to reset the chip (can usually be done through gdb). An action to program the chip (can be done through gdb but might also be an external script). It would be good to have this as a possible item in the "build" dependency chain. This probably arcs over into Aleix’ "deployment infrastructure" plans. Would be nice to have some working templates for some common chips. "Implement function" for (undeclared?) extern functions, maybe needs to look at __attribute__(weak) and similar nonstandard C stuff Sometimes it would be nice to display the absolute memory address of a struct member for structs in the tooltip, if the struct instance has a compile-time-known location. There seem to be a few general issues with C support in KDevelop (files not highlighted at all, …). This needs to be investigated a bit, but you can certainly get help on the clang part (if necessary) from knowledgeable people in the KDevelop team. Many C functions have lots of parameters. Maybe one could display the parameter name when moving the mouse over the argument which is passed in? That'd also be nice for cpp sometimes. Completion support for C's Foo foo = { .member = value } syntax Maybe there's an easy way to find out how much space a function's code takes up in flash memory? Eventually we can build code in the shipped templates with cmake? I think there are toolchain files for e.g. armv7 cross compilation etc Think about how we can handle / provide / support the vendor’s “standard libraries” for the controller(s) Think about how we can maybe at least ship a set of .ld files for common chips (certainly we can borrow those somewhere?)

Expected results: Get to a point where people consider using KDevelop to develop their microcontroller firmware, maybe limited to a certain controller family in the beginning if the scope proves too broad (I’d suggest the stm32 family and related chips). You do not have to implement all the points above, that is just a list of ideas. The goal is to get to a point where there is some kind of usable workflow which provides benefits over what other IDEs do (which should not be too difficult, since a very good basis for C language support is already in place, far superior to what most competing IDEs for this scope I have seen so far can offer).

Knowledge Prerequisite: C, C++, a bit of Qt; you definitely need some prior experience in microcontroller programming to do useful work on this and you definitely need some hardware at home as well for testing (e.g. some STM32 demo board+JTAG debugger)

Mentor: KDevelop Team, Sven Brauch <mail at svenbrauch dot de>

Project: KDevelop: Go language integration

Brief explanation: Come up with a plugin to integrate Google’s Go language We’re very open for ideas here, this is more or less a R&D topic. Go is becoming more and more popular, and KDevelop might be a good candidate for a superb IDE for Go. Support for Go language using one of the existing language parsers Use of a custom parser is discouraged Debugger integration https://golang.org/doc/gdb, or https://blog.cloudflare.com/go-has-a-debugger-and-its-awesome/ … the proposal counts! Note there’s an existing KDevelop Go plugin here (unfortunately using a custom parser which we’d like to avoid if possible): https://quickgit.kde.org/?p=kdev-go.git More information here: http://comments.gmane.org/gmane.comp.kde.devel.kdevelop/42874

Expected results: Go language support, and some kind of debugger integration for Go

Knowledge Prerequisite: C, C++, Qt, Go

Mentor: KDevelop Team, Kevin Funk <[email protected]>

Keyboard Layouts

Keyboard layouts in KDE software allow user to use multiple keyboard layouts and switch between them. It consists of keyboard configuration module (in System Settings), keyboard layout widget/applet, and keyboard layout daemon.

Project: Automatic layout switching based on text input context

Brief explanation: Currently when user switches to the input field he always have to switch keyboard layout. Remembering last layout per application window helps a bit but even the same window may have different languages to accept. It would be nice if we can use the context of the text input to try to switch layout automatically. E.g. if user enters text in a text box which already has some text, or has some text in different language on a webPage, user can just select the text and the keyboard module will automatically detect the language of the text and change the layout.

Note: this might be not a short term project but we could lay out some foundation in GSOC.

Expected results: There is a lot of research in this feature.

Primary Results:

We need to equip keyboard layout with language detection, so that we can detect the language of the input text which is passed by the context and change the layout accordingly.

Secondary Results:

What information about the language we can extract, which additional options we need (e.g. automatic choice might work poorly in some environments so we might need to let user disable it for some applications/windows etc), also if automatic choice was made and user had to switch manually to correct we may try to remember that and adjust the automatic switching accordingly next time. If we can have good description of potential contexts, their language tags, and some code to detect those contexts and languages that would be a good result for this project. If we can do more that would be fantastic.

Knowledge Prerequisite: C++ and Qt.

Mentor: Shivam Makkar <[email protected]>

Kopete

Kopete is an instant messenger supporting AIM, Bonjour, Gadu-Gadu, GroupWise, ICQ, Jabber (XMPP, Google Talk, Facebook, ...), Meanwhile, QQ, Skype, Windows Live Messenger, WinPopup, Yahoo and more. It is designed to be a flexible and extensible multi-protocol system suitable for personal and enterprise use.

Mailing list: [email protected] (archive at: lists.kde.org or gmane.org)

Project: Jabber message archive

Brief explanation: When you use more jabber clients and you want to have full chat history in all clients, you need to synchronize message history between all clients. To make it easier for different jabber clients, there is jabber protocol extension for storing history directly on jabber servers which allows clients to download (missing) messages:

XEP-0136: Message Archiving

XEP-0313: Message Archive Management

Expected results: Working support for XEP-0136 or XEP-0313

Knowledge Prerequisite: C++/Qt, Jabber protocol

Mentor: Pali Rohár <[email protected]>, Pali on #kopete

Project: IRC protocol

Brief explanation: Kopete KDE3 version had plugin for IRC protocol. Porting that IRC plugin to new KDE versions was never finished and Kopete does not have working support for IRC yet.

Expected results: Restore IRC protocol into Kopete

Knowledge Prerequisite: C++/Qt, IRC protocol

Mentor: Pali Rohár <[email protected]>, Pali on #kopete

Project: Chat history improvements

Brief explanation: Kopete can archive chat history via built-in plugin. There are more plugins which implement such archive functionality and use different storages. There are also problems with API how chat history is used... This project is for improving status of chat history in Kopete.

Expected results: Come up with idea 1) what to store from chat session 2) how to store it 3) where to store it and 4) how to provide chat history to user. Part of result is of course full implementation and ideally also conversion from current history plugins.

Knowledge Prerequisite: C++/Qt, some knowledge of storing chat history

Mentor: Pali Rohár <[email protected]>, Pali on #kopete

Note: Part of GSoC proposal must be ideas or solutions to these problems. I suggest to read mailing list discussion from last year.

Krita

Krita: digital painting for artists. It support creating images from scratch from begin to end. Krita is a complex application and developers need to have a fair amount of experience in order to be able to do something.

Krita is a widely used digital painting application for professional artists. Last year, Krita gained the ability to create hand-drawn 2D animations, among other new features. For this year, projects that the Krita team would be interested in include:

Project: Extending Animation Support with masks and curves

Brief Explanation: We want the animation support extended by allowing users to place masks (filter masks, transformation masks, transparency masks) on the timeline and animate their properties using curves. Every property of a layer or mask placed on the timeline should be animatable.

Expected results:

• Implementation of a generic curve editing widget that can be reused in other places
• Implementation of a gui for applying the curve settings to one or more properties of a mask or layer
• Implementation of the actual rendering of the properties in the frames

Knowledge Prerequisite:

• C++ and Qt

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk_log)

Project: Soft-proofing and other color management improvements

Brief Explanation: Color management lies at the core of Krita. All images, all display functions, all color selectors are color managed in Krita. What is missing is soft-proofing: displaying which colors are out-of-gamut for the intended target device. This is needed so the user can make informed color choices. Krita is also unique in allowing users to paint in HDR color spaces, which offers additional gamut and clamping problems, both when painting and in the color selectors.

Expected Results:

• A working soft-proofing implementation for both the OpenGL and CPU canvas.
• Gamut-warnings in all color selectors
• Warnings when clamping when using floating point color spaces.

Knowledge Prerequisite:

• C++, Qt, LCMS, Color theory

Mentor: Boudewijn Rempt (IRC: boud), Stefano Bonicatti (IRC: smjert) or Dmitry Kazakov (IRC: dmitryk_log)

Project: Making Krita Canvas Decoration Painting Code OpenGL 3.2 compatible

Brief Explanation: When Krita was ported to Qt4, one of the great new innovations Qt offered was an OpenGL based QPainterEngine, allowing us to use the same code to draw canvas decorations (such as tool lines, selections etc.) on the OpenGL and on the GPU canvas. Fast-forward to 2016: the OpenGL QPainterEngine is not compatible with the OpenGL 3.2 Core Profile and on OSX and Windows/Intel, Krita's OpenGL canvas is broken. We have two options: port the QPainterEngine to OpenGL 3.2 Core Profile, or rewrite all places in Krita where we use QPainter on an OpenGL widget.

Expected Results:

• Either: a ported QPainterEngine (which we can then upstream to Qt)
• Or: an implementation of Krita's canvas decoration classes that uses OpenGL 3.2 directly

Knowledge Prerequisite:

• C++, Qt, OpenGL, GLSL

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Taking the Shape Brush to the next level

Brief Explanation: Krita has a number of interesting brush engines. One of them is the Shape Brush engine. Inspired by Alchemy, the shape brush "throws" shapes on the canvas. The current implementation is limited to geometric shapes. We want the brush engine to be extended to make it possible to load vector shapes defined as PDF or SVG and use those to draw on the canvas as well. Other improvements are the addition of Feathering, an outline mode, edge sharpening and background textures.

Expected Results: A revampted and exciting shapes brush

Knowledge Prerequisite:

• C++, Qt, Krita

Mentor: Boudewijn Rempt (IRC: boud) or Lukas Tvrdy (IRC: LukasT)

Project: Implementation of experimental OpenCL support for layer composition, filtering and painting

Brief Explanation: Krita in the current state relies purely on CPU power for vast majority of operations. Many of them can be offloaded onto GPU. This will improve performance due to high throughput of parallel operations and potentially will enable power-efficient port of Krita for mobile devices.

Expected Results: Architecture for OpenCL module which allows to interact with existing code seamlessly and preliminary support for GPU acceleration. Ideally, there should be a separate tool that paints directly on a OpenCL/OpenGL buffer stored in GPU memory. This buffer should be painted over the existing Krita canvas.

Knowledge Prerequisite:

• C++, OpenCL

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Implementation of experimental OpenGL-enabled brush

Brief Explanation: Krita in the current state relies purely on CPU power for vast majority of operations. Many of them can be offloaded onto GPU. This will improve performance due to high throughput of parallel operations and potentially will enable power-efficient port of Krita for mobile devices.

Expected Results: this is another experimental GPU-related project that allows the user to paint over the canvas purely on GPU. But this project relies on a different technology: openGL. There should be a special kind of layer that is stored in GPU memory and a special tool that is capable of painting over this layer. The tool should be able to use basic Krita brush presets (for the Pixel Brush engine) to paint over the canvas with the speed of lighting. To make this project easier, we put a limitation: this special layer should be on the top of the layers stack and therefore, just painted over the Krita openGL canvas.

Knowledge Prerequisite:

• C++, OpenGL

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Extending animation by adding a sound channel and scratchpad on the timeline

Brief Explanation: Krita now has a support for doing animations. But it is suboptimal for people who do a character animation over the existing sound channel (most of the studios work this way). Krita should be able to attach a sound channel to the timeline, then the user should be able to paint over the timeline to mark the places where the character tell specific words.

Links: A lesson by Aaron Blaise: https://www.youtube.com/watch?v=rYPx6sGZzow

Expected Results: GUI for the sound channel visualization and a skratchpad. Ability to play sound with the specified frame rate (exactly the one Krita is playing animation at the moment).

Knowledge Prerequisite:

• C++, Qt, Sound Processing

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Add Python Scripting to Krita

Brief explanation: Krita has had two attempts at scripting support: through kjs and through kross. Neither was good enough. The VFXindustry standard for scripting is Python, and the goal of project is to integrate Python and PyQt directly into Krita.

Expected results: by the end of the summer, users should be able to automate repetitive tasks, file import and export and add gui elements such as dockers, all written in PyQt.

Knowledge Prerequisite: Deep knowledge of Python, SIP, C++ and Qt.

Mentor: Boudewijn Rempt (IRC: boud)

Project: Add 3D Painting Assistants

Brief explanation: One of the more innovative features in Krita are the painting assistants. These are shapes overlaid on the canvas that the artist can use to help him achieve perspective, straight lines and other shapes freehand. For complex drawings it would be useful to be able to place 3D models on the canvas, position and scale them and use those as guides for drawing.

Expected results: by the end of the summer, 3D models should be shown on canvas as canvas decorations, using OpenGL in hidden-line wireframe mode. The models should be manipulated using on-canvas controls like other assistants. Magnetic snapping is an optional extra.

Knowledge Prerequisite: C++, Qt, OpenGL, Assimp

Mentor: Boudewijn Rempt (IRC: boud)

Kdenlive

Kdenlive is the free video editor for simple tasks and for professional projects. It relies on several multimedia components, and is a complex program with a quite long history... So it takes some time to get used to its internals.

Kdenlive tiny development team unfortunately can't offer a daily support to newcomers, so some autonomy, patience for search, trials and errors will be a good point :-\

Project: Porting to Windows (and OSX?)

Brief Explanation: All components Kdenlive relies on already run on Windows (Qt5/KF5 thanks to KDE on Windows, FFMpeg/MLT thanks to Shotcut), and Kdenlive itself was already ported a long time back. The goal would be to compile, debug, fix and distribute Kdenlive on Windows. If that was a too easy task (?!?), we also would like OSX support then!

Expected results:

• Compile and debug environment setup (using KDE on Windows emerge tool, with mingw?)
• Application starting and able to do common simple tasks, opening to more complete testing by real users (patches will certainly be needed)
• Procedure to generate installer for autonomous application distribution

Knowledge Prerequisite:

• Some unix & windows scripts understanding to set properly up the development environment
• Ability to look for solutions to windows specificities in Qt/OpenGL topics, from already ported applications (KDE on Windows, digiKam, Krita, PIM: look into their code, go asking into their channels...)

Mentor: Vincent Pinon (IRC: vpinon)

KStars

KStars is a very powerful tool for anyone interested in astronomy. It is part of the KDE Edu suite.

Project: Seamless retrieval of data on deep-sky objects in KStars from the internet

Brief explanation: KStars already has a database that supports the download and display of catalogs of deep-sky objects. The aim of this project is to implement yet another database for the download and display of “variety” deep-sky objects without being bound to a given catalog; then, build machinery to download object data from the CDS Sesame resolver and put it into this database. Finally, this would mean that the user could seamlessly look up an object that KStars knows nothing about, and KStars will fetch the required info from the internet.

Expected results: by the end of summer, a user should be able to type into the KStars “Find dialog” the name of an object that KStars has no data on. KStars should fetch the data from the internet, create an object in KStars’ database, and take the user to its location.

Knowledge Prerequisite: C++, Qt, XML parsing, SQL

Mentor: Jasem Mutlaq (IRC: knro), Akarsh Simha (IRC: kstar)

Project: KStars Lite

Brief explanation: Currently KStars only runs on desktop/laptop computers. Due to the proliferation of tablet/mobile devices, a lite version of KStars should be available to users on these form factors. The goal is to develop a QML/QtQuick2 frontend for KStars with basic functions:

1. Sky map: Pan, zoom...etc
2. Search
3. Color schemes
4. Simulation time
5. Location/Time from mobile/phone or by user
6. Optional: Projection Systems
7. Optional: FOV Symbols

The student is expected to work initially on separating GUI/Data coupling in KStars, and then write a QML/QtQuick2 frontend to present the necessary functionality to the user. The work must be performed against the primary branch, i.e. there will be no separate application specific for tablet/mobile, all form factors must share the same code base. The sky map shall contain the default stars and DSO catalogs with possibility of additional catalogs in the future.

Expected results: Lite version of KStars for Mobile/Tablet form factors.

Knowledge Prerequisite: C++, Qt, QtQuick2

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

• Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
• Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: KStars on Windows

Brief explanation: While KStars is available on Windows by KDE via the KDE Windows Initiative, it is out of date and requires a lot of installation prerequisites in KDE4. The primary goal is to develop a single KStars installation Windows executable to install KStars and any prerequisite libraries in KDE5/Qt5. The secondary goal is to use ASCOM under Windows to drive telescopes. KStars relies on INDI Library to control astronomical devices in Linux, and currently INDI Library is not available on Windows. You need to update KStars to accommodate ASCOM telescopes under Windows. The student may utilize any open source and/or free installation frameworks to build the final executable.

Expected results: KStars single executable for Windows. ASCOM telescope support under KStars for Windows.

Knowledge Prerequisite: C++, Qt, INDI/ASCOM

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

• Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
• Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: DSS Overlay

Brief explanation: DSS is a digital version of an all-sky photographic atlas. The goal is to add a KStars component to superimpose the DSS images unto the sky map. Therefore, the end user shall be able to view the real sky view against the simulated sky map. The user should be able to enable/disable the overlay just like any other sky component (e.g. Milky Way). Utilize DSS tiles spanning 1x1 square degrees for a total of 41253 tiles all over the sky map. Due to the storage and resource limitations, the tiles should be only displayed at high zoom levels starting with FOV 10 degrees or lower.

Expected results: DSS overlay component covering the whole sky.

Knowledge Prerequisite: C++, Qt

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

• Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
• Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: Propose your own project

Brief explanation: If you have some interesting ideas about KStars that can be implemented within the GSoC timeframe, you are very welcome to propose them, because we seem to have run out of ideas.

Mentors:

KWin

Project: Running KWin/Wayland in a Docker container

Brief explanation: In order to more easily test our software and to provide an emulator for Plasma mobile we need to be able to use KWin/Wayland in Docker. Running in Docker requires that the visual output goes to a different windowing system (e.g. X11/Wayland) living outside the container. The access to this windowing system must be made available for KWin inside the Docker container, but not to other applications inside the container. Furthermore it must be possible for KWin to use host OpenGL functionality and not be restricted to llvmpipe based OpenGL.

Expected results: By the end of summer KWin can run in Docker.

Knowledge Prerequisite: C++, containers, unix sockets

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

Project: Layered compositing in KWin/Wayland

Brief explanation: Modern GPU supports layered rendering. A frame can consist of multiple layers which are composed directly by the GPU. For KWin/Wayland this is an interesting technology as it allows to bypass the OpenGL based compositor. Instead of rendering each window into a static OpenGL buffer and presenting that, each window can be passed into a layer and the layers can be composed directly by the hardware. This means that less rendering needs to be performed resulting in less power consumption and longer battery life.

The task of this project is to implement an infrastructure in KWin to allow passing windows to layers instead of rendering through the OpenGL compositor. KWin internally has already decent knowledge whether OpenGL will be needed or not. The important part in this project will be to add support to the DRM backend to know whether layers are supported and whether the current frame can be composed this way. The new atomic mode setting API can and should be used for this. The new code in KWin needs to be flexible enough to also support the hwcomposer backend. More information about the idea at https://blog.martin-graesslin.com/blog/2015/08/layered-compositing/

Expected results: DRM backend can use layered compositing

Knowledge Prerequisite: C/C++

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

Project: Wacom Tablet support in KWin/Wayland

Brief explanation: A Wayland compositor needs to forward input events. So far KWin and KWayland does not yet have support for tablet events.

The task of the project is to implement support in KWayland on both client and server side. KWin receiving tablet events from libinput and forwarding them to the Wayland server. An example application for testing might be Krita.

Having access to a Wacom tablet or similar might be helpful.

Expected results: Tablet support in KWin/Wayland.

Knowledge Prerequisite: C/C++, Wayland

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

Project: Window Tab support in KWin

Brief explanation: KWin used to support window tabs in the window decoration. This got lost with the switch to the new KDecoration2 API. But the code in KWin still exists and could easily be reactivated. All it needs is support for in KDecoration2.

The task of this project is to add the missing API in KDecoration2 and hook KWin to it. In addition the default decoration (Breeze) should be extended to support it. This has to be done in close collaboration with the Visual Design Group

Expected results: Window Tab support in KWin and Breeze

Knowledge Prerequisite: C++, Qt

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

Plasma

Project: Plasma mobile emulator that allows to test shell and applications easily on desktop

Brief explanation: Not all app developers have access to mobile devices that is capable of running Plasma mobile. This project aims to have Plasma mobile emulator similar to Android Virtual device which developers can use to test applications and get idea of how it would look on the phone.

Expected results: By the end of summer, developers should be able to easily test applications and shell on their desktop/laptop.

Knowledge Prerequisite: Qt, QML, C++

Mentor: Bhushan Shah <[email protected]>

Project: Plasma mobile network settings

Brief explanation: The current network applet and network configuration app are not really suitable for mobile usage and both have unnecessary features/options which are not used in mobile world. This project aims to write a mobile friendly UI for both components.

Expected results: Plasma mobile has mobile friendly network settings

Knowledge Prerequisite: Qt, QML, C++

Mentor: Jan Grulich <[email protected]>

Project: Porting Plasma PublicTransport framework

Brief explanation: Porting the Plasma PublicTransport framework to Plasma 5 and QML. If the porting is done quickly and successfully you can work on a Plasma Mobile widget for the PublicTransport framework. Please get in contact with the Plasma team <[email protected]> and mentors early and show us your experience with some work on bug fixes or feature requests.

Expected results: Finished port of Plasma PublicTransport framework plus working Plasmoid.

Knowledge Prerequisite: Experience in Qt, QML and C++

Mentor: Eike Hein <[email protected]> & Co-Mentor Mario Fux <[email protected]>

Project: Port Libreoffice VCL skin to Qt 5

Brief explanation: make a Qt 5 skin for Libreoffice

Expected results: Libreoffice looks good

Knowledge Prerequisite: Elite c++ skillz

Mentor: Jonathan Riddell, Jan from Libreoffice

Try updating this build system starting patch https://gerrit.libreoffice.org/#/c/13078/ which just renames qt4 skin

Note: could also be done as a Libreoffice project

WikitoLearn

Collaborative textbooks: http://wikitolearn.org/ | Mail list: https://mail.kde.org/mailman/listinfo/wikitolearn | http://meta.wikitolearn.org/Communication_channels

WikiToLearn is a collaborative platform to create, refine and create collaborative textbooks.

Project: Plots and image creation while editing

Brief description: Plots and similar type of scientifical images are extremely needed while editing scientifical documents. However, the current technology requires the contributor to create SVGs using a variety of their own skills, which leads to many inconsistent images of very different qualities. Also, it becomes very hard to collaborate on SVG renders. The scientifical world has created exist tools such as tikz, which produce beautiful graphics, but it’s not possible to upload source files directly in the wiki. The idea is to provide an extension that can render these images from the source, such as <tikz>..image..</tikz>. Tikz is just an example, we can of course go beyond that.

Expected results: Being able to either upload graphics from other graph applications or having a Special page with an editor.

Knowledge prerequisites:

• Mediawiki (Extensions and basic framework)
• Some graph framework that you choose to use

Mentor: Riccardo Iaconelli, Davide Valsecchi, Gianluca Rigoletti

Project: Discoverability of content

Brief description: At WikiToLearn, we aim to provide textbooks with insight in all possible fields of human knowledge. That is a sheer lot of content. Things get worse when we don’t have a unique path through books, and information might be scattered in many different places. We need to make content discoverable and accessible, so that people can study and eventually assemble new books. We have to organize naming schemes and interfaces in a way that don’t discourage collaboration and forking, but still prove efficient in indexing and researching material.

This idea is a challenge that requires way more thinking and way less techical implementation than average, but could be a very interesting work if you’re a data freak. :-)

Expected results: Easier discoverability of content. This is really dependent on what you want this to be.

Knowledge prerequisites: Depends on the path you take to make the project happen.

Mentor: Riccardo Iaconelli, Irene Cortinovis, Russell Greene

Project: Book navigation/usability on the web

Brief description: At WikiToLearn, we aim to provide textbooks with insight in all possible fields of human knowledge. Things get worse when we don’t have a unique path through books, and information might be scattered in many different places. In those situations, simple concepts such as “index” stop to make sense.

The idea is to implement a “smart” index, which considers the path of the student through the website, and in general all the needed tools that can provide a usable and easy way to navigate through WikiToLearn manuals.

Expected results:

• An easy-to-navigate interface for reading books and going through chapters

Knowledge prerequisites:

• Mediawiki extension development

Mentors: Riccardo Iaconelli, Russell Greene

Project: WikiToLearn Rating

Metrics, graphs and user tracking for page quality evaluation

Brief Explanation: Pages of content on WikiToLearn could be more or less reliable and of good quality. It depends on the writer and on the connection of pages between each other. We want to develop a ranking algorithm based on user opinions. This engine should measure the user “reliability” analyzing their action on the website: edits, creation of pages, level of activity, votes. Then, these data should be used to weight user opinions in the system. The engine must deal with the developing of a page during time, being able to change the page parameter given the modifies (quantitatively). Also connection between pages could be analyzed to determine the quality of pages, using concepts of graph analysis.

Expected Results:

• A ranking engine to process data
• A Mediawiki extension to take data and show results
• Estimate of user’s reliability based on his activity on website
• Evaluation of page quality based on users’ votes, weighted on their reliability
• Analysis of the graph of pages to determine their importance

Knowledge Prerequisites:

• Mediawiki Knowledge (Extension Development)
• One of Python / Java / C++  to develop the engine

Mentor: Davide Valsecchi (@valsdav on Telegram)

Project: WikiToLearn as a Knowledge Base

Brief Explanation:

There is a lot of knowledge expressed into texts that is lost because its unstructured nature.

Could be very nice and interesting to find out a way to exploit it using a semantic approach.

Expected results:

• Defines domains and their ontologies to describe the knowledge contained in WikiToLearn

Knowledge Prerequisites:

• Semantic Web technologies
• RDF, OWL

Mentor: Alessandro Tundo (@tunale on Telegram)

Project: WikiToLearn collaborative editor

Brief explanation: Editing a WikiToLearn page is perhaps the most important feature of the website. As we do collaborative textbooks, we want to provide a collaborative feature for the text editor: more users should be able to write on the same page at the same time. The main idea is to have something similar to Google Docs, ShareLatex, SageMathCloud editing experience.

Expected results: A collaborative text editor

Knowledge prerequisites

• Web RDF
• PHP
• JavaScript
• Modern web technologies

Mentors: Cristian Baldi, Gianluca Rigoletti (@crisbal and @rigolo on telegram)

Project: WikiToLearn improved editor

Brief explanation: WikiToLearn is based on adding new content as well as editing the existing one. The current editor doesn’t offer a nice editing experience, is clunky and doesn’t even offer syntax highlighting. Math syntax is also never checked until the page is saved, which often leads to unreadable errors. We ought to provide a better one.

Expected results:

• A mediawiki extension providing a better editing experience

Knowledge prerequisite:

• Frontend Web Development (HTML, CSS3, JS)
• Backend Web Development (PHP, MySQL databases)
• Mediawiki Knowledge (Extension Development, Templates)

Mentors: Irene Cortinovis, Gianluca Rigoletti, (@pipsin and @rigolo on Telegram)

Project: WikiToLearn Desktop client

Brief description: A Qt/QML app for offline usage and browsing of WikiToLearn. Discuss user experience with your mentors and get feedback and help with mockups from the VDG. Ideally, it would be nice to port this app to mobile environments, too.

Expected Results: A nice cross-platform browser for WikiToLearn. This could possibly contain an editor.

Prerequisites:

• Qt/QML/C++ knowledge
• Web knowledge.

Mentors: Ovidiu-Florin Bogdan, Russell Greene

Project: Integrate Akhet within ownCloud and similar services

Brief description: Akhet is an infrastructure that provides secure access to a linux-based virtual desktop on the cloud, to multiple users. It is very easy to integrate as an ownCloud app or as a SageMathCloud plugin, but this needs to be tested and studied in order to create a perfect integration with the other environments. This idea, when completed, would allow users to interact with files present on the ownCloud storage with graphical applications running directly on the server.

Expected Results: Easy user interaction with files stored on ownCloud with graphical applications running directly on the server.

Knowledge prerequisites:

• Python
• Basic Docker concepts
• A little bit of PHP and willingness to learn APIs of external services

Mentors: Luca Toma (tomaluca95 on Telegram)

Project: WikiToLearn offline editor

Brief explanation: WikiToLearn is based on adding new content as well as editing the existing one. It should be possible to permit everyone, even if offline, to create of modify a new page. The user should be able to get the same experience as editing offline. The main idea is similar to what google docs does, i.e. save the work and sync it when a connection is established.

Expected results:

• A mediawiki extension or a visual editor extension capable of working offline

Knowledge prerequisite:

• Frontend Web Development (HTML, CSS3, JS)
• Backend Web Development (PHP, MySQL databases)
• Mediawiki Knowledge (Extension Development, Templates)

Mentors: Gianluca Rigoletti (@rigolo on Telegram)

Project: Neverland Theme Builder

Brief explanation: KDE's Neverland is able to build full themes from a set of template files. The designer needs to only care about the css/js files and the correct nesting of the layout (html). Once satisfied, complete themes for any supported CMS can be outputted and then used accordingly. The project is based on node.js The current code is outdated, does not use the latest development trends, and does not completely support several different designs, so that a config switch could be used to tell the system which design to build.

Expected results: Review the current code, update and improve upon it, use the latest web development trends. Make it more readable and usable for the end user. This involves Documentation. As a side effect implement the WikiToLearn Design to be build.

Knowledge prerequisites:

• node.js
• PHP
• basic knowledge of how themes for some of the most famous CMS are written, including Mediawiki

Mentor: Ingo Malchow

Inqlude

Inqlude is the Qt 3rd party library archive. It collects all libraries based on Qt, which are available. KDE is the biggest contributor to these libraries with KDE Frameworks 5 and is running the Inqlude project.

There are a number of possible GSoC projects for Inqlude. We probably will not be able to mentor more than one. Here are a number of ideas for projects, but students are welcome to generate their own ideas or combine the listed ideas in their own way.

Project: Manage Qt libraries dependency information

Brief description: Some of the libraries on Inqlude can be used stand-alone, some others require other libraries from Inqlude. Primary example are KDE Frameworks, which are classified in several tiers representing different levels of requirements. This dependency information should be collected, so that users easily can see what they need, when using a given library. Some additional support by the tools to for example fetch dependent libraries automatically when setting up a project would be nice as well.

Expected results: Accurate representation of dependencies between libraries listed on Inqlude and extension of tools to make it convenient to handle them.

Knowledge prerequisites (can be acquired during the project by an avid learner):

• Ruby for working on the command line tools
• Some basic JSON for working with the library meta data
• Some basic HTML for adding information to the web site

Mentor: Cornelius Schumacher (cornelius on IRC)

Project: Improve categorization and search on Inqlude web site

Brief description: We are collecting a lot of attributes of libraries on Inqlude. While there is a basic search and some categories, these are only covering a few use cases. To make it easier for people to find the libraries they are looking for we should have more fine-grained navigation based on categories such as licenses, platforms, dependencies on Qt versions or other libraries, etc. We also should improve the search to be more tailored to the data collected on Inqlude.

Expected results: Improved navigation and search of Inqlude web site.

Knowledge prerequisites (can be acquired during the project by an avid learner):

• Ruby for working on the command line tools
• Some basic JSON for working with the library meta data
• HTML, CSS, Javascript for implementing changes to the web site
• Understanding of usability and design processes for structuring information

Mentor: Cornelius Schumacher (cornelius on IRC)

Project: Integrate Inqlude in KDevelop

Brief description: Inqlude list all existent Qt libraries. It would be great, if these would easily be accessible in KDevelop, so that users of the IDE could find and identify suitable libraries and integrate them into their projects in the easiest possible way.

Expected results: Access to libraries listed on Inqlude in KDevelop

Knowledge prerequisites (can be acquired during the project by an avid learner):

• Qt and C++ to work on integration in KDevelop
• Basics of Ruby, JSON, HTML to understand and work on the Inqlude tooling

Mentor: Cornelius Schumacher (cornelius on IRC), if this project is going to happen, we also need to find a mentor from the KDevelop side (volunteers are welcome :-)

Marble

Project: Medium and Low Tile Levels in the OSM Vector Map

Brief explanation: Image based maps like the one shown on https://www.openstreetmap.org/ are frequently used because they are easy to setup. Vector maps on the other hand offer a much more flexible rendering while they also reduce the amount of data needed to download and store on a device. An OSM vector map has been added to Marble recently and supports high (street) tile levels. This project is about adding support for medium and low tile levels in that map.

Expected results: The OSM vector map in Marble shows data for all tile levels. For low tile levels, vector data from a Natural Earth map theme variant already present in Marble can be adapted and re-used. Medium tile levels should be rendered from OSM data. This requires extending the vector tile creation tool to produce suitable vector tiles and adjusting the level of detail rendered by Marble in medium tile levels.

Knowledge Prerequisite: C++, Qt

Mentor: Dennis Nienhüser (IRC: Earthwings), Torsten Rahn (IRC: tackat)

Project: Real-time Vector Rendering in Marble Maps on Android

Brief explanation: Marble Maps for Android is going to become a user-friendly OpenStreetMap navigation app. For a smooth experience the app needs to render vector maps in real-time. In this project rendering bottlenecks should be identified and fixed.

Expected results: Zooming and panning in Marble Maps on an Android device with recent hardware works smooth without any lags.

Knowledge Prerequisite: C++, Qt

Mentor: Dennis Nienhüser (IRC: Earthwings), Torsten Rahn (IRC: tackat)

Baloo

Project: Improve User Experience

Brief explanation: Baloo is the file searching and indexing framework used by KDE. Baloo is not an application, but a daemon to index files. Applications can use the Baloo framework to provide file search results. This Google Summer of Code project aims to fix the user perceived slowdowns caused by baloo.

1) Right now, while indexing Files baloo commits the indexing information of files after a fixed number of files (40). This often leads to small frequent writes leading the IO slowdowns. The ideal behavior would be to keep track of memory usage and commit the indexing information to the DB after a certain threshold leading to batching of as many writes as possible.

2) Right now baloo indexes the users entire home directory by default and the KCM provides only options to blacklist certain directories (even though lots of other stuff can be configured in ~/.config/baloofilerc). The ideal behavior would be that baloo indexes only the Xdg user directories (Documents, Downloads, Music etc.) and provide the user with an intuitive KCM to add more folders and set blacklists. This would involve coming up with a new KCM design as well.

3) Any other optimizations towards this goal would be welcome.

Expected results:

1) Less users complaining: "Baloo makes my computer crawl" 2) A simple by default, powerful when needed KCM for configuring baloo.

Knowledge Prerequisite: At least some C++ and Qt experience is required;

Mentor: Pinak Ahuja <[email protected]>, pinak on Freenode; Boudhayan Gupta <[email protected]> BaloneyGeek on freenode

Qt

Project: C# language bindings for Qt

Brief explanation: There's an existing project aiming to provide C# bindings for Qt. It's called QtSharp and it's hosted at https://gitlab.com/ddobrev/QtSharp. It, however, lacks a few essential features to be ready for general usage:

• Type maps for basic types - QList, QVector, QMap, QHash, QChar;
• Qt Quick support;
• Documentation package – online and off-line documentation for the generated bindings;
• Build scripts to produce and upload binaries of the generated bindings;
• Automatic management of memory – might not be reasonable or possible so leave for last.

Expected results: Binaries for Linux (for cross-platform support OS X and Windows could be added) allowing developers to use C# combined with Qt to create KDE applications.

Knowledge Prerequisite:

• C++ for understanding parsing errors and supporting the Clang-based parser;
• C# as the main language of the project and generating valid code;
• Qt for familiarity with the modules, basic classes and overall structure;
• Any build script for generating binaries.

Mentor: João Matos <[email protected]>

Web

Project: Use Phabricator API to enhance KDE Reports

Brief explanation: KDE has been trying to move to Phabricator for some time and we’re almost there.

KDE Reports fetches some data from sources that might be gone soon (For example: projects.kde.org and git.reviewboard.kde.org).

We need to update KDE Reports to make it able to fetch data from KDE’s Phabricator instance located at: phabricator.kde.org using its powerful API.

If there’s more time in the project, we’d like to do some other improvements to the app: Make the code more modular by taking out some of the logic defined in the Project model into some lib modules(You can see some examples of work in that direction in the latest commits). Other options include removing unused code, improvements to the test suite and upgrading to latest Rails version(Hopefully Rails 5 if released by then).

The repository of the project: https://quickgit.kde.org/?p=websites%2Freports-kde-org.git
Make sure to read the Readme file before asking questions.

Expected results: KDE Reports adjusted to fetch possible data from KDE's Phabricator instance and overall improvements to the code of the app.

Knowledge Prerequisite:

• Ruby on Rails;

Mentor: Ben Cooksley

Project: Sysadmin - Revamping KDE's Project Management

Brief explanation: Very soon, KDE will be moving to Phabricator for project management. This leaves us with a few shortcomings that need to be addressed:

• Synchronizing our repositories with our Anongit servers and Github - this is currently done with a few shell scripts and after the move to Phabricator will be done using a tool called Propagator. Propagator is currently only very basic and needs a few improvements:
  • We need to be able to send E-Mails to system administrators on errors and sync failures
  • Propagator currently uses AsyncIO for communicaton between the control tool (mirrorctl) and the daemon. This hikes up the requirements for the Python interpreter to 3.5. We'd like to use Tornado and a JSON API for this, especially since adding a dependency on Tornado makes the next bit very easy to do.
  • We want a nice looking web dashboard accessible over the Internet giving us the status of each anongit mirror - whether it's up or down and when it was last updated, along with when the master server was last updated. This'll enable anyone to check on the server health and see if a mirror is out of date.
  • Since Propagator is meant to be a product in its own right and not merely an internal sysadmin tool, we'd like a plugin system implemented that allows you to specify your own types of remote servers, not just standard Git servers and GitHub as currently supported. An example plugin for GitLab sites can be developed to demonstrate this plugin functionality.
• A second side-effect of losing projects.kde.org is that we'll lose access to all the landing pages for projects. In the sysadmin/repo-metadata.git repository, we keep all our data (including name, description, icon and a list of maintainers) for our projects. A stretch deliverable could be an application to generate a static site from this data providing information about all our applications and libraries. This would also be a direct replacement for www.kde.org/applications.

Expected results: Propagator becomes more robust, can e-mail people on errors, can report on mirror status, and can be extended to support more types of remotes. Also, KDE gets a new static site giving information about all our applications and libraries.

Knowledge Prerequisite: Python3, Tornado, Celery, Jinja templates and other related technologies.

Mentor: Boudhayan Gupta <[email protected]>