Toggle the table of contents

GSoC/2022/Ideas: Difference between revisions

From KDE Community Wiki

< GSoC‎ | 2022

Latest revision as of 12:34, 16 April 2022

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.

digiKam

digiKam is an advanced open-source digital photo management application that runs on Linux, Windows, and MacOS. The application provides a comprehensive set of tools for importing, managing, editing, and sharing photos and raw files.

Project: New plugin to process OCR

Brief Explanation: the goal of this project is to implement a new generic DPlugin to process images in batch with Tesseract. It's a C++ framework to make Optical Characters Recognition. This plugin must be able to run over images automatically and record detected text in image metadata for post-processing, as described in this bugzilla file:

https://bugs.kde.org/show_bug.cgi?id=117629

Expected Results:

Provide a new optional Generic Tesseract based DPlugin available in digiKam and Showfoto to run OCR automatically. Write unit-tests, and documentation.

Duration: 175 hours

Knowledge Prerequisite:

C++, Qt5 and Qt6 API, Tesseract, CMake, OCR Image Processing

Mentors: Thanh Trung Dinh ([email protected]), Minh Nghĩa Dương ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])

Project: Improve Image Quality Sorter with Neural Network

Brief Explanation: digiKam has powerful feature to sort images by quality and register items with flags in database for future post processing. Analyzed image qualities are noise, focus, exposure, and compression. Algorithms used in background are revised in 2021 and give good enough result but we can add new criteria of quality based on Neural Network analysis, as for ex to detect the composition of image.

Expected Results:

Provide an update of Image Quality processing using OpenCV DNN engine. Write unit-tests, and documentation.

Duration: 175 hours

Knowledge Prerequisite:

C++, Qt5 and Qt6, DNN, OpenCV, Image Processing

Mentors: Thanh Trung Dinh ([email protected]), Minh Nghĩa Dương ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])

Project: Port Continuous Integration/Deployment to Gitlab/Craft DevOp Infrastructure and Notarize Bundles for Stores

Brief Explanation: digiKam use KDE/Jenkins to process Continuous Integration for Linux/BSD target. Windows and MacOS target do not work. With the recent migration to Gitlab, DevOps gain simplicity and become more powerful. The goal of this project is:

Prepare Craft infrastructure to handle digiKam and all required dependencies (this is more and less already done as other application as Krita already build with Craft).
Setup Continuous Integration and Continuous Deployment authorizations with Gitlab/Craft.
Compile digiKam from MacOS and Windows using CI.
Fix compilation with XCode and VisualC++ if necessary using CI.
Configure the signature of bundles.
Configure the application rights under MacOS and Windows (access to camera device, access to disks).
Construct the bundles.
Test if all is fine at run time on target computers.
Deploy the bundles to the Windows and MacOS stores (Kate editor do it already).

Relevant bugzilla entries are listed below:

Link to Craft DevOps toolkit:

https://community.kde.org/Craft

Mail from KDE admin about CI/CD changes with Gitlab:

https://mail.kde.org/pipermail/kde-core-devel/2022-January/091542.html

Expected Results:

Using modern Gitlab/Craft DevOps infrastructure to compile digiKam. Provide notarized bundles for Apple and Microsoft stores.

Duration: 175 hours

Knowledge Prerequisite:

C++, CMake, Qt5 and Qt6, Gitlab, DevOps, Craft.

Mentors: Thanh Trung Dinh ([email protected]), Minh Nghĩa Dương ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])

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]

Project: Improve Okular for Android

Brief explanation: Okular has an Android version it needs some improvements.

Poppler, the library that Okular uses for PDF rendering is missing a "find me a font given a font name" backend for Android. We should use new new Font API introduced in Android API 29 to do that.

The Icons in Okular-Android are not being rendered, there is something in KDE Frameworks interfering.

You should have an Android device with Android >= 10 for testing

Expected results: New Font API in poppler and icon rendering fixed.

Knowledge prerequisite: C++

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

Plasma

Plasma modernise system settings modules

Brief explanation: KDE is an extremely old project which has built up a lot of configuration modules (KCMs) for settings and hardware which you can see in systemsettings. Many of these have been ported to QtQuick our modern UI toolkit along with a visual refresh, but many have not. A full list can be found here: https://phabricator.kde.org/tag/plasma_kcm_redesign/ The applicant is free to choose 1-4 modules (depending on module size and complexity) to make up a full GSOC.

