GSoC/2016/Ideas

GSoC 2016 logo

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

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

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

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) 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; Jonathan Riddell <[email protected]>, Riddell on Freenode

Project: LVM and 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. LVM support should also be researched and added to 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 LVM and LUKS support in Calamares and KDE Partition Manager. Intermediate deliverables must be listed in the proposal, with as much granularity as possible. If LUKS support gets otherwise implemented before the start of GSoC, the student should focus on LVM and possibly RAID.

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 LVM and/or LUKS volumes, and both Calamares and KDE Partition Manager should offer a full set of LVM and LUKS operations to the user.

Knowledge Prerequisite: The student should have experience with Qt and C++. Previous experience with partitioning application development 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.

• digiKam project web site
• Exiv2 project web site
• digiKam port to KF5 status
• Mailinglist
• Google+ page
• #digikam IRC channel on Freenode

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

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

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

Keyboard Layouts

Keyboard layouts in KDE software allow user to use multiple keyboard layouts and switch between them. It consists of keyboard configuration module (in System Settings), keyboard layout widget/applet, and keyboard layout daemon.

Project: Automatic layout switching based on text input context

Brief explanation: Currently when user switches to the input field he always have to switch keyboard layout. Remembering last layout per application window helps a bit but even the same window may have different languages to accept. It would be nice if we can use the context of the text input to try to switch layout automatically. E.g. if user enters text in the browser we could check the language of the html page and adjust the keyboard layout accordingly. Note: this might be not a short term project but we could lay out some foundation in GSOC.

Expected results: There is a lot of research in this feature. We need to find out what input contexts are detectable, what information about the language we can extract, which additional options we need (e.g. automatic choice might work poorly in some environments so we might need to let user disable it for some applications/windows etc), also if automatic choice was made and user had to switch manually to correct we may try to remember that and adjust the automatic switching accordingly next time. If we can have good description of potential contexts, their language tags, and some code to detect those contexts and languages that would be a good result for this project. If we can do more that would be fantastic.

Knowledge Prerequisite: C++ and Qt.

Mentor: Shivam Makkar <[email protected]>

Kopete

Kopete is an instant messenger supporting AIM, Bonjour, Gadu-Gadu, GroupWise, ICQ, Jabber (XMPP, Google Talk, Facebook, ...), Meanwhile, QQ, Skype, Windows Live Messenger, WinPopup, Yahoo and more. It is designed to be a flexible and extensible multi-protocol system suitable for personal and enterprise use.

Mailing list: [email protected] (archive at: lists.kde.org)

Project: Jabber message archive

Brief explanation: When you use more jabber clients and you want to have full chat history in all clients, you need to synchronize message history between all clients. To make it easier for different jabber clients, there is jabber protocol extension for storing history directly on jabber servers which allows clients to download (missing) messages:

XEP-0136: Message Archiving

XEP-0313: Message Archive Management

Expected results: Working support for XEP-0136 or XEP-0313

Knowledge Prerequisite: C++/Qt, Jabber protocol

Mentor: Pali Rohár <[email protected]>, Pali on #kopete

Project: IRC protocol

Brief explanation: Kopete KDE3 version had plugin for IRC protocol. Porting that IRC plugin to new KDE versions was never finished and Kopete does not have working support for IRC yet.

Expected results: Restore IRC protocol into Kopete

Knowledge Prerequisite: C++/Qt, IRC protocol

Mentor: Pali Rohár <[email protected]>, Pali on #kopete

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

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: Architecture for OpenCL module which allows to interact with existing code seamlessly and preliminary support for GPU acceleration. Ideally, there should be a separate tool that paints directly on a OpenCL/OpenGL buffer stored in GPU memory. This buffer should be painted over the existing Krita canvas.

Knowledge Prerequisite:

• 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: 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:

1. Sky map: Pan, zoom...etc
2. Search
3. Color schemes
4. Simulation time
5. Location/Time from mobile/phone or by user
6. Optional: Projection Systems
7. 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

WikiToLearn is a collaborative platform to create, refine and create collaborative textbooks.

