GSoC/2023/Ideas: Difference between revisions
| Line 163: | Line 163: | ||
'''Duration:''' 175 hours | '''Duration:''' 175 hours | ||
'''Mentor:''' Joseph P. De Veaugh-Geiss (@joseph:kde.org | '''Mentor:''' Volker Krause(@vkrause:kde.org), Nicolas Fella, Benson Muite | ||
) | '''Hardware Manager:''' Joseph P. De Veaugh-Geiss (@joseph:kde.org) | ||
===digiKam=== | ===digiKam=== | ||
Revision as of 12:19, 27 April 2023
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 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
Adding a Proposal
Note
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
Kalendar
Project: Calendar Invitation
Brief explanation: The goal is to make it possible to send calendar invitation from Kalendar and also handle incoming invitations. This includes showing the free busy information from the attendees. Part of this features are already implemented in the C++ core but needs to be hooked up in the UI and others will require more work.
Expected results: Being able to manage all your meetings with Kalendar and make sure this is unit tested :)
Duration: ~350 hours
Knowledge Prerequisite: C++ is highly recommended, this is a complex code base
Mentor: Carl Schwan and Claudio Cambra (contact us in #kalendar:kde.org on Matrix)
Project: Improved multiplatform support
Brief explanation: Kalendar works great on Linux, but due to our dependency tree it is tricky to get it to build on Windows, and we do not have any current builds for macOS. For this project you will work on improving our support for either or both of these platforms and helping them become first class citizens for Kalendar. This will likely involve working on related projects like Akonadi.
Expected results: Working daily builds of Kalendar on Windows and/or macOS, depending on chosen project duration.
Duration: ~175 hours for one platform or ~350 hours for both platforms
Knowledge Prerequisite: C++ and CMake will be used extensively
Mentor: Claudio Cambra and Carl Schwan (contact us in #kalendar:kde.org on Matrix)
Project: Mail integration
Brief explanation: The goal is to make Kalendar not just a great calendaring application, but also a great mail application. We have basic email lists and a basic viewer working, but there is a huge amount of work still to do here: threading, editing, sending, and a lot more. A lot of this will not have to be done from scratch thanks to Akonadi (i.e. email retrieval and sending), but a lot of it will (i.e. threading).
Expected results: Kalendar should be a nice mail app :)
Duration: ~350 hours
Knowledge Prerequisite: C++ is required, QML will be needed but can be learned on the go if one has some JS experience
Mentor: Carl Schwan and Claudio Cambra (contact us in #kalendar:kde.org on Matrix)
Project: Implement calendar availability
Brief explanation: The short version is that you will need to implement RFC 7953 in Kalendar. The long version is that this availability extension definde by this RFC allows to define available and unavailable time periods. This is then helpful when trying to schedule a meeting with someone (see above tasks) as you will then be able to see then and avoid scheduling a meeting at that time. Implementation you will first need to add support for this in KCalendarCore for it and then expose this to the user interface so that user can modify their availability.
Expected results: Being able to configure my availability in Kalendar
Duration: ~175 hours
Knowledge Prerequisite: C++ and QML is recommended
Mentor: Carl Schwan and Claudio Cambra (contact us in #kalendar:kde.org on Matrix)
Project: Accessibility improvements
Brief explanation: It is a general KDE goal to make our applications accessible to everyone, including those who may require using their computers with keyboard navigation and screen readers. Kalendar needs a lot of work in this regard, particularly regarding navigation within the calendar views and around the application.
Expected results: Keyboard navigation throughout the entirety of Kalendar is expected, as well as use with screen readers. Further ideas for accessibility-related improvements are a big plus.
Duration: ~175 hours
Knowledge Prerequisite: QML will be required for this task, and you will likely need to use some C++ too.
Mentor: Claudio Cambra (contact me in #kalendar: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]
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]
Sustainability
Project: Measuring Energy Usage Remotely with Online Portal
Brief explanation: The goal of this project is to create an online portal that allows developers to remotely access and control the energy measurement lab at KDAB Berlin, enabling them to upload Standard Usage Scenario scripts and obtain data from the power meter.
The related issue to this project : https://invent.kde.org/teams/eco/sustainable-software-goal/-/issues/3
Expected results: Developers can upload Standard Usage Scenario scripts and obtain data from the power meter remotely.
Knowledge Prerequisite: React/Django(Any web framework), Networking/Knowledge of tunneling, Task scheduling and Energy Measurement process.
Duration: 175 hours
Mentor: Volker Krause(@vkrause:kde.org), Nicolas Fella, Benson Muite Hardware Manager: Joseph P. De Veaugh-Geiss (@joseph:kde.org)
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: Improve Items Properties Management
Brief Explanation: the goal of this project is to improve the Items properties management. digiKam Properties (as Tags, Color Labels, Rating, Pick Labels, etc.) and Metadata entries (as Exif, Iptc, and Xmp tags) must be copiable between one item to other ones. Drag and drop and clipboard key features must be supported to make these operations. For the copiable Metadata entries, a preferred list of tags must be configurable to simplify workflow users.
Expected Results:
Provide new options to copy digiKam properties or metadata entries between items. Write unit-tests, and documentation.
Bugzilla Entries:
- Allow to apply the previously assigned tag to a new image
- Easily copy properties from one image to another one
Duration: 175 hours
Knowledge Prerequisite:
- C++, Qt API, GUI, CMake, metadata, database
Mentors: Thanh Trung Dinh ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])
Project: Add Automatic Tags Assignment
Brief Explanation: the goal of this project is to assign automatically a tags to items by contents analysis using deep learning. Places, Animals, Plants, Scene Type, Events, etx, must be recognized and corresponding keywords must be generated to be be stored in database and assigned to items. This kind of feature must be available as Maintenance tool, Batch Queue Manager tool, or from Captions sidebar.
Expected Results:
Provide new tool for auto assignment of Tags to items. Write unit-tests, and documentation.
Bugzilla Entries:
- Detecting black & white image
- Objects / Forms / Monuments / Context detection and recognition using Deep Learning
Duration: 175 hours
Knowledge Prerequisite:
- C++, Depp Learning, OpenCV, Qt API, GUI, CMake, metadata, database
Mentors: Thanh Trung Dinh ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])
Project: Port to Qt6::Multimedia Framework
Brief Explanation: digiKam manage video as photo and it's can play the video using QtAV framework, a software component based on FFMpeg 4 API. QtAV is not maintained since few months and not ported to Qt6/FFMpeg 5. Even if digiKam team has back-ported the QtAV source code and ported the implementation to Qt6/FFMpeg5, the maintenance of this code is very complex and needs a lots of man power. As since Qt version 6.4, QtMultimedia support FFMpeg as multi-platform backend, it become a solid alternative for the future.
Expected Results:
Port all implementation using QtAV API to play and deal with the video media in digiKam. Write unit-tests, and documentation.
Bugzilla Entries:
- No sound on AppImage previews
- Video stutters when played with MP3 audio track
- After create a Video SlideShow media as mp4 will not be integrated
- digikam uses abandoned library incompatible with ffmpeg 5.0
Duration: 175 hours
Knowledge Prerequisite:
- C++, FFMpeg, Qt6 API, GUI, CMake, Video Format
Mentors: Thanh Trung Dinh ([email protected]), Maik Qualmann ([email protected]), and Gilles Caulier ([email protected])
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: 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: 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: TBD
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
Community Health
Project: Improve Mining Workflow and/or Create A Qt Application for Monitoring Open Source Project Community Health
Brief explanation: Community health has featured in a number of presentations related to KDE including a blog post and an Akademy presentation. There are a number of tools for monitoring community health including ComDaAn and Git2net. Most of these tools do network analysis on repository information. Related tools include KGraphViewer and SNAP. RKward could also be helpful.
Expected results: Easier monitoring of KDE projects and open source projects KDE depends on.
Duration: ~350 hours
Knowledge Prerequisite: C++ is highly recommended, but other languages welcome. Interest in data mining, reproducible workflows
Mentor: Benson Muite [email protected]
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.