Expected results Modules of the applicants choosing ported to QtQuick with a modern UX working flawlessly with similar feature parity.

Duration: 175 hours

Plasma form factor integration of system dialogs

Brief explanation: On this project you will be improving the integration of different Plasma components into different form factors. By adopting the SystemDialog component, we will be able to integrate them visually on mobile, Big Screen and others.

Expected results: The SIM PIN, PolKit (i.e. admin password prompt), KWallet and Network Manager will appear native on Plasma Mobile. As a stretch goal we could work out how to also benefit from this work on Plasma Big Screen which targets TV UXs.

Knowledge Prerequisite: QML and C++. Knowledge of Kirigami will come in handy.

Duration: 175 hours

Mentor: Aleix Pol Gonzalez, @apol:kde.org

Hardware based navigation of Maliit On-screen keyboard

Brief explanation: On this project you will be improving the Maliit on-screen keyboard to allow selection of keys and other keyboard elements, via hardware input such as gamepads, analog joysticks, or arrow keys, for use in Bigscreen and similar situations.

Expected results: Keys, word completion, and other core features of the keyboard should be controllable from hardware input. There should be clear visual indication of what key is currently selected, selection of word suggestions, and what action pressing hardware buttons (x, y, b, a, triggers, etc…) will result in. The OSK should detect what hardware configurations are currently in use, and display or not display hints as appropriate.

Knowledge Prerequisite: QML and C++

Duration: 175 hours

Mentor: Rodney Dawes KDE Web Chat: dobey)

NeoChat

Spaces Support in NeoChat

Brief explanation: Spaces are used to group matrix rooms together, for example all rooms belonging to the KDE Community. The project's goal is to enable NeoChat to support spaces.

Expected results: NeoChat can show spaces and ideally also create and edit them

Knowledge Prerequisite: QML and C++

Duration: 350 Hours

Mentor: Tobias Fella and Carl Schwan, https://matrix.to/#/#neochat:kde.org

Kalendar

Meeting management in Kalendar

Brief explanation: Kalendar currently doesn't handle many aspects of the wonderful corporate life full of meetings. We currently don't handle showing the free busy time of the participants to a meeting, we also can't let user edit their availability.

Expected results: Kalendar can be used to manage your meetings

Knowledge Prerequisite: QML and C++

Duration: 350 Hours

Mentor: Carl Schwan and Clau Cambra, https://matrix.to/#/#kalendar:kde.org

Krita

Krita is a digital painting application, used by millions of people all over the world. For Google Summer of Code, we expect students to already have contributed to Krita by building the application and submitting merge requests for some bug fixes. Note that some projects also demand a good knowledge of algorithms and skill in doing research.

Project: Export an Image to SVG

Brief explanation: Right now, Krita can only save to SVG one layer at a time. It would be good if Krita was able to save the whole document to SVG: vector layers as groups, and raster layers as bitmaps. To be determined what should happen to other types of layers. Link: https://bugs.kde.org/show_bug.cgi?id=404834

Expected results: File -> Save, File -> Save As, File -> Export should have an option to save to SVG. A file saved into SVG should have all raster and vector content from the document, but not the filter/fill layers.

Knowledge Prerequisite: C++. Qt. CMake

Duration: ~175 hr

Mentor: Wolthera van Hövell

Project: Add Benchmarks to the Krita executable

Brief explanation: currently, to run benchmarks, people have to have a build from source. To see whether particular hardware gives a problem, we should add a function that generates a benchmark file complete with all hardware and OS info as well as what is being done. This should be separate both from the debug output and the krita log.

Expected results: integration of all benchmarks that currently run standalone from the command line into Krita. A dialog to select which benchmarks to run, and the output available after running the benchmark as a file and shown inside the benchmark dialog.

Knowledge Prerequisite: C++, Qt, CMake

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

Mentor: Dmitry Kazakov

Project: Texture Each Dab instead of the whole Stroke

Brief explanation: Implementing texturing brush dabs instead of texturing whole stroke. (Just like Opacity is about the whole stroke and Flow is about the opacity of just one brush dab) Link: https://bugs.kde.org/show_bug.cgi?id=375155

