GSoC/2016/Ideas: Difference between revisions

Help

From KDE Community Wiki

< GSoC | 2016

← Older edit Newer edit →

Revision as of 15:05, 19 February 2016

GSoC 2016 logo

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

Note

Follow the template of other proposals!

Project:

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.

Calamares

Calamares is a distribution-independent installer framework (code). Calamares is participating to Google Summer of Code with KDE as umbrella organization. We are a young project, we are developing quickly, we are working with state of the art technologies (C++11, Qt 5, KDE Frameworks 5, Boost.Python) and we are solving exciting problems.

Calamares is already shipped or is about to be shipped as the default system installer for several Linux distributions, including KaOS, BBQLinux, Fedora KDE, Manjaro, Netrunner Rolling, OpenMandriva, Tanglu, and others.

See this post for instructions on how to structure your Google Summer of Code proposal for Calamares.

Project: Python interface refactor + Python view modules

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Installer pages are also provided by Calamares modules. These modules can currently be written in C++11 (as Qt plugins) or Python. The Python interface *works*, but it is slightly different from the C++ one, and it only supports jobs, not installer pages. This Google Summer of Code project is one of several that start with the same initial subtask, and then branch out in different directions.

0) Refactor the Python interface so that writing a job module is not just implementing a function that expects globals, but rather inheriting from Calamares::Job or a wrapper thereof. Port all the Python modules to this updated interface. PythonQt 3.0 has just been released with support for Qt 5, so this is an option too, as a replacement for Boost.Python. The student should investigate all alternatives, consult with the mentor and propose a design.

1) Further improve the Python interface to allow writing view modules (i.e. installer pages) in Python. The student should do some research on the strengths and weaknesses of different approaches and produce a detailed action plan on what to wrap, how to wrap it, and which technologies to use to achieve said goals.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python and C++ module interfaces, for both job modules and view modules.

Knowledge Prerequisite: At least some C++ experience is required; experience with CMake, Python, Boost.Python and other language binding solutions (PyQt, SWIG...) is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode

Project: Python interface refactor + Ruby modules interface

1) After completing subtask 0 for Python modules, achieve the same level of support for Ruby. The student should research technologies such as SWIG, RubyInline, FFI and Rice and produce a detailed action plan on how to deliver a Ruby interface for Calamares job modules. The latter (Rice) seems to be the most promising for the kind of embedding we need and most similar to Boost.Python, but this must be further ascertained. Packaging and deployment should also be taken into account.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python, Ruby and C++ job module interfaces.

Knowledge Prerequisite: At least some C++ experience is required; experience with CMake, Ruby, Python, Boost.Python and other language binding solutions (PyQt, SWIG...) is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode; Rohan Garg <[email protected]>, shadeslayer on Freenode

Project: Python interface refactor + Python testing mechanism

1) Our Python testing facilities are currently limited to a single script (src/modules/testmodule.py). The student should present an action plan for a more comprehensive testing mechanism, which may or may not be based on testmodule.py, and may or may not involve libcalamares instead. This testing mechanism could further be integrated with our Jenkins continuous integration system.

Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.

Expected results: Equivalence between the Python and C++ job module interfaces, and a comprehensive testing mechanism for Python job modules.

Knowledge Prerequisite: At least some C++ and Python experience is required; experience with CMake, Boost.Python and software testing is a plus but not a hard requirement.

Mentor: Teo Mrnjavac <[email protected]>, teo- on Freenode

Project: Debian installer support

Brief explanation: Calamares is just a job executor at its core, and Calamares jobs are provided by Calamares modules. Some of these modules are common for most Linux distributions, and some might be heavily distribution-specific.

Calamares is already capable of installing a Debian-based system, simply by unpacking a squashfs image like most other distributions, but this is less than ideal: Debian already provides a sophisticated install system (debian-installer), and Calamares should take advantage of it.

The student should propose a detailed action plan, with the ultimate deliverable being one or more job modules that implement a system install procedure based on debian-installer. Additional changes to the user interface (view modules) may or may not be needed for this, depending on the feature set proposed by the student. From a top-down point of view, Calamares should behave like a debian-installer frontend, not unlike Ubiquity, but without compromising its distribution-agnostic design.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Expected results: Calamares should be able to install a Debian based system using debian-installer as backend.

Knowledge Prerequisite: The student should have experience with a Debian based distribution and C++; experience with Python, debian-installer and Debian packaging is a plus.

