SoK/Ideas/2022

Ideas

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, contact the developers and find out more about the particular suggestion you're interested in.

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 in the idea, 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.

You need to submit your proposal to season.kde.org before the deadline.

Sample project

Project type: Coding / Web Development / Promo / Translation

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: Something that you're totally excited about

Project type: Coding / Web Development / Promo / Translation

Brief explanation: Do you have an awesome idea you want to work on with KDE but it isn't 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 love

Knowledge Prerequisite: Probably C++ and Qt, but it 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.

Plasma Sound Design

Project type: Sound Design

Brief explanation: The goal of this task is to create a new sound theme that will be used on KDE Plasma for many purposes. For more information, please check this task.

Expected results: At the end we expect Plasma to have a sound theme for many desktop actions, including but not limited to notifications, startup/shutdown jingle, alerts, and so on. We need 20 sounds in total, and most of them, with the exclusion of startup/shutdown jingles, should be about 1 second long.

Knowledge Prerequisite: Knowledge in sound design and/or music production. You'll also need to know how to use any FLOSS (Free/Libre and Open Source Software) music production software of your liking.

Mentor: Guilherme Marçal Silva - You can contact your mentor by making a comment on this Phabricator task. For that, you'll need a KDE Identity account. On the Phabricator task, you can see more details of what you have to do.

KDE Apps packaging as Flatpak for Flathub

Project type: Coding and Packaging