Expected results: Texture is applied only on brush dabs. See https://bugsfiles.kde.org/attachment.cgi?id=135342

Knowledge Prerequisite: C++, Qt, CMake

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

Mentor: Dmitry Kazakov

Project: Add film-like adjustment

Brief explanation: Film-like is a name of a special adjustment curve that allows the user to control the contrast without having hue shifts that often happen when using standard HSV Adjustment curves. Note: you will need to do quite a bit of research first. Link: https://bugs.kde.org/show_bug.cgi?id=385845

Expected results: A new filter with Film-like adjustment.

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~175 hr

Mentor: Wolthera van Hövell

Project: Pixel-perfect ellipses

Brief explanation: In Krita, there is no way to draw a pixel-perfect ellipse using the Ellipse Tool. Most probably the appropriate solution would be to create a new type of Brush Engine that would behave in a pixel-perfect way. Note: this is more complicated than you might think at first. Link: https://bugs.kde.org/show_bug.cgi?id=387242

Expected results: A way to draw a pixel-perfect ellipse using the Ellipse Tool. The new Brush Engine must also behave in a pixel-perfect way creating lines and other shapes.

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~175 hr

Mentor: Ivan Yossi

Project: Adding support for high-channel depth brush tips

Brief explanation: Currently, brush tips are 8 bits and based on QImage objects. With the advent of 16 bit/channel and 32 bit/channel support in QImage, we can start supporting higher bit depth brush tips. The 16 bit/channel GBR format from Cinepaint is not so relevant: we should support EXR and PNG for predefined brush tips and extend the autogenerated brush tips to support higher channel depths as well.

Expected results: A gui to select the channel depth when creating brush tips, Loading of high-channel depth brush tips, Support for high-channel depth brush tips when painting

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~350 hour

Mentor: Halla rempt

Project: Extend Arrange Docker to support alignment and distribution of Layers

Brief explanation: Currently, the arrange docker only supports aligning and distributing vector objects of a singlet vector layer. This project aims to extend the arrange docker support for layers and masks too.

Expected results: All the current operations available in Arrange docker could be done with the layers.

Knowledge Prerequisite: C++, Qt, CMake

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

Mentor: Agata Cacko

Project: "Enter Group" and "Vector Pattern" GUI functionality for Krita vectors

Brief explanation: Currently, to modify grouped shapes the user have to always ungroup them. The goal of the project is to implement a UIX for modifying the shapes inside the group without ungrouping them (see Inkscape). The user should be able to "enter" a group, which would limit his actions only to the shapes inside a selected group (perhaps, shapes outside the group should also be grayed-out?).

The feature is tightly related to the "SVG Vector Patterns" functionality. Krita can already render vector patterns perfectly fine, but there is no GUI for creating/modifying them. Pattern fills should be editable from the shape editor tool option widget.

Expected results:

The user can Enter/Leave group and modify shapes inside it without ungrouping
Shapes outside the currently entered group are grayed-out (disputable?)
The user can create/modify vector patterns using Tool Options docker of DefaultTool (see KoFillConfigWidget)

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~350 hour

Mentor: Dmitry Kazakov

Project: Improve texture editing pipeline and add DDS file format

Brief explanation: It would be nice to have support for DDS textures file format, which is rather popular among game developers. There are also a lot of nice small features which could improve texture creator's workflow a lot: https://phabricator.kde.org/T12767

Expected results:

Krita can load and save DDS textures
Mipmap generation GUI
cubemaps, 3D-textures, texture arrays editing GUI

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~175 hr

Mentor: Wolthera van Hövell

Project: Per-document resources docker

Brief explanation: Since Krita 5, Krita files can contain resources (brushes, gradients, palettes, etc.) that are specific for a certain document. This project entails creating a new docker that shows those resources and that allows adding and removing those resources from a document. If time permits, the document information dialog should also show the per-document resources.

Expected results: A new docker that shows the document's resources

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~175 hr

Mentor: Halla Rempt

Project: Clipping Masks

Brief explanation: Users are asking for clipping mask functionality that is compatible with Photoshop. This project entails implementing loading and saving clipping masks to and from PSD files and KRA files, adding a tool to create and edit clipping masks and writing documentation for the manual. See https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/