Mentors: Rohan Garg <[email protected]>, shadeslayer on Freenode; Teo Mrnjavac <[email protected]>, teo- on Freenode

Project: LUKS support

Brief explanation: KPMcore (the library used as a partitioning backend in Calamares and KDE Partition Manager) currently only has very basic support for opening/closing LUKS volumes. Full LUKS support is needed, with all operations exposed in an interface, and this then needs to be used in Partition Manager and Calamares.

A work in progress of this task is available in the luks-decorator branch of KPMcore.

The student should propose a detailed action plan, with the ultimate deliverable being full LUKS support in Calamares and KDE Partition Manager. Intermediate deliverables must be listed in the proposal, with as much granularity as possible.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Expected results: Calamares should be able to install a system on one or more LUKS volumes, and both Calamares and KDE Partition Manager should offer a full set of LUKS setup/remove/open/close/… operations to the user.

Knowledge Prerequisite: The student should have experience with Qt and C++. Previous experience with using LUKS is a plus.

Mentors: Teo Mrnjavac <[email protected]>, teo- on Freenode; Andrius Štikonas, stikonas on Freenode

digiKam

digiKam is an advanced digital photo management application for Linux, Windows, and Mac-OSX.

Project: digiKam MySQL / MariaDB Database support

Brief Explanation: Since a while, the MySQL database support in digiKam was not completed and unfinalized. The digiKam database interface is modular and new kind of database type can be added. Currently Sqlite support work fine since a while, but it’s limited to a local storage with a single user. SQlite is not adapted to be used in photo agency workflow where more than one digiKam need to access to a remote and common database storage located on a remote server. This typical use case can be resolved by using MySQL/MariaDB database. Expected results:

Review current whole database implementation including database schema hosted as XML.
Review current dysfunctions and missing features in database interface and schema.
Review of all use cases in photo agency with a centralized database storage.
Implement/Rewrite code/schema for MySQL support and MariaDB.
Write unit tests for database interface and documentation.

Knowledge Prerequisite:

Database, MySQL/MariaDB, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Marcel Weisweg

Project: digiKam MetadataHub improvements

Brief Explanation: while GSoC 2015, a new metadata wrapper have been introduced to digiKam core. This one work as a hub between image metadata and database. The user can route which kind of metadata can be used to populate the database by priority order when items are parsed. In inverse way, the hub will define which image metadata will be populated by digiKam database when user will synchronize images. At previous GSoC, a low level hub have been implemented with a configurable graphical interface. Only few metadata types are currently supported as rating comment and tags. The goal of this project is to implement more metadata types in the hub rules, as GPS info, tags from proprietary photo management software, Copyrights, etc... Expected results:

Review current whole metadata hub implementation including current metadata rules supported.
Review all missing cases to wrap metadata with database and vis versa (bugzilla include a lots of uses cases reported by end users).
Implement new low level rules in hub with relevant settings in configuration panel.
Write unit tests for metadata hub and documentation.

Knowledge Prerequisite:

Metadata, database, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Marcel Weisweg

Project: digiKam automatic Red Eyes detection and correction

Brief Explanation: digiKam include a basic tool to fix red eyes in image editor. there is no automatic mode (detection and fix). The goal of this project is to review code write a low level code to detect and fix red eyes automatically, and include this tool in image editor and Batch Queue Manager. The tool must be able to support 8/16 bits color depth images and must be multi-threaded on multi-core CPU. Expected results:

Review current code from older RedEyes Removal kipi tool which include some interesting algorithms.
Check all features required by the tool in all use cases. Select best algorithm (OpenCV).
Implement low level filter for red eyes detection and fix.
Implement GUI and integration into image editor and BQM.
Write unit tests and documentation.

Knowledge Prerequisite:

Image processing, OpenCV, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Maik Qualmann

Project: digiKam database export to DLNA/UPNP

Brief Explanation: In the past, Kipi-plugins provide a way to export KIPI host data to DLNA/UPNP by a plugin using HUpnp library for Qt. Since Qt5 port this tool do not work anymore as HUpnp project is dead and code is not ported to Qt5, even if we have tested some implementation from GitHub ported to Qt5. The goal of this project is to find a new way to restore this feature in digiKam core directly (not as a plugin), using a suitable solution to support UPNP/DLNA in the long term. Expected results:

