GSoC/2017/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.

Note

These are all proposals! We are open to new ideas you might have!! 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.

Adding a Proposal

Note

Follow the template of other proposals!

Project:

If appropriate, screenshot or other image

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.

digiKam

digiKam is an advanced digital photo management application for Linux, Windows, and MacOS.

• digiKam project web site
• Mailinglist
• Google+ page
• #digikam IRC channel on Freenode

Project 1 : digiKam database export to remote devices

Brief Explanation: In the past, Kipi-plugins provided a way to export KIPI host data to DLNA/UPNP by a plugin using HUpnp library for Qt. Since porting this tool to Qt5 will not work as HUpnp project is unmaintained and its 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 DLNA Export. 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.
• Test the new implementation under Windows and MacOS.
• Write unit tests and documentation.

Knowledge Prerequisite: DLNA/UPNP, C++, and Qt5

Mentor: Gilles Caulier, Mohamed Anwer, and Maik Qualmann

Project 2 : digiKam Database separation for similarity information

Brief Explanation: digiKam has a feature to search items by similarity.This require to compute image fingerprints stored in main database.These data can take space on disk especially with huge collection. This can bloat the main database a lots and increase complexity to backup main database which include all main information for each item registered, as tags, label, comments, etc. As for Face management database, which store face histograms in a dedicated database, the similarity fingerprints must be stored in a dedicated database.

Expected results:

• Review current whole database implementation including database schema hosted as XML.
• Isolate tables and schemas relevant of similarity fingerprints.
• Create a new schema for similarity features.
• Create a new database access interface inspired of Faces Management database interface.
• Implement code to drive fingerprints for Sqlite and MySQL/MariaDB.
• Write unit tests for database interface and documentation.

Knowledge Prerequisite: Database, Sqlite, MySQL/MariaDB, C++, and Qt5

Mentor: Gilles Caulier, Mario Frank, and Maik Qualmann

Project 3 : digiKam Web Services tools authentication with OAuth

Brief Explanation: digiKam has many tools hosted in Kipi-plugins project dedicated to share items on web services, as Facebook, Google, Flickr, Dropbox, Imgur, etc... All tools use an older way to be authenticated through the web service using an external web browser instance to capture the token network session. This is a fastidious way to open a web service session. Only Imgur tool use an embedded OAuth authentification without a web browser instance through O2 library for Qt. The goal of this project is to port all others web service tools to O2 library API.

Expected results:

• Review current implementation of Kipi-plugins tools and identificate all web service compatible with OAuth standard.
• Plan the amount of work to port tools by order of complexity, and identify possible problems.
• Port code for each tools step by step, by writing unit tests independently.
• Test all tools with all use cases, depending of tool options.
• Write documentation.

Knowledge Prerequisite: Network, OAuth, C++, and Qt5

Mentor: Maik Qualmann and Gilles Caulier

Project 4 : digiKam Face Management improvements

Brief Explanation: digiKam is already able to detect well faces in photos, through a core interface based on OpenCV shared library. However the face management needs amelioration:

• Face Recognition is implemented using Eigenfaces algorithm to identify the person depicted and automatically tag the region on the photo with the person's name, but the algorithm require improvements to get better automatized results.
• The user workflow in GUI need also some improvements and fixes to have a better usability in graphical interface.
• The face region registered in database and image metadata need to be synchronized accordingly with image transformations.
• See relevant entries in bugzilla.

Expected results:

• Review current implementation of Face Recognition and Improve existing Eigenfaces implementation.
• Fisherfaces recognition method is partially implemented. Finalize this algorithm digiKam face engine.
• Patch digiKam faces management to be able to switch between recognition methods.
• Review main reports from bugzilla about face management usability.
• Propose solutions to solve main face management usability issues.
• Propose solutions to solve face management metadata issues with face regions.
• Write unit test tools.
• Write documentation.

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

Mentor: Gilles Caulier, Mario Frank, and Maik Qualmann

WikiToLearn

You can find all of the WikiToLearn community on chat.wikitolearn.org. We have many other ideas: get in touch with us to discuss them further!

Project: chat bridge

Brief description: chat bridge is intended to be a protocol-independent chat-bridge to allow message forward from and to various chat system. This system has to interact with the chat with an API (no patch to servers has to be required) and be able to handle differences. For example expose an HTTP/HTTPS server to send a link to an IRC chat if in Telegram someone sends an attachment. The system has to be designed to have modules to other protocols (for future expansion).

