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 kde-devel@kde.org. 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:

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.

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.

Dolphin

Dolphin is a lightweight file manager. It has been designed with ease of use and simplicity in mind, while still allowing flexibility and customisation.

Project: Polkit support in KIO/Dolphin

Brief explanation: Dolphin currently doesn‘t support manipulating files owned by the root user. Many people work-around this limitation by starting Dolphin with root permissions, which is dangerous and not supported. The goal of this project is to provide a Dolphin implementation that opens a nice authentication dialog whenever a file needs to be deleted/moved/created in a folder owned by root. On Linux, this kind of authentication dialogs is provided through Polkit.

Dolphin doesn‘t touch the filesystem directly, it uses KIO jobs for this task. This means that Polkit support needs to go in KIO itself. Note that this will benefit all KDE applications, not just Dolphin! This project is divided into two steps:

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

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, after having typed their password in a polkit authentication dialog. Dolphin should also exit if it detects it has been started with root privileges.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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)

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.