Brief explanation: We currently have Flatpaks recipes for a lot of KDE Apps (https://invent.kde.org/packaging/flatpak-kde-applications) but only some of them are available on Flathub (https://flathub.org/apps/search/org.kde). You will work on submitting missing KDE Apps to Flathub while fixing the issues that come up during the submission review. Once you've understood the process better, you may start working on tooling to help maintain KDE Apps as Flatpaks in both Flathub and KDE CI/CD infrastructure in GitLab.

Expected results: Submit a couple of KDE Apps to Flathub and develop fixes for the issues found during review.

Knowledge Prerequisite: C++, Qt, CMake, Bash, Python (basic knowledge in at least two of those is recommended)

Mentor: Timothée Ravier. Reach out to https://matrix.to/#/#flatpak:kde.org.

Permission management for Flatpak Apps in Discover

Project type: Coding and design

Brief explanation: We currently have Flatpak support in Discover. Flatpaks can have access to files, sockets, etc. However, those permissions are not currently displayed or manageable from the user interface. We thus want to add support for managing Flatpak application permissions directly in the Discover user interface. This project would look a lot like what's currently possible with Flatseal (See https://github.com/tchx84/flatseal and https://flathub.org/apps/details/com.github.tchx84.Flatseal).

Expected results: Installing a Flatpak application prompts the user for confirmation for requested permissions and allows them to manage given permissions after installation.

Knowledge Prerequisite: C++, Qt, CMake (basic knowledge in C++ and Qt is recommended)

Mentor: Timothée Ravier, Aleix Pol. Reach out to https://matrix.to/#/#plasma-discover:kde.org.

Notification support in Tokodon

Project type: Coding and design

Brief explanation: Tokodon is a small Mastodon client application written with Kirigami. Currently, the notification view is missing and will need to be fetched using the Mastodon REST API and a UI will need to be built to display the notification. For displaying new incoming notifications, the backend already exists and it should be simple to use KNotification to display them to the user.

Expected results: Implement notification view and display new notifications when they appear.

Knowledge Prerequisite: C++, Qt, CMake (basic knowledge in C++ and Qt is recommended)

Mentor: Carl Schwan. Reach out to https://matrix.to/#/#plasma-mobile:kde.org.

Improving GCompris

Project type: Coding or documentation

Brief explanation: GCompris is a high quality educational software suite, including a large number of activities for children aged 2 to 10.

Expected results: The aim of this year is either to come with your own idea a whole new activity or taking one from our ideas list. A great help would also be to review and improve our wiki which over the year could be partly outdated.

Here is the page containing new ideas: https://phabricator.kde.org/project/view/142/

Here is the page containing improvements that can be done: https://phabricator.kde.org/project/view/144/

Here is a task which does not relate to a GCompris activity. It is python and aims to create a better user manual. https://phabricator.kde.org/T15157

Knowledge Prerequisite:

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: Provide a timeline in your application. If you haven't contributed yet please read http://gcompris.net/wiki/GSOC_newcomers, http://gcompris.net/wiki/An_exercise_for_new_contributors and http://gcompris.net/wiki/Reviewing_an_activity

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

Feel free to contact us either on irc, kde webchat (https://webchat.kde.org) or by mail ([email protected])

Mentors: Emmanuel Charruau (IRC: allon), Harsh Kumar (IRC: hadron43)

Improving UX for KDE Connect iOS Internal Error

Project Type: Coding and Design

Brief Explanation: KDE Connect enables communications between devices, and we are bringing it to iOS. As it is still in the early stages, some internal errors are not effectively communicated to the end-users/developers (they can only hear a strange sound and find more information about why in the dev console). We have some ideas on how to fix this issue and documented it in https://phabricator.kde.org/T15171, but you are welcome to suggest other options.

Expected Results: Replace all uses of soundAudioError and soundAudioToneBusy with something more helpful for users/developers and close the Phabricator task.

Knowledge Prerequisite:

Basic understanding of Swift, Objective-C, or equivalent
Experience with, or interest to learn git/SwiftUI

Suggested application actions:

Take a look at the KDE Connect iOS app (compile from source or installed from [TestFlight]) and its [source code].
Figure out what "internal error" system we're talking about here, and how it's communicated to the end user.
Identify the potential usability improvements that could be applied to the current "internal error" system.
Propose improvements, how to implement them, and how they could fit into improving the system.
Discuss with the mentors on everything above to be put into a cohesive proposal for your application.

Mentor: Lucas Wang, Apollo Zhu. Reach out to https://t.me/joinchat/AOS6gA37orb2dZCLhqbZjg or https://matrix.to/#/#kdeconnect:kde.org

Investigate Feasibility of KDE Connect for watchOS

Project Type: Coding, Design, and Documentation

Brief Explanation: KDE Connect enables communications between devices, but should watchOS be one of the supported platforms? The iOS UI should theoretically work on watchOS with minimum effort as it is written in SwiftUI, but we are unsure what are the capabilities and limitations there are on watchOS and how those would impact KDE Connect watchOS.

Expected Results: Publish a written report (and potentially code) for what KDE Connect watchOS would be like: how useful it will be, how users interact with it, how we can potentially implement it, when do we know it’s ready for beta testing/release (minimum viable product), etc.

Knowledge Prerequisite:

Knowledge of git, Swift or Objective-C, and experience with SwiftUI or WatchKit
Access to an Apple Watch (simulators and physical devices usually behave differently)

Suggested application actions:

Take a look at the KDE Connect iOS app (compile from source or installed from [TestFlight]) and its [source code].
Familiarize yourself with what kind of a user experience the KDE Connect series of apps is aiming to deliver
Think about how watchOS can fit into that.
Do some digging on if this is even technologically possible (maybe not a standalone KDE Connect, but companion for iOS app?)
Think about the modifications and steps needed to make this possible, perhaps the iOS client needs to be altered too?
Communicate with the mentors on your ideas and findings to the points above to produce a cohesive proposal for your application.

Mentor: Lucas Wang, Apollo Zhu. Reach out to https://t.me/joinchat/AOS6gA37orb2dZCLhqbZjg or https://matrix.to/#/#kdeconnect:kde.org

Document KDE Connect Network Packages

Project Type: Documentation

Brief Explanation: KDE Connect enables communications between devices, but there isn't any documentation/specification on the protocol it uses to communicate. This was one of the main challenges we had when we first started to develop KDE Connect iOS, and is still helpful to have as KDE Connect iOS lacks many of the functionalities of other KDE Connect clients.

Expected Results: Produce a complete listing of all network packets, their parameters, descriptions, a sample packet for each kind, and any other useful information.

Knowledge Prerequisite: Basic understanding of Swift, Objective-C, Java, and/or C++ (especially if you would like to document support status across all 3 KDE Connect implementations).

Suggested application actions:

Take a look at the KDE Connect iOS app (compile from source or installed from [TestFlight]) and its [source code].
Figure out what these JSON packets are and why they're being sent across devices.
^ The last step was probably a bit confusing for a while, perhaps the documentation could be clearer?
Identify the current unclear/unoptimized portions of the documentation.
How can we improve it? More text? visuals? Videos??
Discuss with the mentors on everything above to be put into a cohesive proposal for your application.

Mentor: Lucas Wang, Apollo Zhu. Reach out to https://t.me/joinchat/AOS6gA37orb2dZCLhqbZjg or https://matrix.to/#/#kdeconnect:kde.org