Expected results: Have up and running (let's say version 1.0) a chat bridge that can work with: IRC, RocketChat and Telegram support.

Knowledge prerequisites:

• Concepts of network protocol
• Modern programming language

Mentor: Luca Toma

Project: Stabilize and ship Ruqola

Brief description: Ruqola is a Qt interface to Rocket Chat, with a library implementing DDP semantics, and a QML UI for both the desktop and mobile phones. The project aims to make the application ship smoothly to the desktops and to at least one mobile platform (Android or iOS), with a clear plan to support the other.

Expected results: Release Ruqola 1.0 for desktop and on mobile.

Knowledge prerequisites:

• C++
• Qt/QML
• Basic concepts of mobile development

Mentor: Riccardo Iaconelli

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

KDE Frameworks

Project: Polkit support in KIO

Brief explanation: Running Qt GUI applications as root is dangerous. Some KDE applications are disabling being executed as root. For example, the next versions of Dolphin and Kate will show an error message and exit when started with root privileges. The goal of this project is to add Polkit support in KIO, the library used by KDE applications to manipulate the filesystem. Polkit is the standard framework used by Linux desktops to grant privileged actions to unprivileged processes.

KDE provides the KAuth library to easily integrate Polkit in KDE projects. You will be expected to refactor the file ioslave with KAuth actions. More details in https://phabricator.kde.org/T5202.

Once KIO becomes KAuth-aware, the student will make sure that everything works with Dolphin and Kate, the most popular applications used for editing root files. In particular, on the Dolphin side it is required to relax the assumption that root-owned locations cannot be edited (see https://phabricator.kde.org/T5203).

Expected results: by the end of the summer, a user should be able to delete/move/create a file or a folder in a root-owned location (say, /opt) from Dolphin, as well as editing root files from Kate, after having typed their password in a polkit authentication dialog.

Knowledge Prerequisite: C++, Qt

Mentor: Elvis Angelaccio (IRC: eang on #kde-devel; mail: [email protected])

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: Integrate with share.krita.org

Brief explanation: Share.krita.org is a place where users can share krita scripts, images, brush packs and more. Krita used to use GHNS (Get Hot New Stuff) to integrate with the predecessor of share.krita.org, but that support has disappeared. This project has two parts: integrate with the knewstuff framework (or reimplement the protocol) and create a gui for sharing. The second part is improving the support for creating and editing bundles. Bundles can contain brushes, patterns, gradients and so on. Krita has basic support for creating and editing bundles, but it doesn't work very well in practice. For this part the student must work together with our UX design team to create a better gui design, then implement it. We also want to be able to publish images directly to share.krita.org

Expected results: by the end of the summer, a user should be able to create a bundle from resources registered with Krita, upload it to share.krita.org and install bundles that have been uploaded to share.krita.org.

Knowledge Prerequisite: C++, Qt

Mentor: Boudewijn Rempt (IRC: boud), Scott Petrovic (IRC: scottyp)

Project: Extending Animation Support for curves

Brief Explanation: Last year, we added curves that could be applied to some properties of a layer, like opactity. 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 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
• Saving of these settings

Knowledge Prerequisite:

• C++ and Qt

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 lightning. 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: Analysis of thoroughput of Krita Blending Modes and porting them to AVX2

Brief Explanation: Blending modes is the hottest piece of code in Krita. It should process gigabytes of data per second, therefore it should be extremely optimized. Some of its parts are already optimized to use AVX instructions, but some (float16 color spaces) are not. We need to port the rest of the color spaces to AVX and make a research into the possibilities of using AXV2 instructions directly (int16 instructions). It might happen that you will have to extend VC library to get full AVX support.

Expected Results: Ported Float16 color spaces to AVX, extended Vc library to support int16 AVX2 instructions and adopted it in Krita

Knowledge Prerequisite: C++, SEE/AVX (read Intel's manual)

Mentor: Dmitry Kazakov (IRC: dmitryk|log)

Project: Using cubic splines to create a very quick brush

Brief Explanation: This is a research project. The student should find a way to convert a usual (X,Y) coordinates into a curved coordinate system (l,h) associated with a cubic curve: l (position at the curve), h (distance to the curve). If we have such a mapping, we can create an extremely quick brush that is up to 10 times faster than the current Krita's Pixel Brush.

Expected Results: It is expected that the student has done at least a part of the research before doing the proposal and is kind of sure that such mapping is possible. If the mapping is impossible or not quick enough, then the student can change the project and implement a "quick brush" engine from here.

Knowledge Prerequisite: C++, analytical geometry

Mentor: Dmitry Kazakov (IRC: dmitryk|log)

Project: Partial canvas updates and region of interest (performance optimization for huge (20k+) canvases)

Brief Explanation: We already have an optimization for huge canvases, which is called Instant Preview. But it woks only when the user has the canvas zoomed out to fit the screen. There are some usecases, when the user wants to work with a small "working area" of a huge image and he doesn't care what happens with the rest of the image. This project is targeted to optimizer this case.

Expected Results: By the end of the summer we expect these features to be implemented:

• Partial updates in openGL canvas. Right now we redraw all the image textures in every frame, which is not needed after porting to Qt5.
• Region of Intereset (ROI) in KisImage. Updates should be reordered and the priority should be given to the areas that are currently visible to the user
• Work Area Tool. The user is be able to define the area, where he would like to work in. The updates for other parts of the image are skipped until the user exits this special mode.
• (if there is time) Optimize textures loading to use RIO as well. Theoretically, we can just skip uploading of the tiles that are not visible on the screen at the moment.

Knowledge Prerequisite: C++, OpenGL

Mentor: Dmitry Kazakov (IRC: dmitryk|log), Julian Thijssen (IRC: Nimmy)

Project: Lazy Selection Tool

Brief Explanation: We already have a Colorize Mask for filling line art. Now we need to extend it to support easy selection of the objects. The final tool should look something like Gimp's Foregroud Selection Tool but quicker and more intuitive to use.

Expected Results: By the end of the summer we expect the selection tool to be merged into master and ready for use by the users.

Knowledge Prerequisite: C++, analytical geometry

Mentor: Dmitry Kazakov (IRC: dmitryk|log)

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: Julian Thijssen (IRC: Nimmy)

KStars

KStars is free, open source, cross-platform Astronomy Software. It provides an accurate graphical simulation of the night sky, from any location on Earth, at any date and time.

Project: All-sky DSS/SDSS overlay

Brief explanation: KStars is a very good simulation of the night sky where it draws many objects including stars, planets, galaxies, nebulae and more. However, observers sometimes would like to see how the real sky looks at a particular location. Fortunately, we have Digitized Sky Survey that covers large swaths of the night sky. Second-generation DSS2 contains plates for several filters enabling full-color images to be overlayed unto KStars sky map.

Expected results: Ability to toggle DSS2 color overlay on and off covering all the sky. User can utilize the data either by downloading a specific set of files (expected to be a large data set), or by progressively downloading and caching the data files and displaying them as necessary given the zoom level. Student must optimize memory, bandwidth, and CPU usage throughout the whole process as it should not affect the performance of KStars. A complete API must be developed to enable customized overlay generation given equatorial coordinates, field of view, number of required components...etc so that it can be used for any tool within KStars. The user should be able to configure overlay parameters including transparency, online/offline modes..etc.

Knowledge Prerequisite: C++, Qt, Data Structures

Mentor: Jasem Mutlaq (Matrix: Jasem)

Project: Deep Sky Object Overhaul

Brief explanation: KStars supports many deep sky objects (DSOs) including galaxies, nebulae, supernovae, clusters and more. Currently, some deep sky catalogs are stored in simple space separated text format where they are parsed into KStars directly or into KStars Deep Sky Component SQLite3 database which is then loaded in KStars. However, since all DSOs are loaded at once into memory, this limits the size of catalogs within KStars. A solution similar to how dynamic stars are cached in and out of memory must be developed for DSOs. Furthermore, all catalog entries should have their trixels indexed so that they can be efficiently drawn unto the sky map. Another issue is that catalogs can overlap since there is no cross-identification of various catalogs. For example, Andromeda galaxy exists in Messier catalog as M31, and exists in NGC catalog as NGC 224. The database should support ability to cross-identify objects from all supported and future catalogs.

Expected results:

• Convert all text-format catalogs to SQLite3 database.
• Develop master DSO database where cross-identification of objects is supported. Master database can supported addon downloadable catalogs where they can be merged once downloaded by the user.
• Import of The Principal Galaxy Catalog, 2003 Version (PGC2003) which contains ~1 million galaxies into KStars as a downloadable addon.
• Caching and drawing optimizations for large catalogs.
• Cross-identification for all supported DSO catalogs including, but not limited too: NGC/IC/Messier/Arp/PGC/LDN
• Trixel indexation for all DSOs. Implementation of improved drawing cached routine in KStars for DSOs similar to stars.
• All necessary updates within KStars maps, tools and dialogs to reflect the above changes.

Knowledge Prerequisite: C++, Qt, Data Structures

Mentor: Jasem Mutlaq (Matrix: Jasem)

Project: Ekos Web Client

Brief explanation: Ekos is KStars premier tool for observatory control and automation. A web client port of Ekos is desired where it communicates with the underlying INDI servers and drivers without a direct dependency on thick desktop clients. Ekos includes many modules including setup, capture, focus, guide, align, and mount. All functionalities of the desktop Ekos client are expected in the web client version using Python+Ajax or similar framework technologies suitable for online dynamic driven clients.

Expected results:

• Online Ekos web client with all the thick client feature set.
• Authentication and Registration framework.
• Support for notifications similar to desktop client.
• Ajax dynamic driven interface with near real time updates for framing and captures.
• Multi-user support with granular permissions.
• Web based INDI Control Panel with all the driver controls as in the desktop version.

Knowledge Prerequisite: C++, Qt, Django/Ajax or similar technology framework.

Mentor: Jasem Mutlaq (Matrix: Jasem)

Project: Improving Comets and new Meteor Showers component

Brief explanation: Currently KStars supports display of comets within the solar system. The data is fetched from JPL and computed to show the position, magnitude, sun-distance, among other parameters. However, there are many inconsistencies and incorrect results in the produced results making the comets data in KStars unreliable. Furthermore, comets are drawn as simple point objects and not as comets with physical nucleolus and tail. This reduces the realism of such object within KStars. Additionally, KStars only displays the current position of the comet in the sky, while it may be desirable for the user to see the expected path (arc) of the comet through out the night sky as a function of time. Finally, KStars does not show any information on meteor showers at all. A new meteors shower components needs to be developed. The component should display meteor shows using suitable animation and presents metadata to describe the event to the end user. Such information may include seeing quality (if affected by Moon presence), expected number of meteors per hours, constellation epicenter, rise/transit/set times..etc.

Expected results:

• All the results are expected to work in both the KStars desktop version (Qt Widgets) and the KStars Lite mobile version (QML)
• Fix all comets data to agree with JPL and Minor Planet Center sources.
• Draw comet with approximate physical size for nucleus and tail that fits physical parameters. Option to draw exaggerated size for display purposes.
• Draw current vs. predicted path (from the last few hours to the next few hours) of the comet.
• Draw meteor showers animation from epicenter. Show metadata about the meteor shower and quality of observing.

Knowledge Prerequisite: C++, Qt, QML, solid mathematical background

Mentor: Akarsh Simha (Matrix: kstar)

Project: Implement Qt3D backend for KStars

Brief explanation: The Skymap in KStars desktop version is currently built using QPainter and 2D drawing primitives. In order to take advantage of advances in modern GPU hardware and to present a stunning visual view of the night sky, a 3D backend is desired. Qt 3D provides functionality for near-realtime simulation systems with support for 2D and 3D rendering in both Qt C++ and Qt Quick applications. Within KStars, SkyPainter provides a backend-agnostic class for drawing object unto the skymap regardless of the backend. Previously, an experimental OpenGL backend was developed but was later deprecated due to drawing issues. Since Qt3D provides an abstraction to the backend framework (OpenGL/Vulkan/DirectX), it presents a very flexible framework for building future-proof 3D applications.

Expected results:

• Create Qt3D based backend to draw all objects currently implemented by QPainter backend.
• Create realistic colors, shares, textures, meshes, lighting for all stars, solar system, and deep sky objects.
• Create animations for meteor shows, comet tails, stars twinkle..etc

Knowledge Prerequisite: C++, Qt, Prior experience working with 3D applications/games.

Mentor: Akarsh Simha (Matrix: kstar)

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)

Project: KF5 port

Brief explanation: Kopete currently uses KDE4 libraries and does not work without KDE4. There is unfinished KF5 port. This project is about finishing KF5 port and make it bug free so it can fully replace current KDE4.

Expected results: Kopete working on KF5 desktop without KDE4 libraries

Knowledge Prerequisite: C++, KDE4/Qt4, KF5/Qt5

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

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

To have working multi-client setup (when more jabber clients are online at same time) it is also needed support for Carbon copy:

XEP-0280: Message Carbons

Probably something more will be needed. Part of this project should be some investigation what standard/extensions are other jabber clients supports and choose those which bring multi-client setup compatibility with other clients.

Expected results: Working message archive for multi-client setup

Knowledge Prerequisite: C++/Qt, Jabber protocol

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

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, Pali on #kopete, [email protected]

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, Pali on #kopete, [email protected]

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

Project: OMEMO encryption plugin

Brief explanation: OMEMO is end-to-end encryption for Jabber protocol supporting multi-client setup. It is defined in XEP-0384. Kopete currently supports only OTR end-to-end encryption which does not support multi-client setup.

Expected results: Working OMEMO plugin in Kopete

Knowledge Prerequisite: C++/Qt, basics of cryptography

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

Marble

The Marble community combines free data and open source to produce awesome map software. Find your way and explore the world!

Project: Marble Indoor Maps

Brief Explanation: Marble Maps brings the highly detailed OpenStreetMap to your Android devices. It features a crisp, beautiful map with an intuitive user interface. This project is about extending it to support indoor maps (e.g. selecting and showing different levels of a building).

Expected Results:

• Marble extracts indoor related OSM tags
• Floor and connection elements (e.g. room, wall, door, staircase) are shown in the map. Similar to OpenLevelUp.
• User interface to select floor levels and filtering of the map view based on the active floor level
• Automatic adjustment of the floor level user interface (hide it when there are no indoor map elements in the view, select minimum/maximum floor level automatically)

Knowledge Prerequisite:

• C++, Qt, optionally OSM and QML.

Mentor: Dennis Nienhüser (IRC: Earthwings in #marble)

Interested? Please read the general KDE instructions, try to build Marble Maps on your own, have a look at our task board and contact your prospective mentor, Dennis.

Project: Material Marble Maps

Brief Explanation: Marble Maps brings the highly detailed OpenStreetMap to your Android devices. It features a crisp, beautiful map with an intuitive user interface. This project is about redesigning it in Material Design.

Expected Results:

• Marble Maps on Android follows the Google Material Design Guidelines
• Switch to the Qt Material Style as a base
• Incorporate useful ideas and patterns from other resources, e.g. Papyros

Knowledge Prerequisite:

• QML. A background in design and basic knowledge in C++ and Qt will be helpful.

Mentor: Dennis Nienhüser (IRC: Earthwings in #marble)

Interested? Please read the general KDE instructions, try to build Marble Maps on your own, have a look at our task board and contact your prospective mentor, Dennis.

GCompris

Project: finishing started activities

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: The aim of this year is to complete and getting merged activities that were started but have not been finished. First phase is to check which activities can be continued, what is missing to be integrated (on code and graphic side) and then to complete them. You can find at https://cgit.kde.org/gcompris.git/refs/heads the list of the current branches (some of them need to be dropped, so contact us before starting working on one of them) and more information on https://phabricator.kde.org/project/profile/1/.

The second aim is to refine current activities: some can be improved, whether improving the animation, adding sounds, tutorials... Some tasks already defined in the improvement section of phabricator are quite interesting.

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: Continuing an activity already started or rewriting from scratch is something you have to check before writing your application. Provide a timeline in your application. If you haven't contributed yet please read http://gcompris.net/wiki/An_exercise_for_new_contributors.

There are several info in the wiki: http://gcompris.net/wiki/Developer%27s_corner.

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

Mentors: Johnny Jazeix (IRC: JohnnyJ), Emmanuel Charruau (IRC: Allon1)

LabPlot

Project: Statistical analysis

Currently LabPlot has only basic support for statistical data analysis by providing some basic measures of desciptive statistics in the spreadsheet. The goal of the project is to add more statistics relevant features (hypothesis tests, cluster analysis, ets.) to LabPlot.

Expected results:

• evaluate available statistical open-source libraries which can be used for this project
• determine a reasonable set of features and algorithms that can be added to LabPlot, compare here with other similar projects, and implement them
• for the visualization of results of statictical calculations, implement new kind of reports for this, comparable to other similar projects

Knowledge Prerequisite: C++, Qt, basic statistics knowledge

Mentor: Alexander Semke and Stefan Gerlach

Project: plotting of real-time data

Currently, the visualization and analysis of data is only possible on static data that was imported into or generated in one of LabPlot's data containers. The goal of the project is to add support for streaming data.

Expected results:

• adjust and extend the data containers, analysis algorithms and the plotting part of the application to support streaming data
• add dialogs and wizards to configure this new kind of data sources

Knowledge Prerequisite: C++, Qt

Mentor: Stefan Gerlach and Alexander Semke

Minuet (Software for Music Education)

Minuet is a member of KDE-edu suite of educational applications and was first released in KDE Applications 16.04. Minuet 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.

Minuet currently runs on Linux, Android (Ayush Shah's 2016 Google Summer of Code project), and Windows.

Additional Information:

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

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: Chord-melody Arrangement Generator

Brief explanation: Chord melody is an music arrangement style, generally adopted by guitarists, where melody is play alongside with some pieces of harmony (example here). Whilst the generation of chord melody arrangements is quite a creative task, some basic rules enables the implementation of automatic generators with satisfactory and interesting results. The generator works by receiving two input data: the melody and the harmonic progression (sequence of chords) and then generates a chord melody arrangement for such a song. The generation should consider parameters such as maximum distance between fingers, use of not of tensions, and others. Input and output can be handled for example by using the MusicXML format. Displaying the arrangement in a spreadsheet is also expected (spreadsheet support in Minuet is in progress).

Expected results:

• Design and implementation of MusicXML I/O capabilities in Minuet (libraries already available).
• Design and implementation of the chord melody generator
• Spreadsheet integration for exhibiting the final generated arrangement.

Knowledge Prerequisite:

• C++/Qt/QML.
• Minimal background regarding music harmony.

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)

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

Brief explanation: Trojitá's GUI only shows one IMAP account at once. The scope of this task is to analyze what needs to be done, and implement the required changes for making it possible to show multiple IMAP accounts. General bugfixes are expected in the rest of the time.

Expected results: Full support for multiple IMAP accounts, including unit test coverage.

Knowledge Prerequisite: C++, Qt, contributing to Trojitá prior to GSoC

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

KDevelop

Project: Improve QML/JS integration

Brief explanation:

Expected results: Improve QML/JS integration: Module path dialog, proper handling of QRC imports, navigation for 'import ...' lines, etc.

Knowledge Prerequisite: QML, Qt and C++.

Mentor:

Project: Go Integration

Brief explanation:

Expected results: Proper semantic highlighting, code completion and projects integration.

Knowledge Prerequisite: Go, C++, some Qt

Mentor:

Project: Rust integration

Brief explanation:

Expected results: Proper semantic highlighting, code completion and projects integration.

Knowledge Prerequisite:

Mentor:

Project: Windows Debugger integration (CDB)

Brief explanation:

Expected results: Make it possible to debug applications using CDB. That is managing breakpoints and analyzing the state when the debug session is paused.

Knowledge Prerequisite: CDB, C++, some Qt

Mentor:

Project: Bundling systems integration in KDevelop

Brief explanation: Nowadays these systems' adoption is more and more common in GNU/Linux, it would be interesting to integrate the development of applications under these systems. This project could address Flatpak, Snap and/or Docker systems.

Expected results: Full project manager integration, application execution and debugging.

Knowledge Prerequisite: C++, some Qt, experience with the implemented systems would be welcome.

Mentor: Aleix

KDE neon

https://neon.kde.org

Project: adopt new Installer Calamares

http://calamares.io/

Brief explanation:KDE neon builds KDE software on a continuous integration and delivery system including installable live image ISOs. These currently use an old installer which is unmaintained so we are moving to an installer called Calamares http://calamares.io/ which is cross distro. We need it to support the same features as the current installer before we can move.

Expected results: Fill in missing features I wrote about: "However there’s a few features missing compared to the previous Ubiquity installer. OEM mode might be in there but needs me to add some integration for it. Restricted codecs install should be easy to add. LUKS encrypted hard disk are there but also needs some integration from me. Encrypted home holders isn’t there and should be added. Updating to latest packages on install should also be added. It does seem to work with UEFI computers, but not with secure boot yet. Let me know if you spot any others."

http://jriddell.org/2017/01/20/kde-neon-inaugurated-with-calamares-installer/ 

Knowledge Prerequisite:

• Knowledge of what a live image is and how to install it.
• C++ for Calamares and Python for it's addons.
• Knowledge of using the Qt widget library.

Mentor: Jonathan Riddell

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.

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.

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

Project: Port all backends to Q/KProcess

Brief explanation: Currently different approaches are utilized to implement the backends in Cantor. Some backends use specific APIs to communicate with C code, other uses DBus protocol, and more. This project aims to port all the backends to use Q/KProcess, an inter-process communication technology provide by Qt. This way Cantor will have a standard technology to implement backend, and it will enable the use of Cantor in different operational systems.

Expected results: All backends ported to Q/KProcess and R backend working again.

Knowledge Prerequisite: C++, Qt

Mentor: Filipe Saraiva (filipe at kde.org)