Expected results: Photoshop-compatible clipping masks

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~350 hour

Mentor: Dmitry Kazakov

Project: Action Recorder

Brief explanation: Krita used to have an action recorder: a system that would record all the user's actions, like painting, applying a filter and so on into a macro file that could be replayed. This system was disabled many years ago. You would need to design a generic system that integrates with Krita's 'strokes' framework and that would save all the user's actions to such a macro file, and then be able to replay this, both at native speed and at slowed-down speed. Note that this is different from the existing recorder which writes frames from the image's state to to an animation file.

Expected results: a working recorder and playback functionality

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~350 hour

Mentor: Dmitry Kazakov

Project: Generic Layer Tagging

Brief explanation: The layer properties dialog and layer docker should be extended with support for tagging. There should be a number of default tags, but the set of tags should be extensible. There should also be defined a number of default operational meanings for tags, like "do not render this layer to an exported image" for a "Draft" tag.

Expected results: A tagging system for layers

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~350 hour

Mentor: Halla Rempt

Project: Improve Compositions Docker's Batch Export Features

Brief explanation: The current Compositions Docker does feature exporting and batch exporting, but currently lacks configuration for image or animation export settings. It could use more control over how all compositions are exported.

Expected results: Configurable export settings for the composition docker, and API improvements to allow for reuse of existing export GUI window(s).

Knowledge Prerequisite: C++, Qt, CMake

Duration: ~175 hr

Mentor: Eoin O'Neill

KDE Connect

KDE Connect is a series of apps for a wide range of platforms that provides inter-device integration such as file and clipboard sharing, remote control, battery status sharing, and more.

KDE Connect project web site
KDE Connect Development Telegram Channel
KDE Connect Community Wiki
KDE Connect Userbase Wiki
KDE Connect Qt/Desktop client repository
KDE Connect Android client repository
KDE Connect iOS client repository
KDE Connect mailing list
IRC: #kdeconnect:kde.org & #kdeconnect:libera.chat

Project: Porting the KDE Connect iOS app to macOS

Brief explanation: KDE Connect iOS is one of the KDE Connect client apps, written in Swift (and some Objective-C) using native Apple development frameworks. Since the frontend of the app is written in SwiftUI, it is fairly modular for the iOS codebase to be altered to also include a macOS build target, turning it into a macOS native application.

The current version of KDE Connect for macOS is based on the Qt codebase, shared by the Linux, macOS, and Windows clients. However, the macOS version has remained in the “early beta” development stage since its initial development in 2018, and has seen a continuous stream of challenges:

The KDE Connect Qt client is currently written in the Qt 5 framework, which does not and likely has no plans to support the arm64 architecture on macOS, which will soon be the only architecture for new Macs going forward.
macOS updates have, on many occasions, introduced breaking changes to the D-Bus interface, breaking the app completely.
The Qt client’s interface and design language adhere much closer to the KDE Plasma desktop than the macOS design.
The Qt client uses the D-Bus, and is therefore not sandboxed, which the Mac App Store does not allow.

For the reasons above (and more), this project aims to adapt the current KDE Connect iOS codebase as the de-facto KDE Connect macOS client. The project would contain the following major portions under the overarching goal of modifying the existing KDE Connect iOS codebase to add macOS as a new native target:

Test and modify existing backend APIs calls (CocoaAsyncSocket, Security, OpenSSL, background activity and general LAN capabilities, etc.) to be compatible with macOS.
Investigation is needed for the Security framework as it might have different function calls on macOS
Investigation is needed for the CocoaAsyncSocket API as its behavior with background activity and resource usage is currently untested on macOS.
Design and modify the frontend SwiftUI codebase to adhere to macOS interface design elements and conventions.
Adapt the iOS app for widescreen and window behavior support
Implement file-browser support (secondary-click menu through Finder Sync Extension, directory access, etc.)
Implement features specific to the desktop clients of KDE Connect
Use macOS accessibility API for keyboard and mouse control (implement the Remote Input Plugin)
Run Command Plugin to execute macOS actions (command line, maybe Shortcuts?)

Prior to submitting your GSoC proposal, please take a thorough look around the KDE Connect iOS codebase and have some discussions with us (via the "contact" section below)!

Expected results: An optimized KDE Connect macOS client app, based on the KDE Connect iOS codebase