Review old plugin code DLNAExport. Review all required features to export digiKam contents through a DLNA server.
Implement a DLNA server in digiKam core to export photo and video hosted in physical and virtual collections. The server must have the capability to be restored at each digiKam session.
Implement the server configuration panel in digiKam setup.
Test the new implementation with DLNA compliant devices, as smartphones, tablets, TVs.
Write unit tests and documentation.

Knowledge Prerequisite:

DLNA/UPNP, C++, and Qt

Mentor: Gilles Caulier (IRC: cauliergilles) and Maik Qualmann

KDE Edu

Gcompris

Project: Add educational activities to GCompris (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:

Porting remainings activities from the Gtk+ version to Qt Quick. You can find missing activities to port that will help you select the activity set you are interested in (tasks start with ”Port of Gtk+”).
Creating new activities. There is a list of ideas of activities that have been identified as something we would like to have. You can also propose original ideas not on the list.
Adding core features
Refining current activities: some can be improved, whether improving the animation, adding sounds, tutorials...

Knowledge Prerequisite: By the start of GSoC you should 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: Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphics and the sounds are already available. You can count at least 2 weeks of development for an activity. To keep the work interesting it is recommended to propose a mix of porting some activities and creating new one, either from the idea list or from an original idea you come with. You have to follow the instructions here and provide your exercise as a pull request. Feel free to contact us either on irc or by mail ([email protected]) Mentors: Bruno Coudoin (IRC: bdoin #gcompris on freenode), Johnny Jazeix (IRC: JohnnyJ), Bharath M S (IRC: brat197), Sagar Chand Agarwal (IRC: sagaragarwal94)

Minuet (Software for Music Education)

Minuet will become part of KDE-edu suite of educational applications in version 16.04 and aims at supporting students and teachers in many aspects of music education, such as ear training, first-sight reading, solfa, scales, rhythm, harmony, and improvisation. Minuet makes extensive use of MIDI capabilities to provide a full-fledged set of features regarding volume, tempo, and pitch changes, which makes Minuet a valuable tool for both novice and experienced musicians. Minuet features a rich set of ear training exercises and new ones can be seamlessly added in order to extend its functionalities and adapt it to several music education contexts.

Additional Information: - Blog posts: http://sandroandrade.org/tag/minuet/ - Demonstration video: https://www.youtube.com/watch?v=IxmyevpFErU (watch in HD) - IRC channel: #kde-edu - Mailing list: https://mail.kde.org/mailman/listinfo/kde-edu - Contact: sandroandrade AT kde DOT org

Project: Student’s Performance Metrics and Flexible Exams

Brief explanation: Minuet currently provides a set of exercises for some aspects of music education. Such exercises are defined in JSON files, which indicate the available answers for a given exercise category and how to play each answer. Users are able to choose an exercise and execute it many times, getting a 'correct' or 'wrong' result in each attempt. This project aims at implementing a flexible mechanism for defining customized exams and gather some performance metrics after finishing the evaluation. Some mechanism for storing answers and, potentially, sending them to the teacher afterwards is also expected.

Expected results:

Implementation of a flexible mechanism for customizing exams.
Implementation of a set of performance metrics (hit rate, average answer time, etc).
Implementation of a mechanism for storing and sending answers to the teacher.

Knowledge Prerequisite:

C++/Qt/QML
No music background required

Mentor: Sandro Andrade (IRC: sandroandrade)

Project: Minuet Mobile

Brief explanation: Minuet has reached a stable status in Linux but having it running in mobile platforms like Android is of paramount importance. This project aims at implementing a functional version of Minuet for Android platform. That requires investigate the use of MIDI capabilities in Android and check whether the current ALSA-based solution currently adopted in Linux can be reused. Also, a proper MIDI backend (akin to TiMidity++/Freepats) for Android should be devised. Another possible path, is to get rid of MIDI capabilities and built the playing features upon another sort of technology.

Expected results:

A working version of Minuet for Android, featuring the basic exercises presented in its Linux version.

Knowledge Prerequisite:

Android development
C++/Qt/QML/Material Design
MIDI/ALSA

Mentor: Sandro Andrade (IRC: sandroandrade)

Project: Singing and Clapping Capabilities

Brief explanation: current Minuet human-interaction mechanism comes down to the use of mouse clicks to point out the answer for a given ear training exercise. Obviously, singers and drummers/percussionists wouldn't have any valuable benefit of using Minuet unless it provides some mechanism to get exercises' answer from singing and clapping data captured from a computer-connected microphone. This project aims at implementing the features for recognizing pitch from voice data and hits from clapping data, both acquired from the computer microphone.

Expected results:

A reliable (to some extent) mechanism for detecting pitch from voice data
A reliable mechanism for detecting clapping from audio data
Both mechanisms may require calibration

Knowledge Prerequisite:

C++/Qt/QML
Digital Signal Processing

Mentor: Sandro Andrade (IRC: sandroandrade)

KDE Partition Manager

Project: LUKS support

A work in progress of this task is available in the luks-decorator branch of KPMcore.

Once all the milestones have been achieved there are various related tasks to be done and bugs to be fixed. Drop into #calamares to say hi and discuss your proposal.

Knowledge Prerequisite: The student should have experience with Qt and C++. Previous experience with using LUKS is a plus.

Mentors: Teo Mrnjavac <[email protected]>, teo- on Freenode; Andrius Štikonas, stikonas on Freenode

KDevelop

Project: KDevelop: LLDB Support

Brief explanation: Write a new plugin to support LLDB on KDevelop

Come up with a new kdevelop plugin so that LLDB can be used as a debugging solution, especially on Mac OS X and Windows, where gdb support is rather scarce. Bonus points for making sure your plugins works on other platforms than Linux, i.e. Windows and OS X. Expected results: LLDB support in similar feature-completeness as KDevelop’s GDB support Knowledge Prerequisite: C, C++, GDB/LLDB, Qt, debugging intrinsic problems Mentor: KDevelop Team, Kevin Funk <[email protected]>

Project: KDevelop: Compiler Kits

Brief explanation: Extend KDevelop in a way it can help users select their intended compilers/Qt versions/debugger versions, etc. Let’s face it, we want something very similar to what QtCreator offers: http://doc.qt.io/qtcreator/creator-targets.html This should be especially pave our way on Windows, where we currently cannot select a Visual Studio or MinGW compiler environment from within KDevelop. Bonus points for making sure this all works super smooth on other platforms than Linux, i.e. Windows and OS X Expected results: Compiler selection / Qt version selection / Debugger selection/ Kit selection features Knowledge Prerequisite: C, C++, Qt, software architecture Mentor: KDevelop Team, Kevin Funk <[email protected]>, Milian Wolff <[email protected]>

Project: KDevelop: Improve QML/JS integration

Brief explanation: Extend the QML/JS plugin we started a while ago, cf. http://steckdenis.be/post-2014-08-18-google-summer-of-code-2014-qmljavascript-language-support-for-kdevelop-4-and-5.html We’d like to extend it as much as possible, including the following features: Be able to specific import paths for QML plugins Proper handling of QRC imports Add navigation capabilities to import statements Integrate https://www.kdab.com/kdab-contributions-qt-5-4-qmllint/ Probably many more which I cannot think of right now Expected results: All above bullet points resolved, and probably more Knowledge Prerequisite: C, C++, Qt, QML/JS Mentor: KDevelop Team, Milian Wolff <[email protected]>

Project: KDevelop: Enhanced support for working with microcontrollers

Brief explanation: List of things I can think about which would maybe be useful (feel free to add more / remove the ones you don’t think are useful): First of all, a controller-specific debugger would be cool. As the debugger backend, you usually use gdb; but what commercial IDEs do and which is really nice is having a tool view which allows to inspect the controller's hardware registers without typing all the addresses, in a kind of table. The addresses and structs could probably be parsed out of the headers in the project, using some simple heuristics. In the debugger, somewhere display the current stack pointer and program counter, and maybe stack size. Maybe allow launching a debug server with openocd. An action to reset the chip (can usually be done through gdb). An action to program the chip (can be done through gdb but might also be an external script). It would be good to have this as a possible item in the "build" dependency chain. This probably arcs over into Aleix’ "deployment infrastructure" plans. Would be nice to have some working templates for some common chips. "Implement function" for (undeclared?) extern functions, maybe needs to look at __attribute__(weak) and similar nonstandard C stuff Sometimes it would be nice to display the absolute memory address of a struct member for structs in the tooltip, if the struct instance has a compile-time-known location. There seem to be a few general issues with C support in KDevelop (files not highlighted at all, …). This needs to be investigated a bit, but you can certainly get help on the clang part (if necessary) from knowledgeable people in the KDevelop team. Many C functions have lots of parameters. Maybe one could display the parameter name when moving the mouse over the argument which is passed in? That'd also be nice for cpp sometimes. Completion support for C's Foo foo = { .member = value } syntax Maybe there's an easy way to find out how much space a function's code takes up in flash memory? Eventually we can build code in the shipped templates with cmake? I think there are toolchain files for e.g. armv7 cross compilation etc Think about how we can handle / provide / support the vendor’s “standard libraries” for the controller(s) Think about how we can maybe at least ship a set of .ld files for common chips (certainly we can borrow those somewhere?) Expected results: Get to a point where people consider using KDevelop to develop their microcontroller firmware, maybe limited to a certain controller family in the beginning if the scope proves too broad (I’d suggest the stm32 family and related chips). You do not have to implement all the points above, that is just a list of ideas. The goal is to get to a point where there is some kind of usable workflow which provides benefits over what other IDEs do (which should not be too difficult, since a very good basis for C language support is already in place, far superior to what most competing IDEs for this scope I have seen so far can offer). Knowledge Prerequisite: C, C++, a bit of Qt; you definitely need some prior experience in microcontroller programming to do useful work on this and you definitely need some hardware at home as well for testing (e.g. some STM32 demo board+JTAG debugger) Mentor: KDevelop Team, Sven Brauch <mail at svenbrauch dot de>

Project: KDevelop: Go language integration

Brief explanation: Come up with a plugin to integrate Google’s Go language We’re very open for ideas here, this is more or less a R&D topic. Go is becoming more and more popular, and KDevelop might be a good candidate for a superb IDE for Go. Support for Go language using one of the existing language parsers Use of a custom parser is discouraged Debugger integration https://golang.org/doc/gdb, or https://blog.cloudflare.com/go-has-a-debugger-and-its-awesome/ … the proposal counts! Note there’s an existing KDevelop Go plugin here (unfortunately using a custom parser which we’d like to avoid if possible): https://projects.kde.org/projects/playground/devtools/plugins/kdev-go More information here: http://comments.gmane.org/gmane.comp.kde.devel.kdevelop/42874 Expected results: Go language support, and some kind of debugger integration for Go Knowledge Prerequisite: C, C++, Qt, Go Mentor: KDevelop Team, Kevin Funk <[email protected]>

Krita

Krita: digital painting for artists. It support creating images from scratch from begin 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:

Project: Extending Animation Support with masks and curves

Brief Explanation: 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 generic curve editing widget that can be reused in other places
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

Knowledge Prerequisite:

C++ and Qt

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk_log)

Project: Soft-proofing and other color management improvements

Brief Explanation: Color management lies at the core of Krita. All images, all display functions, all color selectors are color managed in Krita. What is missing is soft-proofing: displaying which colors are out-of-gamut for the intended target device. This is needed so the user can make informed color choices. Krita is also unique in allowing users to paint in HDR color spaces, which offers additional gamut and clamping problems, both when painting and in the color selectors.

Expected Results:

A working soft-proofing implementation for both the OpenGL and CPU canvas.
Gamut-warnings in all color selectors
Warnings when clamping when using floating point color spaces.

Knowledge Prerequisite:

C++, Qt, LCMS, Color theory

Mentor: Boudewijn Rempt (IRC: boud), Stefano Bonicatti (IRC: smjert) or Dmitry Kazakov (IRC: dmitryk_log)

Project: Making Krita Canvas Decoration Painting Code OpenGL 3.2 compatible

Brief Explanation: When Krita was ported to Qt4, one of the great new innovations Qt offered was an OpenGL based QPainterEngine, allowing us to use the same code to draw canvas decorations (such as tool lines, selections etc.) on the OpenGL and on the GPU canvas. Fast-forward to 2016: the OpenGL QPainterEngine is not compatible with the OpenGL 3.2 Core Profile and on OSX and Windows/Intel, Krita's OpenGL canvas is broken. We have two options: port the QPainterEngine to OpenGL 3.2 Core Profile, or rewrite all places in Krita where we use QPainter on an OpenGL widget. Expected Results:

Either: a ported QPainterEngine (which we can then upstream to Qt)
Or: an implementation of Krita's canvas decoration classes that uses OpenGL 3.2 directly

Knowledge Prerequisite:

C++, Qt, OpenGL, GLSL

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 revampted and exciting shapes brush Knowledge Prerequisite:

C++, Qt, Krita

Mentor: Boudewijn Rempt (IRC: boud) or Lukas Tvrdy (IRC: LukasT)

Project: Implementation of experimental OpenCL support for layer composition, filtering and painting

C++, OpenCL

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Implementation of experimental OpenGL-enabled brush

Brief Explanation: Krita in the current state relies purely on CPU power for vast majority of operations. Many of them can be offloaded onto GPU. This will improve performance due to high throughput of parallel operations and potentially will enable power-efficient port of Krita for mobile devices. Expected Results: this is another experimental GPU-related project that allows the user to paint over the canvas purely on GPU. But this project relies on a different technology: openGL. There should be a special kind of layer that is stored in GPU memory and a special tool that is capable of painting over this layer. The tool should be able to use basic Krita brush presets (for the Pixel Brush engine) to paint over the canvas with the speed of lighting. To make this project easier, we put a limitation: this special layer should be on the top of the layers stack and therefore, just painted over the Krita openGL canvas. Knowledge Prerequisite:

C++, OpenGL

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Extending animation by adding a sound channel and scratchpad on the timeline

Brief Explanation: Krita now has a support for doing animations. But it is suboptimal for people who do a character animation over the existing sound channel (most of the studios work this way). Krita should be able to attach a sound channel to the timeline, then the user should be able to paint over the timeline to mark the places where the character tell specific words. Links: A lesson by Aaron Blaise: https://www.youtube.com/watch?v=rYPx6sGZzow Expected Results: GUI for the sound channel visualization and a skratchpad. Ability to play sound with the specified frame rate (exactly the one Krita is playing animation at the moment). Knowledge Prerequisite:

C++, Qt, Sound Processing

Mentor: Boudewijn Rempt (IRC: boud) or Dmitry Kazakov (IRC: dmitryk|log)

Project: Add Python Scripting to Krita

Brief explanation: Krita has had two attempts at scripting support: through kjs and through kross. Neither was good enough. The VFXindustry standard for scripting is Python, and the goal of project is to integrate Python and PyQt directly into Krita. Expected results: by the end of the summer, users should be able to automate repetitive tasks, file import and export and add gui elements such as dockers, all written in PyQt. Knowledge Prerequisite: Deep knowledge of Python, SIP, C++ and Qt. Mentor: Boudewijn Rempt (IRC: boud)

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: Boudewijn Rempt (IRC: boud)

KStars

KStars is a very powerful tool for anyone interested in astronomy. It is part of the KDE Edu suite.

Project: Seamless retrieval of data on deep-sky objects in KStars from the internet

Brief explanation: [A longer, detailed technical explanation for this project giving explanations for the astronomy jargon involved is available here.] KStars already has a database that supports the download and display of catalogs of deep-sky objects. The aim of this project is to implement yet another database for the download and display of “variety” deep-sky objects without being bound to a given catalog; then, build machinery to download object data from the CDS Sesame resolver and put it into this database. Finally, this would mean that the user could seamlessly look up an object that KStars knows nothing about, and KStars will fetch the required info from the internet.

Expected results: by the end of summer, a user should be able to type into the KStars “Find dialog” the name of an object that KStars has no data on. KStars should fetch the data from the internet, create an object in KStars’ database, and take the user to its location.

Knowledge Prerequisite: C++, Qt, XML parsing, SQL

Mentor: Jasem Mutlaq (IRC: knro), Akarsh Simha (IRC: kstar)

Project: KStars Lite

Brief explanation: Currently KStars only runs on desktop/laptop computers. Due to the proliferation of tablet/mobile devices, a lite version of KStars should be available to users on these form factors. The goal is to develop a QML/QtQuick2 frontend for KStars with basic functions:

Sky map: Pan, zoom...etc
Search
Color schemes
Simulation time
Location/Time from mobile/phone or by user
Optional: Projection Systems
Optional: FOV Symbols

The student is expected to work initially on separating GUI/Data coupling in KStars, and then write a QML/QtQuick2 frontend to present the necessary functionality to the user. The work must be performed against the primary branch, i.e. there will be no separate application specific for tablet/mobile, all form factors must share the same code base. The sky map shall contain the default stars and DSO catalogs with possibility of additional catalogs in the future.

Expected results: Lite version of KStars for Mobile/Tablet form factors.

Knowledge Prerequisite: C++, Qt, QtQuick2

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: KStars on Windows

Brief explanation: While KStars is available on Windows by KDE via the KDE Windows Initiative, it is out of date and requires a lot of installation prerequisites in KDE4. The primary goal is to develop a single KStars installation Windows executable to install KStars and any prerequisite libraries in KDE5/Qt5. The secondary goal is to use ASCOM under Windows to drive telescopes. KStars relies on INDI Library to control astronomical devices in Linux, and currently INDI Library is not available on Windows. You need to update KStars to accommodate ASCOM telescopes under Windows. The student may utilize any open source and/or free installation frameworks to build the final executable.

Expected results: KStars single executable for Windows. ASCOM telescope support under KStars for Windows.

Knowledge Prerequisite: C++, Qt, INDI/ASCOM

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: DSS Overlay

Brief explanation: DSS is a digital version of an all-sky photographic atlas. The goal is to add a KStars component to superimpose the DSS images unto the sky map. Therefore, the end user shall be able to view the real sky view against the simulated sky map. The user should be able to enable/disable the overlay just like any other sky component (e.g. Milky Way). Utilize DSS tiles spanning 1x1 square degrees for a total of 41253 tiles all over the sky map. Due to the storage and resource limitations, the tiles should be only displayed at high zoom levels starting with FOV 10 degrees or lower.

Expected results: DSS overlay component covering the whole sky.

Knowledge Prerequisite: C++, Qt

Mentors: Jasem Mutlaq (IRC: knro)

The student will need to:

Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC time frame.
Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2016.

Project: Propose your own project

Brief explanation: If you have some interesting ideas about KStars that can be implemented within the GSoC timeframe, you are very welcome to propose them, because we seem to have run out of ideas.

Mentors:

KWin

Project: Running KWin/Wayland in a Docker container

Brief explanation: In order to more easily test our software and to provide an emulator for Plasma mobile we need to be able to use KWin/Wayland in Docker. Running in Docker requires that the visual output goes to a different windowing system (e.g. X11/Wayland) living outside the container. The access to this windowing system must be made available for KWin inside the Docker container, but not to other applications inside the container. Furthermore it must be possible for KWin to use host OpenGL functionality and not be restricted to llvmpipe based OpenGL.

Expected results: By the end of summer KWin can run in Docker.

Knowledge Prerequisite: C++, containers, unix sockets

Mentor: Martin Gräßlin <[email protected]>, Bhushan Shah <[email protected]>

Project: Layered compositing in KWin/Wayland

Brief explanation: Modern GPU supports layered rendering. A frame can consist of multiple layers which are composed directly by the GPU. For KWin/Wayland this is an interesting technology as it allows to bypass the OpenGL based compositor. Instead of rendering each window into a static OpenGL buffer and presenting that, each window can be passed into a layer and the layers can be composed directly by the hardware. This means that less rendering needs to be performed resulting in less power consumption and longer battery life.

The task of this project is to implement an infrastructure in KWin to allow passing windows to layers instead of rendering through the OpenGL compositor. KWin internally has already decent knowledge whether OpenGL will be needed or not. The important part in this project will be to add support to the DRM backend to know whether layers are supported and whether the current frame can be composed this way. The new atomic mode setting API can and should be used for this. The new code in KWin needs to be flexible enough to also support the hwcomposer backend. More information about the idea at https://blog.martin-graesslin.com/blog/2015/08/layered-compositing/

Expected results: DRM backend can use layered compositing

Knowledge Prerequisite: C/C++

Mentor: Martin Gräßlin <[email protected]>

Project: Wacom Tablet support in KWin/Wayland

Brief explanation: A Wayland compositor needs to forward input events. So far KWin and KWayland does not yet have support for tablet events.

The task of the project is to implement support in KWayland on both client and server side. KWin receiving tablet events from libinput and forwarding them to the Wayland server. An example application for testing might be Krita.

Having access to a Wacom tablet or similar might be helpful.

Expected results: Tablet support in KWin/Wayland.

Knowledge Prerequisite: C/C++, Wayland

Mentor: Martin Gräßlin <[email protected]>

Project: Window Tab support in KWin

Brief explanation: KWin used to support window tabs in the window decoration. This got lost with the switch to the new KDecoration2 API. But the code in KWin still exists and could easily be reactivated. All it needs is support for in KDecoration2.

The task of this project is to add the missing API in KDecoration2 and hook KWin to it. In addition the default decoration (Breeze) should be extended to support it. This has to be done in close collaboration with the Visual Design Group

Expected results: Window Tab support in KWin and Breeze

Knowledge Prerequisite: C++, Qt

Mentor: Martin Gräßlin <[email protected]>

LABPLOT

LabPlot: application for interactive graphing and analysis of scientific data.

Project: add support for the FITS format

Brief Explanation: FITS is an open standard widely used in the astronomy: https://en.wikipedia.org/wiki/FITS Currently LabPlot lacks any support for this format. The goal of this project is to add the support for this project and to provide basic editing and navigation features similar to those available in e.g. FITS Liberator (https://en.wikipedia.org/wiki/FITS_Liberator) or other similar programs. Have a look at the handling of FITS in kstars and investigate how much of kstar’s code and ideas can be used in LabPlot. Expected results:

Use NASA’s libcfitiso to add the support for this format
Import datasets and images from FITS like it is currently possible for other supported formats (assii, binary, netCDF, HDF5)
Write documentation

Knowledge Prerequisite: C++, Qt

Mentor: Stefan Gerlach ([email protected])

Project: extend the 3D-plotting part

Brief Explanation: During GSoC2015 basic 3D-functionality was added to LabPlot. This part needs to be extended, core features needs to be finalized and prepared for a release. The summary of what was already achieved can be found here https://minh.fedorapeople.org/2015/08/21/gsoc-last-report.html

Expected results:

Finalize the plotting of points, curves and surfaces in 3D based on the already existing infrastructure and features in the code
Write documentation

Knowledge Prerequisite:

C++, Qt, VTK

Mentor: Alexander Semke ([email protected])

Project: import data from SQL-databases

Brief Explanation: Currently, the data can only be imported from external files. The goal of the project is to add the ability to import from SQL-databases. Expected results:

Implement a “connection manager” to create and to store connections to different SQL-databases
In the sql-import dialog provide features to define which columns to import and with wich filters
Alternatively, the user should be able to select the data via a SELECT-statement. For this a text editor with syntax highlighting and code completion for SQL should be added.
Import from a database to LabPlot’s spreadsheet should be done similar to the import from external files
Write documentation

Knowledge Prerequisite:

C++, Qt, basic SQL and QtSql knowledge

Mentor: Alexander Semke ([email protected])

Project: theme manager for plots

Brief Explanation: LabPlot provides many features for editing the appearance of the plot. Though it is helpful in many cases to modify the appearance in great detail, it is also useful to have a set of predefined themes like “black curves on white background”, “white curves on black background”. With the help of such themes the user should be able to achieve nice looking results more easily.

Expected results:

Implement a theme manager: it should be possible to save the current appearance as a new theme and to load one of the already saved theme
Provide couple of nice themes that will be delivered with the application
Add support for KDE’s “Get Hot New Stuff”
Write documentation

Knowledge Prerequisite:

C++, Qt, some taste for good looking plots

Mentor: Alexander Semke ([email protected])

Plasma

Project': Plasma mobile emulator that allows to test shell and applications easily on desktop

Brief explanation: Not all app developers have access to mobile devices that is capable of running Plasma mobile. This project aims to have Plasma mobile emulator similar to Android Virtual device which developers can use to test applications and get idea of how it would look on the phone.

Expected results: By the end of summer, developers should be able to easily test applications and shell on their desktop/laptop.

Knowledge Prerequisite: Qt, QML, C++

Mentor: Bhushan Shah <[email protected]>

Project: Port Libreoffice VCL skin to Qt 5

Brief explanation: make a Qt 5 skin for Libreoffice

Expected results: Libreoffice looks good

Knowledge Prerequisite: Elite c++ skillz

Mentor: Jonathan Riddell, Jan from Libreoffice

Try updating this build system starting patch https://gerrit.libreoffice.org/#/c/13078/ which just renames qt4 skin

Note: could also be done as a Libreoffice project

WikitoLearn

Collaborative textbooks: http://wikitolearn.org/ | Mail list: https://mail.kde.org/mailman/listinfo/wikitolearn | http://meta.wikitolearn.org/Communication_channels

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

Category:

Mentoring

@@ Line 626: / Line 626: @@
 === Plasma ===
-'''Project''': Plasma mobile emulator that allows to test shell and applications easily on desktop.
+==== Project': Plasma mobile emulator that allows to test shell and applications easily on desktop ====
 Brief explanation: Not all app developers have access to mobile devices that is capable of running Plasma mobile. This project aims to have Plasma mobile emulator similar to Android Virtual device which developers can use to test applications and get idea of how it would look on the phone.
@@ Line 636: / Line 636: @@
 Mentor: Bhushan Shah <[email protected]>
-'''Project''': Port Libreoffice VCL skin to Qt 5
+==== Project: Port Libreoffice VCL skin to Qt 5 ====
 Brief explanation: make a Qt 5 skin for Libreoffice