GSoC/2018/Ideas: Difference between revisions
Add Choqok idea |
Combine duplicated KDevelop sections |
||
(65 intermediate revisions by 28 users not shown) | |||
Line 1: | Line 1: | ||
[[File:Mascot konqi-app-presentation.png|thumbnail|right|[[Konqi]] is giving a lesson!]] | [[File:Mascot konqi-app-presentation.png|thumbnail|right|[[Konqi]] is giving a lesson!]] | ||
See also: [[../../| | See also: [[../../|GSoC Instructions]], [[../../2017/Ideas|Last year ideas]] | ||
== Guidelines == | == Guidelines == | ||
Line 24: | Line 24: | ||
==== Project: ==== | ==== Project: ==== | ||
'''If appropriate, screenshot or | '''If appropriate, screenshot or another image ''' | ||
'''Brief explanation:''' | '''Brief explanation:''' | ||
Line 58: | Line 58: | ||
'''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. | '''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. | ||
===digiKam=== | |||
digiKam is an advanced digital photo management application for Linux, Windows, and MacOS. | |||
* [http://www.digikam.org digiKam project web site] | |||
* [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist] | |||
* [https://plus.google.com/+digikam Google+ page] | |||
* [http://webchat.freenode.net/?channels=digikam #digikam IRC channel on Freenode] | |||
==== Project 1 : digiKam Web Services tools authentication with OAuth2 ==== | |||
'''Brief Explanation''': digiKam has many tools dedicated to sharing items on web services, as Facebook, Google Photo, Google Drive, SmugMug, etc... | |||
All tools use an older way to be authenticated through the web service using an external web browser instance to capture the token network session. This is a fastidious way to open a web service session. | |||
Currently, Flickr, DropBox, and Imgur tools use an embedded OAuth2 authentification without a web browser instance through O2 library for Qt. | |||
The goal of this project is to port all others web service tools to O2 library API. | |||
'''Expected results''': | |||
*Review code of current tools ported to OAuth2 | |||
*Review current implementation of tools and list all web services compatible with OAuth standard. | |||
*Plan the amount of work to port tools by order of complexity, and identify possible problems. | |||
*Port code for each tools step by step, by writing unit tests independently. | |||
*Test all tools with all use cases, depending of tool options. | |||
*Write documentation. | |||
'''Knowledge Prerequisite''': Network, OAuth, C++, and Qt5 | |||
'''Mentor''': Maik Qualmann and Gilles Caulier | |||
==== Project 2 : Added the possibility to manually sort the digiKam icon view ==== | |||
'''Brief Explanation''': digiKam has the possibility to sort the items in the icon view according to different criteria, for example by: name, date, file size, rating etc. Many digiKam users have long been wishing to manually sort the icon view. The bug report (https://bugs.kde.org/show_bug.cgi?id=91562) now has more than 700 votes. | |||
The goal of this project is to rearrange the sorting of items in the icon view by drag and drop. This sort must be stored in the database and must be retrievable like the other sort functions. | |||
'''Expected results''': | |||
*Review code of current sort functions and the icon view model. | |||
*Review current database schema of SQLite and MySQL. | |||
*Adding a column to SQLite and MySQL table to store manual sort order. | |||
*Write database upgrade procedure to port older digiKam databases. | |||
*Write code for reading and writing manual sort order to the database. | |||
*Write code for the manual item sorting in the icon view. | |||
*Test your implementation of manual sorting. | |||
*Write documentation. | |||
'''Knowledge Prerequisite''': Databases SQLite and MySQL, C++ and Qt5 | |||
'''Mentor''': Maik Qualmann and Gilles Caulier | |||
==== Project 3: Supporting Twitter and Amazon Drive services in digiKam export ==== | |||
'''Brief explanation''': There are many web services that digiKam can communicate with and export images to them. Following digiKam convection, we want to support Twitter and OneDrive export. | |||
Also, It would be great if we grouped web services in specific categories, for example: Facebook, Twitter, VK, G+, ..etc will be grouped in "Social Networks" category. the user can expand a category and check the boxes beside every service he wants to use and share an image to all selected service with the same status update. | |||
'''Expected Results''' | |||
*Reviewing currently supported web services code | |||
*Writing a client to connect to Twitter's API to be used to export images with status to it | |||
*Writing a client to connect to OneDrive API to export images and albums to it | |||
*Creating a dedicated widget to hold web services categories and categorizing each service to the right category | |||
*Supporting the ability to select multiple service and export to them at once | |||
*Writing unit tests for each new service | |||
*Writing docs for each newly created class | |||
'''Knowledge Prerequisites''': C++, Qt, Network, Restful API's | |||
'''Mentor''': Mohamed Anwer and Gilles Caulier | |||
=== Krita === | === Krita === | ||
[http://www.krita.org Krita]: digital painting for artists. It | [http://www.krita.org Krita]: digital painting for artists. It supports creating images from scratch from beginning 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 the following ideas. | 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 the following ideas. | ||
Line 66: | Line 130: | ||
Note that we're always open to ideas you bring in yourself: if you're passionate about something you've come up with yourself, that you want for Krita, that's a big plus for us. | Note that we're always open to ideas you bring in yourself: if you're passionate about something you've come up with yourself, that you want for Krita, that's a big plus for us. | ||
We also expect prospective students to submit at least three | We also expect prospective students to submit at least three patches for bugs or wishes or small features. We want to know how good you are! See https://phabricator.kde.org/T7724 for some smaller tasks that you could work on that are not bugs. | ||
==== Project: | ==== Project: Optimize multithreading in Krita's Tile Manager (make the hash table lockfree) ==== | ||
'''Brief explanation''': This is a hard-core project, only suitable for someone with deep knowledge of the problems of designing multi-threaded software. It involves Krita's core datamodel, where the tiles that compose image data are managed. the | '''Brief explanation''': This is a hard-core project, only suitable for someone with deep knowledge of the problems of designing multi-threaded software. It involves Krita's core datamodel, where the tiles that compose image data are managed. The main problem is that at the moment the core utilizes QReadWriteLock and QMutex a lot, which means that Krita painting performance stops scaling well, when the number of CPU cores becomes larger than 8. The goal of this project is to locate all the bottlenecks (there are at least 4 of them) and resolve them in a lock-free. One of the bottlenecks involves KisTileHashTable which is used to access the tiles. Since this touches the very core of Krita, a thorough test plan is essential. | ||
'''Steps to apply''': | |||
The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal: | |||
# Build Krita with unittests enabled | |||
# Install GNU Perf or VTune | |||
# Run FreehandStrokeBenchmark in a profiler and try to locate all the places where most of the locking/waits happen. The main one will be the hash table, but there are at least three more (your task is to locate them and add into your proposal!) | |||
# (optional) To test your coding abilities you can try to port one of the hash tables code from [https://github.com/preshing/junction Junction] library to Qt's primitives. If you don't feel overwhelmed with such code, you are perfectly fit for the project! | |||
# And feel free to contact Krita developers, if you have any question during these steps! | |||
'''Expected results''': No bottlenecks anymore! | '''Expected results''': No bottlenecks anymore! | ||
Line 80: | Line 152: | ||
==== Project: Extending Animation Support for curves ==== | ==== Project: Extending Animation Support for curves ==== | ||
'''Brief Explanation''': In Krita, you can already add curves that could be applied to some properties of a layer, like | '''Brief Explanation''': In Krita, you can already add curves that could be applied to some properties of a layer, like opacity, animating those properties. 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''': | '''Expected results''': | ||
Line 95: | Line 167: | ||
'''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. | '''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 | '''Expected Results''': A revamped and exciting shapes brush | ||
'''Knowledge Prerequisite''': | '''Knowledge Prerequisite''': | ||
Line 104: | Line 176: | ||
==== Project: Analysis of thoroughput of Krita Blending Modes and porting them to AVX2 ==== | ==== 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). | '''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). [https://github.com/VcDevel/Vc Vc library] supports AXV2 instructions, though we don't know to what extent, it might happen that you would need to extend the library itself to get the needed functionality. This is another hard-core project only suitable if you have a good deal of experience. | ||
'''Expected Results''': | '''Steps to apply''': The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal: | ||
# Build Krita with unittests enabled | |||
# Install GNU Perf or VTune | |||
# Run KisCompositionBenchmark under a profiler and see the hottest places of blending modes code | |||
# Check the code of "Normal" blending mode for float32 color spaces (KoOptimizedCompositeOpOver128), copy the file and try to create your own blending mode for float16 color space. Hint: the only thing you should do is to implement correct unpacking/packing code that would convert the values to 32-bit float and back. | |||
# If you don't feel overwhelmed with such code, you are perfectly fit for the project! | |||
# And feel free to contact Krita developers, if you have any question during these steps! | |||
'''Expected Results''': Float16 color spaces are ported to AVX, Integer8 and Integer16 colorspaces are ported to AVX2 | |||
'''Knowledge Prerequisite''': C++, SEE/AVX (read [http://www.intel.eu/content/www/eu/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html Intel's manual]) | '''Knowledge Prerequisite''': C++, SEE/AVX (read [http://www.intel.eu/content/www/eu/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html Intel's manual]) | ||
'''Mentor''': Dmitry Kazakov (IRC: dmitryk|log) | '''Mentor''': Dmitry Kazakov (IRC: dmitryk|log) | ||
==== Project: Port generic code for not-so-popular blending modes to AVX ==== | |||
'''Brief Explanation''': In Krita we have a lot of blending modes, but only Normal and Alpha Darken are optimized and ported to AVX instructions. The reason for that is obvious, these two blending modes are the hottest and are used in every single image produced in Krita. But it doesn't mean that the other blending modes are less important for painters: they still use Multiply for painting shadows, and Linear Dodge for painting highlights, so they should also be fast! | |||
The good piece of news is that all these "non-popular" blending modes are implemented in Krita by means of a single class KoCompositeOpGenericSC, so, basically, as a result of your project, you should provide one class only! The bad piece of news is that this single class implements about a hundred of blending modes using C++ templates... so be prepared! :) | |||
'''Steps to apply''': The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal: | |||
# Build Krita with unittests enabled | |||
# Install GNU Perf or VTune | |||
# Run KisCompositionBenchmark under a profiler and see the hottest places of blending modes code | |||
# Check the code of "Copy" blending mode in KoCompositeOpCopy2 and try to port it into AVX for RGB8 colorspace. Use KoOptimizedCompositeOpOver32 as an example. | |||
# If you don't feel overwhelmed with such code, you are perfectly fit for the project! | |||
# And feel free to contact Krita developers, if you have any question during these steps! | |||
'''Expected Results''': "Copy" blending mode is ported to AVX, all the "generic" blending modes are ported to AVX | |||
'''Knowledge Prerequisite''': C++, SEE/AVX (read [http://www.intel.eu/content/www/eu/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html Intel's manual]) | |||
'''Mentor''': Dmitry Kazakov (IRC: dmitryk|log) | |||
==== Project: Optimize Soft, Gaussian and Stamp brushes to use AVX ==== | |||
'''Brief Explanation''': When the user draws a line in Krita, this line consists of thousands of small rectangular images (dabs) that are painted one over another. For each dab, Krita generates its own mask (depending on the stylus pressure and tilt) and uses this mask for filling the layer. It happens thousands of times per second, which makes mask generation code one of the hottest places in Krita. We already have AVX optimization for Default brush mask engine and it works 5(!) times faster than Gaussian engine and 3(!) times faster than the Soft engine. The goal of this project is to port the rest of non-optimized engines to use AVX via [https://github.com/VcDevel/Vc Vc library] and make them faster. | |||
'''Steps to apply''': The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal: | |||
# Build Krita with unittests enabled | |||
# Install GNU Perf or VTune | |||
# Run FreehandStrokeBenchmark under a profiler and compare the results for different types of brushes. You can see how faster Default brush tip is. | |||
# Check the code in kis_brush_mask_applicator_factories.cpp and try to implement your own version of FastRowProcessor for KisGaussCircleMaskGenerator '''without''' using any AVX. Even without any vector instruction, the brush will become much faster, just because it will use less virtual calls. | |||
# If you don't feel overwhelmed with the amount of C++ templates in your code, you are perfectly fit for the project! | |||
# And feel free to contact Krita developers, if you have any question during these steps! | |||
'''Expected Results''': Circular Soft, Gaussian and Stamp brush masks are ported to AVX-optimized code. Optionally, if there is enough time, rectangular brush masks are posted as well. | |||
'''Knowledge Prerequisite''': C++, SEE/AVX (read [http://www.intel.eu/content/www/eu/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html Intel's manual]) | |||
'''Mentor''': Dmitry Kazakov (IRC: dmitryk|log) | |||
==== Project: Partial canvas updates and region of interest (performance optimization for huge (20k+) canvases) ==== | ==== Project: Partial canvas updates and region of interest (performance optimization for huge (20k+) canvases) ==== | ||
'''Brief Explanation''': We already have an optimization for huge canvases, which is called Instant Preview. But it | '''Brief Explanation''': We already have an optimization for huge canvases, which is called Instant Preview. But it works 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 to the rest of the image. This project is targeted to optimize this case. | ||
'''Expected Results''': By the end of the summer we expect these features to be implemented: | '''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. | * 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 | * 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 | * Work Area Tool. The user should 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. | * (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. | ||
'''Steps to apply''': The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal: | |||
# Build Krita | |||
# Check the code in KisImage, pay attention to 'cropRect' parameter of the update calls. That is exactly what you need for limiting the updates in the work area tool | |||
# Try to write Work Area Tool: copy the code of KisToolCrop, connect it to Krita and make it override the cropRect parameter in KisImage. | |||
# If you manage to make a draft of Work Area Tool, most probably, you will manage to complete the whole project successfully! | |||
# And feel free to contact Krita developers, if you have any question during these steps! | |||
'''Knowledge Prerequisite''': C++, OpenGL | '''Knowledge Prerequisite''': C++, OpenGL | ||
Line 139: | Line 269: | ||
KDE Student Programs is the working group responsible for running Season of KDE and managing KDE's participation in Google Summer of Code, Google Code-In, and other mentorship programmes. | KDE Student Programs is the working group responsible for running Season of KDE and managing KDE's participation in Google Summer of Code, Google Code-In, and other mentorship programmes. | ||
=== GCompris === | === GCompris === | ||
==== Project: | ==== Project: One step closer to version 1.0 ==== | ||
'''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. | '''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''': | '''Expected results''': | ||
The aim of this year is to | The aim of this year is to work on the most important activities that we are missing to have a complete 1.0. You can find a list of tasks that you can work on at https://phabricator.kde.org/T7498. | ||
First phase is to check how the Gtk+ version was working, what could be improved and then create a proposal with a timeline explaining what you expect to do and the time estimation. It does not need to be a simple clone, improvements should be done when possible. | |||
Bitmap drawing activity and piano activities are already started in gsoc-tuxPaint/playpiano branches respectively. | |||
Note that for piano activities, it is a "package" containing multiple activities: play_piano, piano_composition, name_notes and play_rhythm. | |||
The other ones are to start from scratch. | |||
'''Knowledge Prerequisite''': | '''Knowledge Prerequisite''': | ||
Line 176: | Line 294: | ||
'''Application guide''': | '''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. | There are several info in the wiki: http://gcompris.net/wiki/Developer%27s_corner. | ||
Line 182: | Line 300: | ||
''Feel free to contact us either on irc or by mail ([email protected])'' | ''Feel free to contact us either on irc or by mail ([email protected])'' | ||
'''Mentors''': | '''Mentors''': Divyam Madaan (IRC: dmadaan), Emmanuel Charruau (IRC: allon), Johnny Jazeix (IRC: JohnnyJ), Timothée Giet (IRC: Animtim) | ||
==== Project: Unit test framework ==== | |||
==== Project: | |||
'''Expected results''': | '''Expected results''': | ||
The aim of this project is to build the base for unit testing for GCompris. The student will have to think on what we can test (qml, js...) and how we can put this in place. | |||
More information can be found in https://phabricator.kde.org/T7668. | |||
'''Knowledge Prerequisite''': | |||
Be interested in children’s education | |||
Be familiar with GCompris concept and content | |||
Basic knowledge in a programming language and CMake use (a 1 year school course is enough) | |||
Be able to build the Qt Quick version of GCompris | |||
Technologies used are CMake, C++, Qt. | |||
'' | ''Feel free to contact us either on irc or by mail (gcompris-devel@kde.org)'' | ||
'''Mentors''': | '''Mentors''': Divyam Madaan (IRC: dmadaan), Johnny Jazeix (IRC: JohnnyJ), Rudra Nil Basu (IRC: rudra), Timothée Giet (IRC: Animtim) | ||
=== KDE Partition Manager === | |||
=== Kopete === | === Kopete === | ||
Line 232: | Line 349: | ||
'''Mentors''': Vijay <[email protected]> (vijay_ on IRC), Kopete Mailing List <[email protected]> | '''Mentors''': Vijay <[email protected]> (vijay_ on IRC), Kopete Mailing List <[email protected]> | ||
=== LabPlot === | === LabPlot === | ||
[http://www.labplot.kde.org LabPlot] is a KDE-application for interactive graphing and analysis of scientific data. LabPlot provides an easy way to create, manage and edit plots and to perform data analysis. | [http://www.labplot.kde.org LabPlot] is a KDE-application for interactive graphing and analysis of scientific data. LabPlot provides an easy way to create, manage and edit plots and to perform data analysis. | ||
==== Project: Plotting of live MQTT data ==== | ==== Project: Plotting of live MQTT data ==== | ||
Line 270: | Line 363: | ||
'''Knowledge Prerequisite''': C++, Qt, (optional) knowledge and experience with MQTT | '''Knowledge Prerequisite''': C++, Qt, (optional) knowledge and experience with MQTT | ||
'''Mentor''': | '''Mentor''': Fábián Kristóf - Szabolcs (mailto:[email protected]) | ||
=== | ==== Project: Import of educational data sets available on the internet ==== | ||
'''Brief explanation''': There are many internet pages providing data sets for educational and study purposes for many different areas (astrophysics, statistics, medicine, etc.). Some tools used in the scientific area provide some "wrappers" for such online sources and allow the user to easily play around with those data sets in the applications whereas the technical details like fetching of data from the server and parsing are done completely transparent for the user. The goal of this project is to add similar functionality to LabPlot. There will be a wizard where the user can select from a thematically grouped list of data sets available online. The internal description of such an online data set should contain the URL with the actual file that needs to be downloaded and the settings for LabPlot's data parser (separator, column names and data types, etc.). The data fetched once should be cached so there is no need to fetch from the web again. Here we can have a look maybe at KStars for how to implement such a caching strategy and maybe even re-use some code from KStars. | |||
In addition to the list of pre-defined online sources, we need to elaborate how the user can add new online data sets (together with all the required parametrization) and publish the settings to make them available for everybody. | |||
'''Expected results''': We want to be able to easily import the educational data sets available on the internet. | |||
''' | '''Knowledge Prerequisite''': C++, Qt | ||
''' | '''Mentor''': Stefan Gerlach | ||
''' | ==== Project: Import of data from web-services ==== | ||
'''Brief explanation''': Brief explanation: This goal of this project is to extend the number of supported data sources by adding the possibility to import the data from web services (live and historical financial data, weather, etc.). Most web services expose their data via JSON. We need to add a "JSON filter" to LabPlot capable to connect to a web service, to fetch the data, to parse it and to import into LabPlot's internal data containers. In the GUI the user should be guided through the entry of the service URL, additional services parameters like API token, etc. and through the settings for the actual parsing (which JSON fields to consume and how). Also, it should be possible to refresh the data periodically like it is already possible for the live data (http://krajszgsoc.blogspot.de/2017/09/in-finish-line-but-not-in-end.html). The goal is also to provide a set of widely known web services so the user can select and import the data from a list of pre-defined services. In addition to this, we need to elaborate the possibility to "publish" the settings for a web-service done by the user and make them publicly available to every LabPlot user. | |||
'''Expected results''': Similar to the currently supported data sources (files, sockets, serial port, SQL databases) we want to import the data from web services and visualize it. | |||
''' | '''Knowledge Prerequisite''': C++, Qt, (optional) JSON support in Qt | ||
''' | '''Mentor''': Alexander Semke | ||
=== Kdenlive === | |||
[https://kdenlive.org Kdenlive] is a KDE-application for professional video editors. It supports hundreds of video formats and all the features you can expect from a non-linear video editor, including some advanced features like timeline preview rendering, proxy clips and more. | |||
=== Choqok === | === Choqok === | ||
Line 308: | Line 401: | ||
'''Application guide''': | '''Application guide''': | ||
Get in touch on IRC (#choqok). | Get in touch on IRC (#choqok). | ||
=== KStars === | |||
[https://edu.kde.org/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: Improving the reliability and usability of KStars==== | |||
Brief explanation: KStars has a mature codebase with well-written C++ for a desktop and a mobile client. The applicant would like to contribute enhancements by improving the sources (C++11/C++14 features, static code analysis, better testing in CI) and adding usability improvements to the desktop and the mobile version of KStars. | |||
'''Expected results''': | |||
* All findings of the static code analyzers will be fixed. | |||
* The C++ tooling will be integrated to Jenkins in KDE CI. | |||
* The desktop version of KStars will have usability improvements. | |||
* The build system (CMake) of the Android client will be enhanced. | |||
* Add new functionalities for telescope equipment control and camera capture and live streaming. | |||
'''Knowledge Prerequisite''': C++, Qt, Qml, Jenkins, static code analyzers. | |||
'''Mentor''': Jasem Mutlaq ([https://riot.im/app/#/room/#kstars:matrix.org Matrix]: Jasem) | |||
==== 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 an 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 support 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. | |||
'''Knowledge Prerequisite''': C++, Qt, Data Structures | |||
'''Mentor''': Jasem Mutlaq ([https://riot.im/app/#/room/#kstars:matrix.org Matrix]: Jasem) | |||
==== Project: Implementing Ekos in KStars Lite ==== | |||
'''Brief explanation''': Ekos is KStars premier tool for observatory control and automation. KStars Lite was successfully developed in GSoC 2016 and is available for Android phones and tablets. We would like to extend KStars Lite to include basic support for Ekos. Currently, KStars Lite supports basic telescope and capture controls, but it could be extended to support a richer experience for users who are performing observatory control and astrophotography. | |||
'''Expected results''': | |||
* Telescope floating motion controls including speed controls. | |||
* Like video feed display from supported devices. | |||
* Image capture with binning, count, exposure, ISO..etc controls similar to Ekos desktop client. | |||
* Focus controls. | |||
* Alignment using remote astrometry. | |||
'''Knowledge Prerequisite''': C++, Qt, QML | |||
'''Mentor''': Jasem Mutlaq ([https://riot.im/app/#/room/#kstars:matrix.org Matrix]: Jasem) | |||
==== 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. | |||
'''Knowledge Prerequisite''': C++, Qt, Django/Ajax or similar technology framework. | |||
'''Mentor''': Jasem Mutlaq ([https://riot.im/app/#/room/#kstars:matrix.org Matrix]: 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''': Akarsh Simha ([https://riot.im/app/#/room/#kstars:matrix.org Matrix]: kstar) | |||
=== Peruse === | |||
Peruse is a comic book reader application by KDE, which is designed to work both on touch based devices, and on the traditional desktop. Additionally, it has a tool called Peruse Creator which is designed to create comic books for use with Peruse and any other CBZ capable comic book reader. It has rudimentary support for the [http://acbf.wikia.com/wiki/Specifications Advanced Comic Book Format], which is a metadata container for comic book archives (CBR, CBZ and so on). | |||
See also the Peruse website for more detailed information: https://peruse.kde.org/ | |||
==== Project: Expand Creator's Abilities ==== | |||
'''Brief explanation:''' Peruse Creator is currently very simple, and will allow the user to create a CBZ comic book archive annotated with a subset of the [http://acbf.wikia.com/wiki/Specifications Advanced Comic Book Format] (ACBF) metainfo, such as authors, publisher information, characters and so on. It does not allow for the creation or editing of the viewport based navigation that ACBF describes, nor does it support the text layers system ACBF proposes for comic book translation. It also lacks editor components for a variety of the general metainformation ACBF suggests. | |||
Your project proposal should include explicit descriptions of which of these you wish to build support for, and how you propose to do so. It should further include timeframes for each. | |||
'''Expected results:''' A more capable Peruse Creator. | |||
'''Knowledge Prerequisite:''' C++ and Qt required, additionally QML/QtQuick knowledge is preferred | |||
'''Mentor:''' Dan Leinir Turthra Jensen ([email protected], IRC: leinir, Telegram and twitter: @leinir) | |||
==== Project: New Viewer Component ==== | |||
'''Brief explanation:''' The current viewer component for Comic Book Archives (CBR) in Peruse is a simple full-page viewer, which only supports page-by-page navigation. The [http://acbf.wikia.com/wiki/Specifications Advanced Comic Book Format] (ACBF) metadata container brings with it support for a viewport system, which describes how the application should present [http://acbf.wikia.com/wiki/Body_Section_Definition#Frame specific sub-sections of each page], as well as a system for [http://acbf.wikia.com/wiki/Body_Section_Definition#Jump navigating between arbitrary pages in the comic]. | |||
Your project proposal should include explicit descriptions of how you would suggest implementing this, as well as a schedule for the work. | |||
'''Expected results:''' A viewer component which is able to consume and display the viewport based navigation metadata from the ACBF container, as well as present the general metainformation to the user. | |||
'''Knowledge Prerequisite:''' C++ and Qt required, additionally QML/QtQuick knowledge is preferred | |||
'''Mentor:''' Dan Leinir Turthra Jensen ([email protected], IRC: leinir, Telegram and twitter: @leinir) | |||
=== KGpg === | |||
[https://utils.kde.org/projects/kgpg KGpg] is a frontend for GnuPG key management. | |||
'''Brief explanation:''' KGpg currently consists of one application with a very narrow external interface, which is available via DBus. The goal is to split out parts of the code into a static library that is used both by the KGpg binary as well as to-be-written unit tests, which should also cover at least all of the "[https://cgit.kde.org/kgpg.git/tree/transactions transaction]" classes. | |||
'''Expected results:''' unit tests that can be called via CTest, and are integrated into the KDE CI jobs | |||
'''Knowledge Prerequisite:''' basic C++, CMake, and GnuPG usage | |||
'''Mentor:''' Rolf Eike Beer ([email protected], IRC: Dakon) | |||
===KWin=== | |||
==== Multi-GPU support in Wayland session ==== | |||
'''Brief Explanation''': Currently KWin as a Wayland compositor can only render to outputs of the primary GPU. We want to allow multi GPU setups with more than one graphics card or simultaneous use of an expansion card and the internal graphics. For that, we need to query all available GPUs and handle them accordingly in our DRM backend. | |||
'''Expected results''': | |||
Query all available GPUs in DRM backend and their outputs. | |||
'''Knowledge Prerequisite''': C++, Qt5, basic knowledge of graphics hardware | |||
'''Mentor''': Roman Gilg (Email: [email protected]; IRC: romangg) | |||
==== Wayland graphical tablet input support ==== | |||
'''Brief Explanation''': Tablets are very different from mice, they have a lot more information about their current state and events. As such there are separate protocols for passing these events from raw hardware to the client. We need to add: | |||
* A protocol in kwayland to wrap the low level protocol | |||
* support in KWin to map libinput to sending wayland events to the right clients. | |||
* support in Qt's wayland client code to map wayland to Qt events that applications can use | |||
(this will mean collaborating not just within KDE code but also Qt) | |||
'''Expected results''': | |||
Working tablet support in all applications within a kwin wayland session. | |||
'''Knowledge Prerequisite''': C++, Qt5, | |||
'''Mentor''': David Edmundson ([email protected]) | |||
==== Activities support in KWin on Wayland ==== | |||
'''Brief Explanation''': KWin has one important regression when it comes to Wayland - lack of support for activities (mainly hiding windows that do not belong to the current activity). What needs to be done: | |||
* Implement a way for kwin to know which applications belong to which activities | |||
* Implement a way for applications to specify on which activities they are | |||
'''Expected results''': | |||
Working activities in KWin without any performance regressions. | |||
'''Knowledge Prerequisite''': C++, Qt5, | |||
'''Mentor''': Ivan Cukic ([email protected]) | |||
=== Plasma === | |||
==== Improve handling for touchpads and mice with Libinput ==== | |||
'''Brief explanation:''' [https://www.freedesktop.org/wiki/Software/libinput/ Libinput] is now used as the driver for input devices in most distros. However, System Settings does not present the user with good interfaces for configuring input devices with libinput. Currently, the only well-supported use case is for [https://bugsfiles.kde.org/attachment.cgi?id=108954 touchpads in a Wayland session]. For touchpads on X11, and mice on both X11 and Wayland, the user experience is sub-optimal or non-existent. | |||
'''Expected results:''' System Settings should expose good user interfaces for configuring both touchpads and mice when using Libinput, and for both Wayland and X11. | |||
'''Knowledge Prerequisite:''' C++, Qt | |||
'''Mentor:''' Nate Graham (Email: [email protected]; Telegram: @nggraham) | |||
'''Application guide''': | |||
* https://wayland.freedesktop.org/libinput/doc/latest/developers.html | |||
* https://bugs.kde.org/show_bug.cgi?id=383379 | |||
==== System Settings: Port keyboard input modules and expand scope to cover input method configuration ==== | |||
'''Brief explanation:''' System Settings' keyboard configuration module needs to be ported to Qt Quick based on reference designs provided by KDE's Visual Design Group. Additionally, the scope of keyboard input configuration needs to be expanded to cover input method configuration as well. This is both part of a larger drive to port the modules in the System Settings application to Qt Quick and modernize its UI design, as well as improve the text input configuration experience for a global audience. This project involves refactoring the existing System Settings module's code to be used as the backend for a QML-based UI and writing new backend code to configure the ibus or fcitx input method daemons. The UI design is expected to be refined during the course of the project in collaboration with VDG contributors. Interaction with other developers working on System Settings module ports in parallel is also expected. | |||
'''Expected results:''' System Settings should offer keyboard layout and basic input language configuration in a modern UI design. | |||
'''Knowledge Prerequisite:''' C++, Qt, Qt Quick/QML | |||
'''Mentor:''' Eike Hein (Email: [email protected]; IRC: Sho_; Telegram: @eikehein) | |||
'''Application guide''': | |||
* https://conf.kde.org/en/akademy2017/public/events/359 | |||
* https://www.youtube.com/watch?v=wE0KDabPfsQ | |||
* https://phabricator.kde.org/M112 | |||
==== Discover: fwupd integration ==== | |||
'''Brief explanation:''' Discover Software Center is in charge of offering different kinds of assets at the moment. Applications, Add-ons, etc as well as serving updates. At the moment it's still not able to update our devices' firmwares. There's a tool for GNU/Linux called FWUPD to do so: https://fwupd.org/developers | |||
Despite the description specifying plasma, the end goal is to provide a seamless solution to have your hardware's firmware up to date. | |||
If the proposal is too short, other improvements suggested to add to the idea will be welcome. | |||
'''Expected results:''' Plasma being great at having an up to date system, also with hardware. | |||
'''Knowledge Prerequisite:''' C++ and Qt, also notions of how glib works, to understand upstream FWUPD. | |||
'''Mentor:''' Aleix Pol: apol, @AleixPol, [email protected] | |||
=== Okular === | |||
==== Add support for showing and adding replies to sticky notes ==== | |||
'''Brief explanation:''' PDF files can contain replies to certain annotations, you would need to add support to Okular and potential poppler so that they show the same way they do on other PDF readers. Once they are shown and if there is enough time adding the capability to add replies is also welcome. | |||
'''Knowledge Prerequisite:''' C++, Qt | |||
'''Mentor:''' Okular developers https://mail.kde.org/mailman/listinfo/okular-devel | |||
'''Application guide''': | |||
* https://bugs.kde.org/show_bug.cgi?id=387834 | |||
==== Project: Verifying signatures of pdf files ==== | |||
'''Brief explanation:''' Okular should provide information about signatures if a pdf document has been signed. The poppler library used by Okular to render pdf files does support verification of signed pdf files and the retrieval of signature information. However, this functionality is not used by Okular. Goal of the project is to extend the Okular GUI to show whether a document is signed, and to show the signature details. | |||
Bonus points for any steps towards signing pdf files in Okular. | |||
'''Expected results:''' When opening a signed document, Okular should show that the document is signed, and whether the signature is valid, expired, etc. Detailed information about the signature(s) should be made available, through a new menu entry (all signatures) or by a context menu for individual signatures. | |||
'''Knowledge prerequisite:''' C++ and Qt, very little cryptography skills | |||
==== Project: Implement the FreeText annotation ==== | |||
'''Brief explanation:''' Okular implements various annotations from the pdf standard, but a few are still missing. Goal of this project is to implement the FreeText annotation. It allows to write text anywhere directly on a pdf file [0]. There is partial support in poppler [1], the library that is used for the actual pdf rendering. Okular shows such annotations, but they cannot be manipulated. Goal is to implement full support for editing FreeText annotations in Okular. | |||
[0] https://bugs.kde.org/show_bug.cgi?id=353401 | |||
[1] https://bugs.freedesktop.org/show_bug.cgi?id=93213 | |||
'''Expected results:''' The Okular annotation toolbar gains a new entry 'FreeText', where users can create new FreeText annotations. Additionally, existing FreeText annotations can be moved, deleted and modified. | |||
'''Knowledge prerequisite:''' C++ and Qt, and a bit about the pdf format | |||
==== Project: Improve custom stamp annotation handling ==== | |||
'''Brief explanation:''' Okular does display stamp annotations, but the support | |||
is somewhat incomplete. This particularly shows when trying to use stamp | |||
annotations with a custom image. For example, such annotations can be | |||
added in Okular, but they cannot be saved to the pdf file in a way | |||
that any other pdf viewer can read. Also, they will not appear on print-outs. | |||
The underlying reason for this is that Okular renders these stamps itself, | |||
rather than relying on the poppler library, which does all other pdf | |||
rendering. Goal of this project is therefore to teach poppler how to | |||
render stamp annotations, and then make Okular use that new functionality. | |||
More details can be found in the bug report [0]. | |||
[0] https://bugs.kde.org/show_bug.cgi?id=383651 | |||
'''Expected results:''' Poppler should render stamp annotations. Annotations | |||
should be printable from Okular. Custom stamps inserted via the Okular GUI | |||
should be visible in other pdf readers. | |||
'''Knowledge prerequisite:''' C++, and a bit about the pdf format. | |||
==== Project: Annotation improvements ==== | |||
'''Brief explanation:''' Okular supports convenient editing of pdf annotations, but quite a number of paper-cut bugs are known. Examples are [0,1,2], but many more can be found in the bugtracker. Goal of this project is to fix as many of these bugs as possible, which should improve the Okular user experience greatly. | |||
[0] https://bugs.kde.org/show_bug.cgi?id=275371 | |||
[1] https://bugs.freedesktop.org/show_bug.cgi?id=102635 | |||
[2] https://bugs.freedesktop.org/show_bug.cgi?id=52010 | |||
'''Expected results:''' Lots of annotation-related bugs fixed. Annotation rendering and manipulation should be more enjoyable. | |||
'''Knowledge prerequisite:''' C++ and Qt, and a bit about the pdf format | |||
=== WikiToLearn === | |||
You can find all of the WikiToLearn community on [https://chat.wikitolearn.org chat.wikitolearn.org]. We have many other ideas: get in touch with us to discuss them further! | |||
==== Project: Progressive Web App ==== | |||
'''Brief explanation:''' [https://cgit.kde.org/scratch/cristianbaldi/wikitolearn-frontend.git Current PWA] is being used in the first iteration of the new WikiToLearn architecture. It needs some improvement in terms of testing, offline-experience and organization to make it stable and ready for a first stable release. We want, also, to create a cohesive ecosystem of resources and design guidelines that can be easily reused. Main goal of this project is to enhance the existing project to provide a tested, functional and production-ready PWA. | |||
'''Expected results:''' | |||
* Improve documentation | |||
* Write design guidelines for people who want to contribute | |||
* Organize shared resources in a reusable manner | |||
* Write unit and integration test | |||
* Implement functional offline browsing | |||
* Enhance UX for a production-ready release | |||
'''Knowledge Prerequisite:''' | |||
* Knowledge of Vue | |||
* Knowledge of HTML5, CSS3 (Sass/Less), JS (ES6 and Browser Apis) | |||
* Responsive design | |||
* Build Tools (WebPack) | |||
* Standards and best practices in Web Development | |||
'''Mentor:''' Gianluca Rigoletti (@rigolo) | |||
=== Falkon === | |||
Falkon is a web browser previously known as QupZilla. | |||
==== JavaScript/QML extensions support ==== | |||
'''Brief explanation:''' Falkon supports additional application extensions to be installed. Currently, it only supports compiled C++ extensions, which makes it complicated to develop and distribute. Adding support for JavaScript extensions would make it more accessible and easier for developers. | |||
Qt includes own JavaScript engine (QJSEngine/QQmlEngine), so this task is about integrating it into Falkon code base and exposing the browser function to JavaScript extensions. | |||
'''Expected results:''' Extensions can be written in JavaScript and use QML for GUI. JavaScript extensions should be able to access and interact with all important browser functions. | |||
'''Knowledge Prerequisite:''' C++/Qt, JavaScript/QML basics | |||
'''Mentor:''' David Rosca ([email protected], IRC: nowrep on #falkon) | |||
==== Plasma integration ==== | |||
'''Brief explanation:''' Falkon is Qt application and as such it integrates quite well into Plasma desktop environment. There is also an extension that allows to store passwords in KWallet. Plasma desktop provides some services that could be useful to use from browser, like showing the progress of downloads as jobs in notification applet or searching for bookmarks or open tabs from KRunner. | |||
There is already existing extension for Chrome that implements these features - [https://cgit.kde.org/plasma-browser-integration.git plasma-browser-integration] that can be used as a base for the Falkon extension. | |||
'''Expected results:''' Falkon C++ extension and additional helpers improves the integration with Plasma desktop. | |||
'''Knowledge Prerequisite:''' C++/Qt, JavaScript basics | |||
'''Mentor:''' David Rosca ([email protected], IRC: nowrep on #falkon) | |||
=== Cantor === | |||
Cantor provides a graphical frontend for different open source computer algebra systems and scientific programming languages [https://edu.kde.org/cantor/]. | |||
==== Project: Improve Cantor's worksheet ==== | |||
'''Brief explanation''': One of the central components in Cantor is the worksheet - the place where the calculations are triggered and the results are shown. The worksheet is basically a collection of "cells" of different types which can carry user inputs or the results of the calculations. There are many features that are available in similar (free and commercial) products and that are still missing in this area in Cantor. The goal of this project is to close couple of most obvious gaps and to greatly improve the user experience in Cantor. To name couple of things that need to be implemented: | |||
* collapsible cells to hide the output of the calculations | |||
* additional styling for the cells like setting the color and the font | |||
* highlighting of the cell being currently calculated | |||
* use optionally different background colors for different cell types for an easier identification of e.g. text cells and cells used for calculations | |||
* show timings | |||
* context menu for the cells and for the cells outputs, provide their things like differentiate, simplify, etc. as well as things like "copy as text/latex/image" | |||
* copy&paste of cells | |||
* etc. | |||
'''Expected results''': Cantor's worksheet with an improved the usability extended functionality. | |||
'''Knowledge Prerequisite''': C++, Qt, Qt Graphics Framework | |||
'''Mentor''': tbd | |||
=== Plasma Mobile === | |||
Plasma Mobile is KDE's software stack for mobile devices that includes Plasma phone components, Kirigami and a set of mobile-friendly applications. | |||
==== Project: Mobile-friendly Locale & Language configuration module ==== | |||
'''Brief Explanation''': System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Locale & Language configuration module. | |||
'''Expected results''': the student has designed and programmed a configuration module that | |||
*Allows users to change system locale & language, install translation packages and configure keyboard layouts | |||
*Has a flexible and user-friendly interface | |||
*Can be used on both desktop and mobile platforms | |||
'''Knowledge Prerequisite''': Qt 5, QML, C++ | |||
'''Mentor''': Eike Hein (Sho_ on IRC) | |||
==== Project: Mobile-friendly Storage configuration module ==== | |||
'''Brief Explanation''': System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Storage configuration module. | |||
'''Expected results''': the student has designed and programmed a configuration module that | |||
*Allows users to see their storage stats in an informative and friendly way | |||
*Can be used to configure USB/MTP storage: by plugging your phone to a desktop/laptop you should be able to access files on the phone. Even though this bit is mostly base system/hardware providing this, Plasma Mobile should offer a user interface to enable/disable the USB/MTP storage support by default and on-demand | |||
*Has a flexible and user-friendly interface | |||
*Can be used on both desktop and mobile platforms | |||
'''Knowledge Prerequisite''': Qt 5, QML, C++ | |||
'''Mentor''': tbd | |||
==== Project: Mobile-friendly Network configuration module ==== | |||
'''Brief Explanation''': System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Network configuration module. | |||
'''Expected results''': the student has designed and programmed a configuration module that | |||
* Allows users to configure their wireless and mobile connections | |||
* Allows users to easily create hotspots | |||
* Gives users possibility to see statistics about transmitted/recieved data and control their limits for mobile connections | |||
'''Additional information''': There is currently one mobile-friendly KCM for network configuration in progress. In case it's not completely finished before GSoC coding period starts, then the student is supposed to finish it and add something else on top of that (like support for VPN connections), there will be definitely some interesting things to add and improve. | |||
'''Knowledge Prerequisite''': Qt, QML, C++ | |||
'''Mentor''': Jan Grulich (email: [email protected]; irc: jgrulich) | |||
==== Project: Telephony applications set ==== | |||
'''Brief Explanation''': In accordance with Plasma Mobile roadmap (https://vizzzion.org/blog/2017/10/plasma-mobile-roadmap/) and the goal of usability and productivity for basic software (https://phabricator.kde.org/T6831), we need to enable Plasma Mobile users to perform basic tasks on their phone effortlessly. To achieve that, we should provide a set of telephony applications: Dialer, SMS, Contact book. All of those apps already exist but are extremely basic and hardly usable. The goal of this project is to bring them to a state when they can be used for telephony tasks on a day-to-day basis. | |||
'''Expected results''': the student has designed and programmed the telephony application set that: | |||
*Allows users to perform telephony tasks on a daily basis | |||
*Has a flexible and user-friendly interface (usage of Kirigami is highly recommended) | |||
'''Knowledge Prerequisite''': Qt 5, QML, C++ | |||
'''Mentor''': Dan Leinir Turthra Jensen (leinir on IRC) | |||
=== KDevelop === | |||
[https://www.kdevelop.org/ Kdevelop] is a cross-platform IDE for C, C++, Python, QML/JavaScript and PHP. [mailto:[email protected] Contact the Kdevelop team]. | |||
==== Project: Improve development on docker containers ==== | |||
'''Brief Explanation''': We have been working on integrating properly docker containers usage into the IDE so they can be developed transparently. This project should help polishing the rough edges and make sure everything integrates properly. | |||
Some ideas would be improving the build systems, debuggers, language support in general, etc. We expect whoever sends the proposal to have looked into the problem and formed an idea of what needs to happen. Here's some explanation of the status quo. | |||
http://www.proli.net/2017/05/23/kdevelop-runtimes-docker-and-flatpak-integration/ | |||
http://www.proli.net/2017/12/18/docker-as-an-sdk-for-arm-distributions/ | |||
'''Expected results''': Improved usability of the integration of docker into the IDE. | |||
'''Knowledge Prerequisite''': Qt 5, C++ | |||
'''Mentor''': Aleix Pol | |||
=== Xdg-desktop-portal-kde === | |||
==== Project: Remote desktop portal ==== | |||
'''Brief explanation:''' Xdg-desktop-portal-kde is a portal backend implementation for [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal], allowing sandboxed applications (flatpak, snap) to access system files, devices and many other things. One of the missing parts is an implementation of [https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.impl.portal.RemoteDesktop.xml remote desktop portal], which should allow sandboxed applications to use remote desktop. Xdg-desktop-portal-kde recently got support for screencast portal, which adds support for screen sharing, this together with missing remote desktop portal should bring complete support for remote desktop to sandboxed applications, but also for Plasma wayland session. The similar implementation for Gnome can be found [https://github.com/flatpak/xdg-desktop-portal-gtk here]. | |||
The following were project headers removed from the 2019 ideas, since they were empty of ideas: | |||
'''Expected results:''' Applications with support for xdg-desktop-portal should be able to use remote desktop also with Plasma desktop. | |||
'''Knowledge Prerequisite:''' C++, Qt | |||
'''Mentor:''' Jan Grulich (Email: [email protected]; irc: jgrulich) | |||
=== Choqok === | |||
Get in touch on IRC (#choqok). | |||
=== Kopete === | |||
[https://kopete.kde.org/ Kopete] is a flexible and extendable multiple protocol instant messaging system. [http://mail.kde.org/mailman/listinfo/kopete-devel Developer mail list]. | |||
=== KGpg === | |||
[https://utils.kde.org/projects/kgpg KGpg] is a frontend for GnuPG key management. [mailto:[email protected] Contact the KGpg team]. | |||
===KWin=== | |||
KWin is the KDE project's default window manager. [https://mail.kde.org/mailman/listinfo/kwin Kwin developer mail list]. | |||
=== Peruse === | |||
Peruse is a comic book reader application by KDE, which is designed to work both on touch based devices, and on the traditional desktop. Additionally, it has a tool called Peruse Creator which is designed to create comic books for use with Peruse and any other CBZ capable comic book reader. It has rudimentary support for the [http://acbf.wikia.com/wiki/Specifications Advanced Comic Book Format], which is a metadata container for comic book archives (CBR, CBZ and so on). | |||
See the Peruse website for more detailed information: https://peruse.kde.org/ | |||
=== Plasma === | |||
Plasma is KDE's desktop environment; Simple by default, powerful when needed. [https://mail.kde.org/mailman/listinfo/plasma-devel Developer mail list]. | |||
=== WikiToLearn === | |||
WikiToLearn was born as a non-profit community and an open source project, which provides free and collaborative textbooks with the help of students and academia. Knowledge only grows if shared! | |||
You can find all of the [ https://www.wikitolearn.org/ WikiToLearn] community on [https://chat.wikitolearn.org chat.wikitolearn.org]. We have many other ideas: get in touch with us to discuss them further! |
Latest revision as of 00:41, 14 March 2019
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 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 [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.
Adding a Proposal
Project:
If appropriate, screenshot or another 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.
Expected results: Something you and KDE loves
Knowledge Prerequisite: Probably C++ and Qt but 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.
digiKam
digiKam is an advanced digital photo management application for Linux, Windows, and MacOS.
Project 1 : digiKam Web Services tools authentication with OAuth2
Brief Explanation: digiKam has many tools dedicated to sharing items on web services, as Facebook, Google Photo, Google Drive, SmugMug, etc... All tools use an older way to be authenticated through the web service using an external web browser instance to capture the token network session. This is a fastidious way to open a web service session. Currently, Flickr, DropBox, and Imgur tools use an embedded OAuth2 authentification without a web browser instance through O2 library for Qt. The goal of this project is to port all others web service tools to O2 library API.
Expected results:
- Review code of current tools ported to OAuth2
- Review current implementation of tools and list all web services compatible with OAuth standard.
- Plan the amount of work to port tools by order of complexity, and identify possible problems.
- Port code for each tools step by step, by writing unit tests independently.
- Test all tools with all use cases, depending of tool options.
- Write documentation.
Knowledge Prerequisite: Network, OAuth, C++, and Qt5
Mentor: Maik Qualmann and Gilles Caulier
Project 2 : Added the possibility to manually sort the digiKam icon view
Brief Explanation: digiKam has the possibility to sort the items in the icon view according to different criteria, for example by: name, date, file size, rating etc. Many digiKam users have long been wishing to manually sort the icon view. The bug report (https://bugs.kde.org/show_bug.cgi?id=91562) now has more than 700 votes. The goal of this project is to rearrange the sorting of items in the icon view by drag and drop. This sort must be stored in the database and must be retrievable like the other sort functions.
Expected results:
- Review code of current sort functions and the icon view model.
- Review current database schema of SQLite and MySQL.
- Adding a column to SQLite and MySQL table to store manual sort order.
- Write database upgrade procedure to port older digiKam databases.
- Write code for reading and writing manual sort order to the database.
- Write code for the manual item sorting in the icon view.
- Test your implementation of manual sorting.
- Write documentation.
Knowledge Prerequisite: Databases SQLite and MySQL, C++ and Qt5
Mentor: Maik Qualmann and Gilles Caulier
Project 3: Supporting Twitter and Amazon Drive services in digiKam export
Brief explanation: There are many web services that digiKam can communicate with and export images to them. Following digiKam convection, we want to support Twitter and OneDrive export. Also, It would be great if we grouped web services in specific categories, for example: Facebook, Twitter, VK, G+, ..etc will be grouped in "Social Networks" category. the user can expand a category and check the boxes beside every service he wants to use and share an image to all selected service with the same status update.
Expected Results
- Reviewing currently supported web services code
- Writing a client to connect to Twitter's API to be used to export images with status to it
- Writing a client to connect to OneDrive API to export images and albums to it
- Creating a dedicated widget to hold web services categories and categorizing each service to the right category
- Supporting the ability to select multiple service and export to them at once
- Writing unit tests for each new service
- Writing docs for each newly created class
Knowledge Prerequisites: C++, Qt, Network, Restful API's
Mentor: Mohamed Anwer and Gilles Caulier
Krita
Krita: digital painting for artists. It supports creating images from scratch from beginning 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 the following ideas.
Note that we're always open to ideas you bring in yourself: if you're passionate about something you've come up with yourself, that you want for Krita, that's a big plus for us.
We also expect prospective students to submit at least three patches for bugs or wishes or small features. We want to know how good you are! See https://phabricator.kde.org/T7724 for some smaller tasks that you could work on that are not bugs.
Project: Optimize multithreading in Krita's Tile Manager (make the hash table lockfree)
Brief explanation: This is a hard-core project, only suitable for someone with deep knowledge of the problems of designing multi-threaded software. It involves Krita's core datamodel, where the tiles that compose image data are managed. The main problem is that at the moment the core utilizes QReadWriteLock and QMutex a lot, which means that Krita painting performance stops scaling well, when the number of CPU cores becomes larger than 8. The goal of this project is to locate all the bottlenecks (there are at least 4 of them) and resolve them in a lock-free. One of the bottlenecks involves KisTileHashTable which is used to access the tiles. Since this touches the very core of Krita, a thorough test plan is essential.
Steps to apply: The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal:
- Build Krita with unittests enabled
- Install GNU Perf or VTune
- Run FreehandStrokeBenchmark in a profiler and try to locate all the places where most of the locking/waits happen. The main one will be the hash table, but there are at least three more (your task is to locate them and add into your proposal!)
- (optional) To test your coding abilities you can try to port one of the hash tables code from Junction library to Qt's primitives. If you don't feel overwhelmed with such code, you are perfectly fit for the project!
- And feel free to contact Krita developers, if you have any question during these steps!
Expected results: No bottlenecks anymore!
Knowledge Prerequisite: C++, Qt, threads, locks.
Mentor: Dmitry Kazakov (dmkitryK|log on irc)
Project: Extending Animation Support for curves
Brief Explanation: In Krita, you can already add curves that could be applied to some properties of a layer, like opacity, animating those properties. 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
- Saving of these settings
Knowledge Prerequisite:
- C++ and Qt
Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk_log)
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 revamped and exciting shapes brush
Knowledge Prerequisite:
- C++, Qt, Krita
Mentor: Boudewijn Rempt (IRC: boud) or Lukas Tvrdy (IRC: LukasT)
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). Vc library supports AXV2 instructions, though we don't know to what extent, it might happen that you would need to extend the library itself to get the needed functionality. This is another hard-core project only suitable if you have a good deal of experience.
Steps to apply: The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal:
- Build Krita with unittests enabled
- Install GNU Perf or VTune
- Run KisCompositionBenchmark under a profiler and see the hottest places of blending modes code
- Check the code of "Normal" blending mode for float32 color spaces (KoOptimizedCompositeOpOver128), copy the file and try to create your own blending mode for float16 color space. Hint: the only thing you should do is to implement correct unpacking/packing code that would convert the values to 32-bit float and back.
- If you don't feel overwhelmed with such code, you are perfectly fit for the project!
- And feel free to contact Krita developers, if you have any question during these steps!
Expected Results: Float16 color spaces are ported to AVX, Integer8 and Integer16 colorspaces are ported to AVX2
Knowledge Prerequisite: C++, SEE/AVX (read Intel's manual)
Mentor: Dmitry Kazakov (IRC: dmitryk|log)
Project: Port generic code for not-so-popular blending modes to AVX
Brief Explanation: In Krita we have a lot of blending modes, but only Normal and Alpha Darken are optimized and ported to AVX instructions. The reason for that is obvious, these two blending modes are the hottest and are used in every single image produced in Krita. But it doesn't mean that the other blending modes are less important for painters: they still use Multiply for painting shadows, and Linear Dodge for painting highlights, so they should also be fast!
The good piece of news is that all these "non-popular" blending modes are implemented in Krita by means of a single class KoCompositeOpGenericSC, so, basically, as a result of your project, you should provide one class only! The bad piece of news is that this single class implements about a hundred of blending modes using C++ templates... so be prepared! :)
Steps to apply: The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal:
- Build Krita with unittests enabled
- Install GNU Perf or VTune
- Run KisCompositionBenchmark under a profiler and see the hottest places of blending modes code
- Check the code of "Copy" blending mode in KoCompositeOpCopy2 and try to port it into AVX for RGB8 colorspace. Use KoOptimizedCompositeOpOver32 as an example.
- If you don't feel overwhelmed with such code, you are perfectly fit for the project!
- And feel free to contact Krita developers, if you have any question during these steps!
Expected Results: "Copy" blending mode is ported to AVX, all the "generic" blending modes are ported to AVX
Knowledge Prerequisite: C++, SEE/AVX (read Intel's manual)
Mentor: Dmitry Kazakov (IRC: dmitryk|log)
Project: Optimize Soft, Gaussian and Stamp brushes to use AVX
Brief Explanation: When the user draws a line in Krita, this line consists of thousands of small rectangular images (dabs) that are painted one over another. For each dab, Krita generates its own mask (depending on the stylus pressure and tilt) and uses this mask for filling the layer. It happens thousands of times per second, which makes mask generation code one of the hottest places in Krita. We already have AVX optimization for Default brush mask engine and it works 5(!) times faster than Gaussian engine and 3(!) times faster than the Soft engine. The goal of this project is to port the rest of non-optimized engines to use AVX via Vc library and make them faster.
Steps to apply: The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal:
- Build Krita with unittests enabled
- Install GNU Perf or VTune
- Run FreehandStrokeBenchmark under a profiler and compare the results for different types of brushes. You can see how faster Default brush tip is.
- Check the code in kis_brush_mask_applicator_factories.cpp and try to implement your own version of FastRowProcessor for KisGaussCircleMaskGenerator without using any AVX. Even without any vector instruction, the brush will become much faster, just because it will use less virtual calls.
- If you don't feel overwhelmed with the amount of C++ templates in your code, you are perfectly fit for the project!
- And feel free to contact Krita developers, if you have any question during these steps!
Expected Results: Circular Soft, Gaussian and Stamp brush masks are ported to AVX-optimized code. Optionally, if there is enough time, rectangular brush masks are posted as well.
Knowledge Prerequisite: C++, SEE/AVX (read Intel's manual)
Mentor: Dmitry Kazakov (IRC: dmitryk|log)
Project: Partial canvas updates and region of interest (performance optimization for huge (20k+) canvases)
Brief Explanation: We already have an optimization for huge canvases, which is called Instant Preview. But it works 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 to the rest of the image. This project is targeted to optimize 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 should 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.
Steps to apply: The topic of the project is quite advanced, so we recommend you to do the following steps before writing a proposal:
- Build Krita
- Check the code in KisImage, pay attention to 'cropRect' parameter of the update calls. That is exactly what you need for limiting the updates in the work area tool
- Try to write Work Area Tool: copy the code of KisToolCrop, connect it to Krita and make it override the cropRect parameter in KisImage.
- If you manage to make a draft of Work Area Tool, most probably, you will manage to complete the whole project successfully!
- And feel free to contact Krita developers, if you have any question during these steps!
Knowledge Prerequisite: C++, OpenGL
Mentor: Dmitry Kazakov (IRC: dmitryk|log), Julian Thijssen (IRC: Nimmy)
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)
KDE Student Programs
KDE Student Programs is the working group responsible for running Season of KDE and managing KDE's participation in Google Summer of Code, Google Code-In, and other mentorship programmes.
GCompris
Project: One step closer to version 1.0
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 work on the most important activities that we are missing to have a complete 1.0. You can find a list of tasks that you can work on at https://phabricator.kde.org/T7498.
First phase is to check how the Gtk+ version was working, what could be improved and then create a proposal with a timeline explaining what you expect to do and the time estimation. It does not need to be a simple clone, improvements should be done when possible.
Bitmap drawing activity and piano activities are already started in gsoc-tuxPaint/playpiano branches respectively. Note that for piano activities, it is a "package" containing multiple activities: play_piano, piano_composition, name_notes and play_rhythm. The other ones are to start from scratch.
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 or by mail ([email protected])
Mentors: Divyam Madaan (IRC: dmadaan), Emmanuel Charruau (IRC: allon), Johnny Jazeix (IRC: JohnnyJ), Timothée Giet (IRC: Animtim)
Project: Unit test framework
Expected results: The aim of this project is to build the base for unit testing for GCompris. The student will have to think on what we can test (qml, js...) and how we can put this in place. More information can be found in https://phabricator.kde.org/T7668.
Knowledge Prerequisite:
Be interested in children’s education
Be familiar with GCompris concept and content
Basic knowledge in a programming language and CMake use (a 1 year school course is enough)
Be able to build the Qt Quick version of GCompris
Technologies used are CMake, C++, Qt.
Feel free to contact us either on irc or by mail ([email protected])
Mentors: Divyam Madaan (IRC: dmadaan), Johnny Jazeix (IRC: JohnnyJ), Rudra Nil Basu (IRC: rudra), Timothée Giet (IRC: Animtim)
KDE Partition Manager
Kopete
Project: Write tests and Improve protocol support
Brief explanation: Kopete is an instant messaging client that has the modular architecture and supports many messaging services with useful plugins to complement them.
Expected results: The aim of this project is to fix the bugs due to porting and improve the frontend and the test coverage.
Knowledge Prerequisite:
- Be interested in test-driven development.
- Be familiar with the codebase of KDE in general.
- Knowledge of C++ / Qt.
Application guide:
Get in touch with us on mailing-list and start hacking KDE and fix bugs. Teams of two people is preferred for this project as it is a lot of work :)
You can contact on IRC also but it is better to discuss over mailing list as not many people are in IRC on #kopete channel.
Mentors: Vijay <[email protected]> (vijay_ on IRC), Kopete Mailing List <[email protected]>
LabPlot
LabPlot is a KDE-application for interactive graphing and analysis of scientific data. LabPlot provides an easy way to create, manage and edit plots and to perform data analysis.
Project: Plotting of live MQTT data
Brief explanation: LabPlot has already some support for plotting of live-data (http://krajszgsoc.blogspot.de/2017/09/in-finish-line-but-not-in-end.html). To cover more use-cases we want to also support MQTT sources. We need to investigate the available MQTT libraries for Qt:
and to add some support for MQTT to LabPlot.
Expected results: Similar to the currently supported data sources (files, sockets, serial port, SQL databases) we want to support the subscription to MQTT brockers and plotting of their data.
Knowledge Prerequisite: C++, Qt, (optional) knowledge and experience with MQTT
Mentor: Fábián Kristóf - Szabolcs (mailto:[email protected])
Project: Import of educational data sets available on the internet
Brief explanation: There are many internet pages providing data sets for educational and study purposes for many different areas (astrophysics, statistics, medicine, etc.). Some tools used in the scientific area provide some "wrappers" for such online sources and allow the user to easily play around with those data sets in the applications whereas the technical details like fetching of data from the server and parsing are done completely transparent for the user. The goal of this project is to add similar functionality to LabPlot. There will be a wizard where the user can select from a thematically grouped list of data sets available online. The internal description of such an online data set should contain the URL with the actual file that needs to be downloaded and the settings for LabPlot's data parser (separator, column names and data types, etc.). The data fetched once should be cached so there is no need to fetch from the web again. Here we can have a look maybe at KStars for how to implement such a caching strategy and maybe even re-use some code from KStars. In addition to the list of pre-defined online sources, we need to elaborate how the user can add new online data sets (together with all the required parametrization) and publish the settings to make them available for everybody.
Expected results: We want to be able to easily import the educational data sets available on the internet.
Knowledge Prerequisite: C++, Qt
Mentor: Stefan Gerlach
Project: Import of data from web-services
Brief explanation: Brief explanation: This goal of this project is to extend the number of supported data sources by adding the possibility to import the data from web services (live and historical financial data, weather, etc.). Most web services expose their data via JSON. We need to add a "JSON filter" to LabPlot capable to connect to a web service, to fetch the data, to parse it and to import into LabPlot's internal data containers. In the GUI the user should be guided through the entry of the service URL, additional services parameters like API token, etc. and through the settings for the actual parsing (which JSON fields to consume and how). Also, it should be possible to refresh the data periodically like it is already possible for the live data (http://krajszgsoc.blogspot.de/2017/09/in-finish-line-but-not-in-end.html). The goal is also to provide a set of widely known web services so the user can select and import the data from a list of pre-defined services. In addition to this, we need to elaborate the possibility to "publish" the settings for a web-service done by the user and make them publicly available to every LabPlot user.
Expected results: Similar to the currently supported data sources (files, sockets, serial port, SQL databases) we want to import the data from web services and visualize it.
Knowledge Prerequisite: C++, Qt, (optional) JSON support in Qt
Mentor: Alexander Semke
Kdenlive
Kdenlive is a KDE-application for professional video editors. It supports hundreds of video formats and all the features you can expect from a non-linear video editor, including some advanced features like timeline preview rendering, proxy clips and more.
Choqok
Project: Port Choqok to Kirigami
Brief explanation: Current Choqok UI doesn't make use of QML and creates interfaces in C++ files. The idea is to rewrite the interface in QML. At this point is better doing it with Kirigami since this means it will work on Plasma Mobile too.
Expected results: Choqok UI makes use of Kirigami.
Knowledge Prerequisite: C++, Qt, Qml
Mentor: Andrea Scarpino (IRC: ilpianista)
Application guide: Get in touch on IRC (#choqok).
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: Improving the reliability and usability of KStars
Brief explanation: KStars has a mature codebase with well-written C++ for a desktop and a mobile client. The applicant would like to contribute enhancements by improving the sources (C++11/C++14 features, static code analysis, better testing in CI) and adding usability improvements to the desktop and the mobile version of KStars.
Expected results:
- All findings of the static code analyzers will be fixed.
- The C++ tooling will be integrated to Jenkins in KDE CI.
- The desktop version of KStars will have usability improvements.
- The build system (CMake) of the Android client will be enhanced.
- Add new functionalities for telescope equipment control and camera capture and live streaming.
Knowledge Prerequisite: C++, Qt, Qml, Jenkins, static code analyzers.
Mentor: Jasem Mutlaq (Matrix: Jasem)
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 an 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 support 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.
Knowledge Prerequisite: C++, Qt, Data Structures
Mentor: Jasem Mutlaq (Matrix: Jasem)
Project: Implementing Ekos in KStars Lite
Brief explanation: Ekos is KStars premier tool for observatory control and automation. KStars Lite was successfully developed in GSoC 2016 and is available for Android phones and tablets. We would like to extend KStars Lite to include basic support for Ekos. Currently, KStars Lite supports basic telescope and capture controls, but it could be extended to support a richer experience for users who are performing observatory control and astrophotography.
Expected results:
- Telescope floating motion controls including speed controls.
- Like video feed display from supported devices.
- Image capture with binning, count, exposure, ISO..etc controls similar to Ekos desktop client.
- Focus controls.
- Alignment using remote astrometry.
Knowledge Prerequisite: C++, Qt, QML
Mentor: Jasem Mutlaq (Matrix: Jasem)
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.
Knowledge Prerequisite: C++, Qt, Django/Ajax or similar technology framework.
Mentor: Jasem Mutlaq (Matrix: 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: Akarsh Simha (Matrix: kstar)
Peruse
Peruse is a comic book reader application by KDE, which is designed to work both on touch based devices, and on the traditional desktop. Additionally, it has a tool called Peruse Creator which is designed to create comic books for use with Peruse and any other CBZ capable comic book reader. It has rudimentary support for the Advanced Comic Book Format, which is a metadata container for comic book archives (CBR, CBZ and so on).
See also the Peruse website for more detailed information: https://peruse.kde.org/
Project: Expand Creator's Abilities
Brief explanation: Peruse Creator is currently very simple, and will allow the user to create a CBZ comic book archive annotated with a subset of the Advanced Comic Book Format (ACBF) metainfo, such as authors, publisher information, characters and so on. It does not allow for the creation or editing of the viewport based navigation that ACBF describes, nor does it support the text layers system ACBF proposes for comic book translation. It also lacks editor components for a variety of the general metainformation ACBF suggests.
Your project proposal should include explicit descriptions of which of these you wish to build support for, and how you propose to do so. It should further include timeframes for each.
Expected results: A more capable Peruse Creator.
Knowledge Prerequisite: C++ and Qt required, additionally QML/QtQuick knowledge is preferred
Mentor: Dan Leinir Turthra Jensen ([email protected], IRC: leinir, Telegram and twitter: @leinir)
Project: New Viewer Component
Brief explanation: The current viewer component for Comic Book Archives (CBR) in Peruse is a simple full-page viewer, which only supports page-by-page navigation. The Advanced Comic Book Format (ACBF) metadata container brings with it support for a viewport system, which describes how the application should present specific sub-sections of each page, as well as a system for navigating between arbitrary pages in the comic.
Your project proposal should include explicit descriptions of how you would suggest implementing this, as well as a schedule for the work.
Expected results: A viewer component which is able to consume and display the viewport based navigation metadata from the ACBF container, as well as present the general metainformation to the user.
Knowledge Prerequisite: C++ and Qt required, additionally QML/QtQuick knowledge is preferred
Mentor: Dan Leinir Turthra Jensen ([email protected], IRC: leinir, Telegram and twitter: @leinir)
KGpg
KGpg is a frontend for GnuPG key management.
Brief explanation: KGpg currently consists of one application with a very narrow external interface, which is available via DBus. The goal is to split out parts of the code into a static library that is used both by the KGpg binary as well as to-be-written unit tests, which should also cover at least all of the "transaction" classes.
Expected results: unit tests that can be called via CTest, and are integrated into the KDE CI jobs
Knowledge Prerequisite: basic C++, CMake, and GnuPG usage
Mentor: Rolf Eike Beer ([email protected], IRC: Dakon)
KWin
Multi-GPU support in Wayland session
Brief Explanation: Currently KWin as a Wayland compositor can only render to outputs of the primary GPU. We want to allow multi GPU setups with more than one graphics card or simultaneous use of an expansion card and the internal graphics. For that, we need to query all available GPUs and handle them accordingly in our DRM backend.
Expected results: Query all available GPUs in DRM backend and their outputs.
Knowledge Prerequisite: C++, Qt5, basic knowledge of graphics hardware
Mentor: Roman Gilg (Email: [email protected]; IRC: romangg)
Wayland graphical tablet input support
Brief Explanation: Tablets are very different from mice, they have a lot more information about their current state and events. As such there are separate protocols for passing these events from raw hardware to the client. We need to add:
* A protocol in kwayland to wrap the low level protocol * support in KWin to map libinput to sending wayland events to the right clients. * support in Qt's wayland client code to map wayland to Qt events that applications can use
(this will mean collaborating not just within KDE code but also Qt)
Expected results: Working tablet support in all applications within a kwin wayland session.
Knowledge Prerequisite: C++, Qt5,
Mentor: David Edmundson ([email protected])
Activities support in KWin on Wayland
Brief Explanation: KWin has one important regression when it comes to Wayland - lack of support for activities (mainly hiding windows that do not belong to the current activity). What needs to be done:
- Implement a way for kwin to know which applications belong to which activities
- Implement a way for applications to specify on which activities they are
Expected results: Working activities in KWin without any performance regressions.
Knowledge Prerequisite: C++, Qt5,
Mentor: Ivan Cukic ([email protected])
Plasma
Improve handling for touchpads and mice with Libinput
Brief explanation: Libinput is now used as the driver for input devices in most distros. However, System Settings does not present the user with good interfaces for configuring input devices with libinput. Currently, the only well-supported use case is for touchpads in a Wayland session. For touchpads on X11, and mice on both X11 and Wayland, the user experience is sub-optimal or non-existent.
Expected results: System Settings should expose good user interfaces for configuring both touchpads and mice when using Libinput, and for both Wayland and X11.
Knowledge Prerequisite: C++, Qt
Mentor: Nate Graham (Email: [email protected]; Telegram: @nggraham)
Application guide:
- https://wayland.freedesktop.org/libinput/doc/latest/developers.html
- https://bugs.kde.org/show_bug.cgi?id=383379
System Settings: Port keyboard input modules and expand scope to cover input method configuration
Brief explanation: System Settings' keyboard configuration module needs to be ported to Qt Quick based on reference designs provided by KDE's Visual Design Group. Additionally, the scope of keyboard input configuration needs to be expanded to cover input method configuration as well. This is both part of a larger drive to port the modules in the System Settings application to Qt Quick and modernize its UI design, as well as improve the text input configuration experience for a global audience. This project involves refactoring the existing System Settings module's code to be used as the backend for a QML-based UI and writing new backend code to configure the ibus or fcitx input method daemons. The UI design is expected to be refined during the course of the project in collaboration with VDG contributors. Interaction with other developers working on System Settings module ports in parallel is also expected.
Expected results: System Settings should offer keyboard layout and basic input language configuration in a modern UI design.
Knowledge Prerequisite: C++, Qt, Qt Quick/QML
Mentor: Eike Hein (Email: [email protected]; IRC: Sho_; Telegram: @eikehein)
Application guide:
- https://conf.kde.org/en/akademy2017/public/events/359
- https://www.youtube.com/watch?v=wE0KDabPfsQ
- https://phabricator.kde.org/M112
Discover: fwupd integration
Brief explanation: Discover Software Center is in charge of offering different kinds of assets at the moment. Applications, Add-ons, etc as well as serving updates. At the moment it's still not able to update our devices' firmwares. There's a tool for GNU/Linux called FWUPD to do so: https://fwupd.org/developers
Despite the description specifying plasma, the end goal is to provide a seamless solution to have your hardware's firmware up to date. If the proposal is too short, other improvements suggested to add to the idea will be welcome.
Expected results: Plasma being great at having an up to date system, also with hardware.
Knowledge Prerequisite: C++ and Qt, also notions of how glib works, to understand upstream FWUPD.
Mentor: Aleix Pol: apol, @AleixPol, [email protected]
Okular
Add support for showing and adding replies to sticky notes
Brief explanation: PDF files can contain replies to certain annotations, you would need to add support to Okular and potential poppler so that they show the same way they do on other PDF readers. Once they are shown and if there is enough time adding the capability to add replies is also welcome.
Knowledge Prerequisite: C++, Qt
Mentor: Okular developers https://mail.kde.org/mailman/listinfo/okular-devel
Application guide:
Project: Verifying signatures of pdf files
Brief explanation: Okular should provide information about signatures if a pdf document has been signed. The poppler library used by Okular to render pdf files does support verification of signed pdf files and the retrieval of signature information. However, this functionality is not used by Okular. Goal of the project is to extend the Okular GUI to show whether a document is signed, and to show the signature details.
Bonus points for any steps towards signing pdf files in Okular.
Expected results: When opening a signed document, Okular should show that the document is signed, and whether the signature is valid, expired, etc. Detailed information about the signature(s) should be made available, through a new menu entry (all signatures) or by a context menu for individual signatures.
Knowledge prerequisite: C++ and Qt, very little cryptography skills
Project: Implement the FreeText annotation
Brief explanation: Okular implements various annotations from the pdf standard, but a few are still missing. Goal of this project is to implement the FreeText annotation. It allows to write text anywhere directly on a pdf file [0]. There is partial support in poppler [1], the library that is used for the actual pdf rendering. Okular shows such annotations, but they cannot be manipulated. Goal is to implement full support for editing FreeText annotations in Okular.
[0] https://bugs.kde.org/show_bug.cgi?id=353401 [1] https://bugs.freedesktop.org/show_bug.cgi?id=93213
Expected results: The Okular annotation toolbar gains a new entry 'FreeText', where users can create new FreeText annotations. Additionally, existing FreeText annotations can be moved, deleted and modified.
Knowledge prerequisite: C++ and Qt, and a bit about the pdf format
Project: Improve custom stamp annotation handling
Brief explanation: Okular does display stamp annotations, but the support is somewhat incomplete. This particularly shows when trying to use stamp annotations with a custom image. For example, such annotations can be added in Okular, but they cannot be saved to the pdf file in a way that any other pdf viewer can read. Also, they will not appear on print-outs.
The underlying reason for this is that Okular renders these stamps itself, rather than relying on the poppler library, which does all other pdf rendering. Goal of this project is therefore to teach poppler how to render stamp annotations, and then make Okular use that new functionality. More details can be found in the bug report [0].
[0] https://bugs.kde.org/show_bug.cgi?id=383651
Expected results: Poppler should render stamp annotations. Annotations should be printable from Okular. Custom stamps inserted via the Okular GUI should be visible in other pdf readers.
Knowledge prerequisite: C++, and a bit about the pdf format.
Project: Annotation improvements
Brief explanation: Okular supports convenient editing of pdf annotations, but quite a number of paper-cut bugs are known. Examples are [0,1,2], but many more can be found in the bugtracker. Goal of this project is to fix as many of these bugs as possible, which should improve the Okular user experience greatly.
[0] https://bugs.kde.org/show_bug.cgi?id=275371 [1] https://bugs.freedesktop.org/show_bug.cgi?id=102635 [2] https://bugs.freedesktop.org/show_bug.cgi?id=52010
Expected results: Lots of annotation-related bugs fixed. Annotation rendering and manipulation should be more enjoyable.
Knowledge prerequisite: C++ and Qt, and a bit about the pdf format
WikiToLearn
You can find all of the WikiToLearn community on chat.wikitolearn.org. We have many other ideas: get in touch with us to discuss them further!
Project: Progressive Web App
Brief explanation: Current PWA is being used in the first iteration of the new WikiToLearn architecture. It needs some improvement in terms of testing, offline-experience and organization to make it stable and ready for a first stable release. We want, also, to create a cohesive ecosystem of resources and design guidelines that can be easily reused. Main goal of this project is to enhance the existing project to provide a tested, functional and production-ready PWA.
Expected results:
- Improve documentation
- Write design guidelines for people who want to contribute
- Organize shared resources in a reusable manner
- Write unit and integration test
- Implement functional offline browsing
- Enhance UX for a production-ready release
Knowledge Prerequisite:
- Knowledge of Vue
- Knowledge of HTML5, CSS3 (Sass/Less), JS (ES6 and Browser Apis)
- Responsive design
- Build Tools (WebPack)
- Standards and best practices in Web Development
Mentor: Gianluca Rigoletti (@rigolo)
Falkon
Falkon is a web browser previously known as QupZilla.
JavaScript/QML extensions support
Brief explanation: Falkon supports additional application extensions to be installed. Currently, it only supports compiled C++ extensions, which makes it complicated to develop and distribute. Adding support for JavaScript extensions would make it more accessible and easier for developers.
Qt includes own JavaScript engine (QJSEngine/QQmlEngine), so this task is about integrating it into Falkon code base and exposing the browser function to JavaScript extensions.
Expected results: Extensions can be written in JavaScript and use QML for GUI. JavaScript extensions should be able to access and interact with all important browser functions.
Knowledge Prerequisite: C++/Qt, JavaScript/QML basics
Mentor: David Rosca ([email protected], IRC: nowrep on #falkon)
Plasma integration
Brief explanation: Falkon is Qt application and as such it integrates quite well into Plasma desktop environment. There is also an extension that allows to store passwords in KWallet. Plasma desktop provides some services that could be useful to use from browser, like showing the progress of downloads as jobs in notification applet or searching for bookmarks or open tabs from KRunner.
There is already existing extension for Chrome that implements these features - plasma-browser-integration that can be used as a base for the Falkon extension.
Expected results: Falkon C++ extension and additional helpers improves the integration with Plasma desktop.
Knowledge Prerequisite: C++/Qt, JavaScript basics
Mentor: David Rosca ([email protected], IRC: nowrep on #falkon)
Cantor
Cantor provides a graphical frontend for different open source computer algebra systems and scientific programming languages [1].
Project: Improve Cantor's worksheet
Brief explanation: One of the central components in Cantor is the worksheet - the place where the calculations are triggered and the results are shown. The worksheet is basically a collection of "cells" of different types which can carry user inputs or the results of the calculations. There are many features that are available in similar (free and commercial) products and that are still missing in this area in Cantor. The goal of this project is to close couple of most obvious gaps and to greatly improve the user experience in Cantor. To name couple of things that need to be implemented:
- collapsible cells to hide the output of the calculations
- additional styling for the cells like setting the color and the font
- highlighting of the cell being currently calculated
- use optionally different background colors for different cell types for an easier identification of e.g. text cells and cells used for calculations
- show timings
- context menu for the cells and for the cells outputs, provide their things like differentiate, simplify, etc. as well as things like "copy as text/latex/image"
- copy&paste of cells
- etc.
Expected results: Cantor's worksheet with an improved the usability extended functionality.
Knowledge Prerequisite: C++, Qt, Qt Graphics Framework
Mentor: tbd
Plasma Mobile
Plasma Mobile is KDE's software stack for mobile devices that includes Plasma phone components, Kirigami and a set of mobile-friendly applications.
Project: Mobile-friendly Locale & Language configuration module
Brief Explanation: System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Locale & Language configuration module.
Expected results: the student has designed and programmed a configuration module that
- Allows users to change system locale & language, install translation packages and configure keyboard layouts
- Has a flexible and user-friendly interface
- Can be used on both desktop and mobile platforms
Knowledge Prerequisite: Qt 5, QML, C++
Mentor: Eike Hein (Sho_ on IRC)
Project: Mobile-friendly Storage configuration module
Brief Explanation: System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Storage configuration module.
Expected results: the student has designed and programmed a configuration module that
- Allows users to see their storage stats in an informative and friendly way
- Can be used to configure USB/MTP storage: by plugging your phone to a desktop/laptop you should be able to access files on the phone. Even though this bit is mostly base system/hardware providing this, Plasma Mobile should offer a user interface to enable/disable the USB/MTP storage support by default and on-demand
- Has a flexible and user-friendly interface
- Can be used on both desktop and mobile platforms
Knowledge Prerequisite: Qt 5, QML, C++
Mentor: tbd
Project: Mobile-friendly Network configuration module
Brief Explanation: System Settings are built of modules (KCMs) which allow users to configure specific aspects of their system. KCMs that are programmed using Qt Quick and designed to look good on any screen sizes can be shared between desktop and mobile. This project's goal is to create such a universal Network configuration module.
Expected results: the student has designed and programmed a configuration module that
- Allows users to configure their wireless and mobile connections
- Allows users to easily create hotspots
- Gives users possibility to see statistics about transmitted/recieved data and control their limits for mobile connections
Additional information: There is currently one mobile-friendly KCM for network configuration in progress. In case it's not completely finished before GSoC coding period starts, then the student is supposed to finish it and add something else on top of that (like support for VPN connections), there will be definitely some interesting things to add and improve.
Knowledge Prerequisite: Qt, QML, C++
Mentor: Jan Grulich (email: [email protected]; irc: jgrulich)
Project: Telephony applications set
Brief Explanation: In accordance with Plasma Mobile roadmap (https://vizzzion.org/blog/2017/10/plasma-mobile-roadmap/) and the goal of usability and productivity for basic software (https://phabricator.kde.org/T6831), we need to enable Plasma Mobile users to perform basic tasks on their phone effortlessly. To achieve that, we should provide a set of telephony applications: Dialer, SMS, Contact book. All of those apps already exist but are extremely basic and hardly usable. The goal of this project is to bring them to a state when they can be used for telephony tasks on a day-to-day basis.
Expected results: the student has designed and programmed the telephony application set that:
- Allows users to perform telephony tasks on a daily basis
- Has a flexible and user-friendly interface (usage of Kirigami is highly recommended)
Knowledge Prerequisite: Qt 5, QML, C++
Mentor: Dan Leinir Turthra Jensen (leinir on IRC)
KDevelop
Kdevelop is a cross-platform IDE for C, C++, Python, QML/JavaScript and PHP. Contact the Kdevelop team.
Project: Improve development on docker containers
Brief Explanation: We have been working on integrating properly docker containers usage into the IDE so they can be developed transparently. This project should help polishing the rough edges and make sure everything integrates properly. Some ideas would be improving the build systems, debuggers, language support in general, etc. We expect whoever sends the proposal to have looked into the problem and formed an idea of what needs to happen. Here's some explanation of the status quo.
http://www.proli.net/2017/05/23/kdevelop-runtimes-docker-and-flatpak-integration/ http://www.proli.net/2017/12/18/docker-as-an-sdk-for-arm-distributions/
Expected results: Improved usability of the integration of docker into the IDE.
Knowledge Prerequisite: Qt 5, C++
Mentor: Aleix Pol
Xdg-desktop-portal-kde
Project: Remote desktop portal
Brief explanation: Xdg-desktop-portal-kde is a portal backend implementation for xdg-desktop-portal, allowing sandboxed applications (flatpak, snap) to access system files, devices and many other things. One of the missing parts is an implementation of remote desktop portal, which should allow sandboxed applications to use remote desktop. Xdg-desktop-portal-kde recently got support for screencast portal, which adds support for screen sharing, this together with missing remote desktop portal should bring complete support for remote desktop to sandboxed applications, but also for Plasma wayland session. The similar implementation for Gnome can be found here. The following were project headers removed from the 2019 ideas, since they were empty of ideas:
Expected results: Applications with support for xdg-desktop-portal should be able to use remote desktop also with Plasma desktop.
Knowledge Prerequisite: C++, Qt
Mentor: Jan Grulich (Email: [email protected]; irc: jgrulich)
Choqok
Get in touch on IRC (#choqok).
Kopete
Kopete is a flexible and extendable multiple protocol instant messaging system. Developer mail list.
KGpg
KGpg is a frontend for GnuPG key management. Contact the KGpg team.
KWin
KWin is the KDE project's default window manager. Kwin developer mail list.
Peruse
Peruse is a comic book reader application by KDE, which is designed to work both on touch based devices, and on the traditional desktop. Additionally, it has a tool called Peruse Creator which is designed to create comic books for use with Peruse and any other CBZ capable comic book reader. It has rudimentary support for the Advanced Comic Book Format, which is a metadata container for comic book archives (CBR, CBZ and so on).
See the Peruse website for more detailed information: https://peruse.kde.org/
Plasma
Plasma is KDE's desktop environment; Simple by default, powerful when needed. Developer mail list.
WikiToLearn
WikiToLearn was born as a non-profit community and an open source project, which provides free and collaborative textbooks with the help of students and academia. Knowledge only grows if shared!
You can find all of the [ https://www.wikitolearn.org/ WikiToLearn] community on chat.wikitolearn.org. We have many other ideas: get in touch with us to discuss them further!