GSoC/2022/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 are urged to contact the developers and find out more about the particular suggestion you're looking at.

Becoming 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 rarely works.

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 another image

Brief explanation:

Expected results:

Knowledge Prerequisite:

Duration: ~175 hr or ~350 hour (use only one)

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
expected effort to finish the project (either ~175 or ~350 hrs)
your name and email address for contact (if you're willing to be a mentor)

**Ideas with no mentors listed and their contact info will be removed**

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

Duration: Mention one of ~175 or ~350 hours of effort necessary to finish the project. Use only one of these two project classes and don't come up with other numbers here.

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:kde.org on matrix.

Okular

Okular is a universal document viewer developed by KDE. Okular works on multiple platforms, including but not limited to Linux, Windows, Mac OS X, *BSD. Contact the Okular developers.

Project: Okular user interface for e-ink tables (PineNote)

Brief explanation: e-ink tables are special given their "low" refresh rate.

We would need to create a new Okular user interface (based either in the mobile or the dekstop one) to accommodate for the unique features of those kind of displays.

We will probably arrange to get a device loaned if someone gets selected for this project.

Expected results: A new Okular user interface that works well with e-ink tablets.

Knowledge prerequisite: C++, probably QML.

Duration: 350 hours.

Mentor: Albert Astals Cid [email protected]

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: Observation Wizard Improvements

Brief explanation: The Observation Wizard enables users to select and filter objects of interest to them . Currently, the selection is done by object type, location, and magnitude in the sky. Further, the user can filter objects based on altitude and time-range when they are available. This tool can be further improved by providing the following features:

INDI Integration: Filter and sort by object size for Deep Sky Objects that have a physical width and height, unlike point-like sources like stars. Limit objects to fall within a particular percentage of the sensor. For example, M31 galaxy is very large and spans almost 3 degrees in the night sky. It would not fit inside the camera's 1x1 degree field of view (as calculated from INDI). Similarly, an object spanning on 5'x5' arcmins is too small in the camera.
Image Integration: The way the final list of objects are displayed should be modernized. Each object should have an image and also an Altitude-vs-Time plot next to it so that the user can quick identify what is the best time to observe this object. For large lists, this can be very CPU intensive and should be optimized accordingly.
Save/Load: Ability to save and load the wizard search parameters for future use so that the user does not always have to start from scratch every time they need to search for objects.
Export: Export the list of object to an external file or source in CSV and JSON formats.

Expected results:

Improved Observation Wizard Tool.
Proper integration with INDI & Ekos.

Knowledge Prerequisite: C++, Qt, Data Structures

Mentor: Jasem Mutlaq (KDE Web Chat: Jasem)

Project: FITSViewer & Photometry Improvements

Brief explanation: The FITSViewer is used to display FITS images as captured by cameras or opened by the user. It supports 8, 16, 32, and 64bit formats with either a single channel (Mono or Bayer) or RGB cube. The goal for this project is to provide efficient and intuitive controls for:

Noise Calculation: Calculate the overall Signal-to-Noise (SNR) radio for the overall image, or a specific subframe of the image.
Sky Glow Computation: Estimation of Sky Glow component in image of various exposures. Each captured image is affected by multiple sources of noise, only of which is the sky glow which in turn is affected by the atmosphere, pollution, and artificial sources (e.g. light). The objective is to propose to the user the optimum exposure time given the sky glow contribution to the image.
Mask Overlay: Ability to select custom mask over stars to aid in focusing and photometry.
Photometry: KStars includes SEP which can be used to extract sources from stellar images and also performs aperture photometry. A new tool should be developed to aid the users to perform photometric work with the images including reduction of images (darks & flats) with various optimization/algorithmic settings. Additionally, the tool provides means for aperture photometry calculations as well.

Since FITSViews typically deals with very high-resolution images, such calculations can be very computationally expensive. It is expected that a very efficient multi-threaded code to be developed to take advantage of all the available cores on the system and any hardware or instruction set optimizations to achieve the smoothest user experience. Expected results:

Improved Histogram Tool.
SNR, Sky Glow, and Photometry calculations.
Photometric reductions. Aperture photometry.

Knowledge Prerequisite: C++, Qt, Threading, Data Structures

Mentor: Jasem Mutlaq (KDE Web Chat: Jasem)

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: Jasem Mutlaq (KDE Web Chat: Jasem)

Project: KStars Testing

Brief explanation: KStars is built on a relatively large number of C++ classes, grouped in the following categories: sky objects and components, projection algorithms, graphics, timekeeping, widgets, Ekos automation, INDI client, FITS viewing, accessories and several library interfaces. Most of these constituting classes remain untested in terms of systematic and automatic verification. The objective of this project is to verify the code written in those classes at three levels: API, functionality and UI-based use case. In order to achieve this, the existing test code will have to extend its code coverage, report validation results and integrate seamlessly to the build recipe of the project.

The difficulty of this project is the requirement to create tests on legacy code and consolidate a test plan that reflects how the software is working instead of how we expect it to work.

Expected results:

Verify APIs: call each public class member using arbitrary test fixtures, control side effects by stubbing interfaces. This verifies code is executing in the data domain we expect, or fails for known reasons. As an example, the report will reveal how classes managing coordinates accept or reject numerical input.
Verify functionalities: ensure specific class interfaces return an expected result given a controlled set of input parameters. This verifies code is behaving as expected, or isolates known issues. As an example, the report will reveal which value of the Julian time classes managing timekeeping produce given different input objects embedding the same UTC time.
Verify use cases: ensure specific scenarios can be executed in the interface as presented in their documentation. This verifies procedures achieving useful results for the end-user remain stable, and controls how they evolve and improve during development.
Consolidate test reports and code coverage, and automate the execution of the test plan when building.

Bonus: generate videos of use cases for end-users automatically.

Level: beginner to intermediate

Knowledge prerequisites: C++, Qt, software testing and verification fundamentals

Mentor: Jasem Mutlaq (KDE Web Chat: Jasem)

Plasma Mobile Dialer

Plasma Mobile Dialer is a part of the Plasma Mobile project developed by KDE. Additional details could also be found in the developer documentation.

Project: Visual voicemail support

Brief explanation: KDE Gitlab issue

As described in the KDE GitLab, it is possible to reuse the so-called vvmd daemon that retrieves Visual voicemail. It provides environment-agnostic D-Bus interfaces. The draft for the Qt wrappers is also there. The integration could be implemented as part of the org.kde.telephony QML plugin or as a separate QML plugin. After that, the user interface could be written in QML with Kirigami components library for the plasma-dialer side. The task is mostly to propose and implement an appropriate graphical user interface.

Expected results: An additional tab/page for the dialer where you could listen to voicemail messages

Knowledge prerequisites: QML, Kirigami (mostly), C++, Qt, D-Bus IPC (to interact with the existing daemon), CMake (project build system)

Duration: 175 hours

Mentor: Alexey (KDE Web Chat: aa13q)