Project: Plots and image creation while editing

Brief description: Plots and similar type of scientifical images are extremely needed while editing scientifical documents. However, the current technology requires the contributor to create SVGs using a variety of their own skills, which leads to many inconsistent images of very different qualities. Also, it becomes very hard to collaborate on SVG renders. The scientifical world has created exist tools such as tikz, which produce beautiful graphics, but it’s not possible to upload source files directly in the wiki. The idea is to provide an extension that can render these images from the source, such as <tikz>..image..</tikz>. Tikz is just an example, we can of course go beyond that.

Expected results: Being able to either upload graphics from other graph applications or having a Special page with an editor.

Knowledge prerequisites:

• Mediawiki (Extensions and basic framework)
• Some graph framework that you choose to use

Mentor: Riccardo Iaconelli, Davide Valsecchi, Gianluca Rigoletti

Project: Discoverability of content

Brief description: At WikiToLearn, we aim to provide textbooks with insight in all possible fields of human knowledge. That is a sheer lot of content. Things get worse when we don’t have a unique path through books, and information might be scattered in many different places. We need to make content discoverable and accessible, so that people can study and eventually assemble new books. We have to organize naming schemes and interfaces in a way that don’t discourage collaboration and forking, but still prove efficient in indexing and researching material.

This idea is a challenge that requires way more thinking and way less techical implementation than average, but could be a very interesting work if you’re a data freak. :-)

Expected results: Easier discoverability of content. This is really dependent on what you want this to be.

Knowledge prerequisites: Depends on the path you take to make the project happen.

Mentor: Riccardo Iaconelli, Irene Cortinovis, Russell Greene

Project: Book navigation/usability on the web

Brief description: At WikiToLearn, we aim to provide textbooks with insight in all possible fields of human knowledge. Things get worse when we don’t have a unique path through books, and information might be scattered in many different places. In those situations, simple concepts such as “index” stop to make sense.

The idea is to implement a “smart” index, which considers the path of the student through the website, and in general all the needed tools that can provide a usable and easy way to navigate through WikiToLearn manuals.

Expected results:

• An easy-to-navigate interface for reading books and going through chapters

Knowledge prerequisites:

• Mediawiki extension development

Mentors: Riccardo Iaconelli, Russell Greene

Project: WikiToLearn Metrics

Understanding and optimizing the usage of the website's users

Brief Explanation: Understanding participation and involvement from contributors is key to create useful workflows, a vibrant community and high quality content. It is also important to report back to universities that decide to experiment with WikiToLearn about the activity of students and professors. We need to study which metrics make more sense, extract the data from the logs and the software, and try to convert identified issues into possible actions

Expected Results:

• A study on which metrics provide the most information for the WikiToLearn usecases
• The collection/aggregation of those informations, where we don’t have this data already
• The implementation of an interface where these metrics and available for study
• (bonus) investigate and propose solutions to fix the potential issues that might arise

Knowledge prerequisites:

• Database (SQL)
• Basic Mediawiki

Mentors: Russell Greene

Project: WikiToLearn Rating

Metrics, graphs and user tracking for page quality evaluation

Brief Explanation: Pages of content on WikiToLearn could be more or less reliable and of good quality. It depends on the writer and on the connection of pages between each other. We want to develop a ranking algorithm based on user opinions. This engine should measure the user “reliability” analyzing their action on the website: edits, creation of pages, level of activity, votes. Then, these data should be used to weight user opinions in the system. The engine must deal with the developing of a page during time, being able to change the page parameter given the modifies (quantitatively). Also connection between pages could be analyzed to determine the quality of pages, using concepts of graph analysis.

Expected Results:

• A ranking engine to process data
• A Mediawiki extension to take data and show results
• Estimate of user’s reliability based on his activity on website
• Evaluation of page quality based on users’ votes, weighted on their reliability
• Analysis of the graph of pages to determine their importance

Knowledge Prerequisites:

• Mediawiki Knowledge (Extension Development)
• One of Python / Java / C++  to develop the engine