Knowledge Prerequisite: Swift, Objective-C, SwiftUI, Xcode, iOS, macOS

Duration: Exact commitment time depends on the scope of the project and how many Plugins the project wishes to cover. Estimated to be ≈175 hours for UI + backend + non lower-level Plugins, ≈300 hours if lower-level Plugins such as remote input, presenter pointer, notification sync, etc. are included on top of the ≈175 hours project.

Mentor: Lucas Wang. Reach out via the KDE Connect Development Telegram or KDE Connect Development Matrix (bridged with Telegram).

Project: Make KDE Connect iOS more inclusive

Brief explanation: KDE Connect is “Made for people like you. Open Source. Free to use. For any purpose. Forever.” But we’d like to extend the actively developing KDE Connect iOS client to be “for anyone” as well through the adoption of internationalization, localization, and accessibility best practices:

Other KDE Connect clients support multiple languages, but the iOS app is only available in U.S. English. Built with SwiftUI, KDE Connect iOS should be relatively easy to internationalize, but we need a way to export and send things needing translation to the KDE translation team, and import the translated material when ready. You might find this note helpful.
iOS provides the users with a lot of configuration options and ways to interact with their devices, such as larger font sizes, VoiceOver, full keyboard navigation, and more. We have been gradually adding small changes to different parts of the app to make it support different device configurations, but it’s far from perfect or complete. A full accessibility audit and dedicated effort to make the app equally easy to use will make KDE Connect iOS better for everyone—including those who don’t use assistive technologies regularly.

To learn more about accessibility and inclusion, see Apple’s resources on these subjects:

Expected results: Make KDE Connect iOS more accessible to people using assistive technologies like VoiceOver and more. Internationalize KDE Connect iOS to be fully localizable into other languages and set up a workflow to import and export localizations. Note that:

You are not required to localize the app yourself, but it can be helpful to think about how we can ensure localizers have all the information/context they need.
You should be regularly communicating with KDE Connect (iOS) users to identify barriers preventing them from having a great experience with the app, check up with them to measure the effectiveness of the changes implemented and make revisions with the additional feedback received.

Knowledge Prerequisite: git, Swift, SwiftUI, Xcode, iOS and its accessibility technologies. Familiarity with Objective-C and SVN can be helpful but is not required.

Duration: about 175 hours.

Mentor: Lucas Wang. Reach out via the KDE Connect Development Telegram or KDE Connect Development Matrix (bridged with Telegram).

GCompris

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

Project: Adding new activities to GCompris

GCompris has recently launched its version 1.0 with multiple datasets feature. Moving forward we are looking to add more new activities to GCompris.

Expected results: This year we aim to add some new activities to GCompris. For example, we lack activities in the science domain (chemistry, biology) which can be proposed. We have a few ideas to propose but these are just ideas.

You can have a look at our GCompris board to get some ideas about port of activities too.

Programming turtle: https://phabricator.kde.org/T15272

Find a number corresponding to a position on a graduated bar: https://phabricator.kde.org/T15274

Adding using 10's complements to add numbers: https://phabricator.kde.org/T15276

Grammatical analyses: https://phabricator.kde.org/T15277

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

Basic knowledge of QML, JavaScript would be a plus.

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 or by mail ([email protected])

Duration: 175 hours.

Mentors: Emmanuel Charruau (IRC: allon), Harsh Kumar (IRC: hadron), Deepak Kumar (IRC: deepak)

Project: Launch activities directly in command line

This project aims to implement new command line tools to Gcompris.

Expected results: This project aims to implement functionality to launch any Gcompris activity from the command line. The users should be able to launch activities with its name from the command line. If any activity has multiple datasets they should be able to choose the settings for the multiple dataset before launching the activities.

You can check more about the project details over here: https://phabricator.kde.org/T13899

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

Basic knowledge of QML, JavaScript would be a plus.

Good knowledge of C++ would be required.

Be able to build the Qt Quick version of GCompris.

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

Duration: 175 hours.

Mentors: Emmanuel Charruau (IRC: allon), Harsh Kumar (IRC: hadron), Deepak Kumar (IRC: deepak)

Retrieved from "https://community.kde.org/index.php?title=GSoC/2022/Ideas&oldid=93940"