Mentor: Davide Valsecchi (@valsdav on Telegram)

Project: WikiToLearn Exercises

Platform for sharing exercises and their solutions

Brief Explanation: We want a platform deeply connected with WikiToLearn (probably an extension, or even a whole new subdomain) that allows teachers and students to share exercises on various subjects (especially scientific exercises, like Math, Calculus, Physics) and their solution (step by step, with comments and explanations). Each exercise would be connected to a related WikiToLearn page and vice versa WtL would be connected to the platform.

Expected results:

• A web application or a MediaWIki extension
• The software should be integrated with MediaWiki/WtL (same account, shared resources and theme)
• The exercises should be divided in topics
• Everyone should be able to edit the exercises
• Exercises will have to support math formulas, text, images, other rich and interactive content (plots) and explanations
• Exercises will have a place to discuss them

Knowledge Prerequisite:

• Frontend Web Development (HTML, CSS3, JS)
• Backend Web Development (PHP, MySQL databases)
• Mediawiki Knowledge (Extension Development, Templates)

Mentor: Davide Riva

Project: WikiToLearn as a Knowledge Base

Brief Explanation:

There is a lot of knowledge expressed into texts that is lost because its unstructured nature.

Could be very nice and interesting to find out a way to exploit it using a semantic approach.

Expected results:

• Defines domains and their ontologies to describe the knowledge contained in WikiToLearn

Knowledge Prerequisites:

• Semantic Web technologies
• RDF, OWL

Mentor: Alessandro Tundo

Project: WikiToLearn improved editor

Brief explanation: WikiToLearn is based on adding new content as well as editing the existing one. The current editor doesn’t offer a nice editing experience, is clunky and doesn’t even offer syntax highlighting. Math syntax is also never checked until the page is saved, which often leads to unreadable errors. We ought to provide a better one.

Expected results:

• A mediawiki extension providing a better editing experience

Knowledge prerequisite:

• Frontend Web Development (HTML, CSS3, JS)
• Backend Web Development (PHP, MySQL databases)
• Mediawiki Knowledge (Extension Development, Templates)

Mentors: Gianluca Rigoletti (@rigolo on Telegram)

Project: WikiToLearn Desktop client

Brief description: A Qt/QML app for offline usage and browsing of WikiToLearn. Discuss user experience with your mentors and get feedback and mockups from the VDG. Ideally, it would be nice to port this app to mobile environments, too.

Expected Results: A nice cross-platform browser for WikiToLearn. This could possibly contain an editor.

Prerequisites:

• Qt/QML/C++ knowledge
• Web knowledge.

Mentors: Ovidiu-Florin Bogdan, Russell Greene

Project: Integrate Akhet within ownCloud and similar services

Brief description: Akhet is an infrastructure that provides secure access to a linux-based virtual desktop on the cloud, to multiple users. It is very easy to integrate as an ownCloud app or as a SageMathCloud plugin, but this needs to be tested and studied in order to create a perfect integration with the other environments. This idea, when completed, would allow users to interact with files present on the ownCloud storage with graphical applications running directly on the server.

Expected Results: Easy user interaction with files stored on ownCloud with graphical applications running directly on the server.

Knowledge prerequisites:

• Python
• Basic Docker concepts
• A little bit of PHP and willingness to learn APIs of external services

Mentors: Luca Toma (tomaluca95 on Telegram)

Project: WikiToLearn offline editor

Brief explanation: WikiToLearn is based on adding new content as well as editing the existing one. It should be possible to permit everyone, even if offline, to create of modify a new page. The user should be able to get the same experience as editing offline. The main idea is similar to what google docs does, i.e. save the work and sync it when a connection is established.

Expected results:

• A mediawiki extension or a visual editor extension capable of working offline

Knowledge prerequisite:

• Frontend Web Development (HTML, CSS3, JS)
• Backend Web Development (PHP, MySQL databases)
• Mediawiki Knowledge (Extension Development, Templates)

Mentors: Gianluca Rigoletti (@rigolo on Telegram)