GSoC/2015/Ideas: Difference between revisions

From KDE Community Wiki
< GSoC‎ | 2015
(copy/paste of 2014 to begin 2015 Ideas)
 
 
(93 intermediate revisions by 38 users not shown)
Line 1: Line 1:
<div style="float:right">http://www.wesnoth.org/images/GSOC_2015_150x150.png</div>
[[File:GoogleSummer 2015logo.jpg |200px|thumb|right|GSoC 2015 logo]]
See also: [[../../|GSoc Instructions]], [[../../2014/Ideas|Last year ideas]]
See also: [[../../|GSoc Instructions]], [[../../2014/Ideas|Last year ideas]]


Line 54: Line 54:


'''Mentor:''' Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Freenode IRC.
'''Mentor:''' Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Freenode IRC.
===Plasma===
==== Project: Port various KDE4 Plasmoids to Plasma 5 ====
'''Brief explanation:''' When we ported from Plasma 4 to Plasma 5 some useful Plasmoids ended up not being initially ported. We want the more important existing applets to continue to run which . Students should select a few Plasmoids which they deem useful for their proposal along with some innovative ideas for improvements. Students should show knowledge of the level of work related.
'''Expected results:''' A few fully working plasmoids, polished and better than before.
'''Knowledge Prerequisite:''' QML skills. Ideally some Plasmoid experience
'''Mentor:''' Sebastian Kugler with help of the Plasma team.
==== Project: Port KSystemLog to use journald as a backend ====
'''Brief explanation:''' KSystemLog is a tool for viewing log files. This has slowly started to fail as log files moved in various distributions. Journald provides a common interface to query programatically system and user logs which will fix the main issue. Applications should impress me with their ideas utilising the available features.
'''Expected results:''' A ported to frameworks journald powered log viewer.
'''Knowledge Prerequisite:''' C++, Qt.
'''Mentor:''' David Edmundson with help of the Plasma team.
==== Project: Port various Systemsettings KCMs to QML ====
'''Brief explanation:''' The codebase of the systemsettings modules is old and needs a redesign both code-wise and UI-wise. Students should select a few KCMs and propose how to port them to the new QML/C++ hybrid with some ideas on the improvement of their UI.
'''Expected results:''' A few fully working KCM modules ported to a mix of QML and C++ that still load correctly in Systemsettings and KCMshell.
'''Knowledge Prerequisite:''' QML and C++ skills.
'''Mentor:''' Marco Martin with help of the Plasma team.
=== Various Places ===
==== Project: package install for 3rd party applications ====
'''Brief explanation:''' KDE software needs to install software in various places.  Investigate the best way to do this which is probably to use packagekit.  Then implement this in the places which need it.
'''Expected results:''' Work out best way for 3rd party programs to query and install packages.  Then adapt the following pieces of software to install the packages they need:
* dolphin file share install samba
* kcm access to install orca
* gwenview to install kipi-plugins
* kcm locale should install kde-l10n-xx
* kickoff to implement package install like kicker?
* k3b needs to install codecs (on ubuntu at least)
all this should be done in a way which works for the major distributions. 
Appstream could be used to find package names to install although support for this in Ubuntu is incomplete.
'''Knowledge Prerequisite:''' C++
'''Mentor:''' Jonathan Riddell (Riddell in #plasma on freenode IRC) with help of the Plasma team.
=== Plasma and Gluon ===
==== Project: Extend gamingFreedom.org framework to be more generic ====
'''Brief explanation:''' Over the last couple of years, the gamingFreedom.org website and server side components have been created, which implement Open Collaboration Services (OCS) in a generic and reusable form. We are now at a point where it would make sense to attempt to use this for further purposes, rather than only for gamingFreedom.org. Specifically, a new implementation of the server component employed for hosting Plasma related content is needed, and a website for presenting this content on the web.
'''Expected results:''' A new website based on gamingFreedom.org's OCS client libraries, and a server implementation for hosting Plasma content.
'''Knowledge Prerequisite:''' PHP for the client and server code
'''Mentor:''' Claudio Desideri and Dan Leinir Turthra Jensen with help of the Plasma team.
=== Kdenlive ===
Kdenlive is an intuitive and powerful multi-track video editor, including most recent video technologies. Our software is completely free, as defined by the GNU foundation. Using Kdenlive is investing in a community driven project, which aims to establish relationships between people in order to built the best video tools.
* [http://www.kdenlive.org Kdenlive project web site]
* [http://community.kde.org/Kdenlive Kdenlive wiki]
* [https://mail.kde.org/mailman/listinfo/kdenlive Mailinglist]
* [http://webchat.freenode.net/?channels=kdenlive #kdenlive IRC channel on Freenode]
==== Project: Add support for new Animation capabilities ====
'''Brief explanation:''' MLT, the media frameworks we use for rendering, has recently added a new [http://mltframework.blogspot.com/2013/06/v090-released-with-new-property.html property animation] to its objects. This allows much simpler, smoother and more general animations than the traditional keyframes technology. We then need new widgets to edit these properties, and eventually evolve our on-monitor interactions.
'''Expected results:''' At the end of the project, we should be able to add and graphically adjust these animation parameters through controls in the effects stack panel, and bonus on the monitor.
'''Knowledge Prerequisite:''' In the end you will assemble QtWidgets and interact with MLT data through C++. So you should be at ease with C++ and Qt (no need to be an expert), and have a look to the MLT manual page about animation.
'''Mentor:''' Vincent Pinon with help of the Kdenlive team.
==== Project: Redesign titler using WebVFX ====
'''Brief explanation:''' Our titler, the tool we use to add text and drawing objects over the video, relies on a home made module added to the MLT framework. Our module is limited in features, quite slow to render, and demands work to maintain. MLT has since then been plugged into WebVFX engine, which provides infinite possibilities through web technologies, and it is certainly more robust. The goal is then to port our titler to this engine, then maybe evolve the interface to offer new possibilities.
'''Expected results:''' At the end of the project, the titler should rely only on MLT WebVFX module. Bonus we should be able to add and easily edit more objects types.
'''Knowledge Prerequisite:''' First step is to translate our XML to Web formats inside the C++ code, so you should understand those dialects. For the UI rework, you would then work with Qt, in either C++ or QML.
'''Mentor:''' Vincent Pinon with help of the Kdenlive team.
==== Project: add import/export filters for video editors exchange formats ====
'''Brief explanation:''' To reduce the barrier to switch to Kdenlive, users should be able to import and export with commercial editing softwares (at least partially). Some scripts already exist to crudely parse EDL or AAF formats, the goal is to do it cleanly integrated in Kdenlive.
'''Expected results:''' At the end of the project, we should be able to exchange projects with one or more commercial tools. Effects and transitions will probably be limited, but timeline construction should be transferable.
'''Knowledge Prerequisite:''' The work will consist in manipulating XML data with Qt (C++), so you should understand those dialects.
'''Mentor:''' Vincent Pinon with help of the Kdenlive team.
==== Project: make Kdenlive work on Windows and OSX ====
'''Brief explanation:''' All the frameworks Kdenlive relies on are working on other platforms, and Kdenlive used run on those long time ago. The goal here is to setup build environments on one or two other OS's, and fix the things that prevent Kdenlive to work.
'''Expected results:''' At the end of the project, Kdenlive should work reliably on one or two commercial OS's.
'''Knowledge Prerequisite:''' Setting up and running builds, fixing things in C++, CMake, dependencies.
'''Mentor:''' Vincent Pinon with help of the Kdenlive and KDE porting teams.


=== Amarok ===
=== Amarok ===


==== Project: Lyric support improvements ====
Amarok is a Music player that helps you organize and rediscover your music.
 
* [http://amarok.kde.org Amarok project web site]
* [http://community.kde.org/Amarok Amarok wiki]
* [https://mail.kde.org/mailman/listinfo/amarok-devel Mailinglist]
* [https://plus.google.com/+amarok Google+ page]
* [http://webchat.freenode.net/?channels=amarok #amarok IRC channel on Freenode]
 
==== Project: Port Amarok to Qt5/Kf5/Plasma5 ====


'''Brief explanation:''' Amarok's support for fetching and displaying of lyrics is very limited. It just fetches from a single provider and many times no results are fetched, sometimes due to minor errors in track/album/artist name. Add some more providers of online lyrics databases. If no results are found this can be coupled with the better tagguessing feature (and even if the tags are not saved), the the lyrics providers can be searched with these guessed tags.
'''Brief explanation:''' Currently Amarok still depends on kdelibs 4.x and Qt4.
Then, improve the lyrics display. Currently it just scrolls at a constant rate, generally that's inconsistent with the actual playback of the song. All .lrc files have timestamps, that can be followed: probably by highlighting the line playing.


'''Expected results:''' Greatly increase the probability of fetching of the lyrics for any song. In the lyrics display, a highlighted line will display the current line being played.
'''Expected results:''' Amarok should compile with Qt 5.x, kdelibs4 dependencies should be replaced with kf5. Port most existing plasma widgets of the Context View to Plasma 5 (at least the most important should be ported). The default system themes should apply to Amarok flawlessly. A very important part of this project is testing the port and adapting the unit tests.


'''Knowledge Prerequisite:''' Knowledge of the Amarok code base (hence of Qt, C++). Basic knowledge of webservices.
'''Knowledge Prerequisite:''' good knowledge of C++/Qt, ideally being familiar with kf 5 and Plasma 5. The student should have some basic knowledge of the Amarok project and its functions as well as its architecture. All relevant information about Amarok, Qt5, kf5 and Plasma 5 can be found online, every suitable applicant should be able to find this documentation on their own.


'''Mentor:''' Mark Kretschmann
'''Mentor:''' To be determined.  All discussions about the project should be held on the mailinglist and/or on IRC


===digiKam===
===digiKam===
Line 73: Line 193:


* [http://www.digikam.org digiKam project web site]
* [http://www.digikam.org digiKam project web site]
* [http://www.exiv2.org Exiv2 project web site]
* [https://techbase.kde.org/Projects/Digikam/CodingSprint2014 digiKam port to KF5 status]
* [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist]
* [https://mail.kde.org/mailman/listinfo/digikam-devel Mailinglist]
* [https://plus.google.com/+digikam Google+ page]
* [https://plus.google.com/+digikam Google+ page]
* [http://webchat.freenode.net/?channels=digikam #digikam IRC channel on Freenode]
* [http://webchat.freenode.net/?channels=digikam #digikam IRC channel on Freenode]


==== Project: Integrate KIPI Export Plugins directly in the GUI of KIPI host applications ====
==== Project: Re-write database KIO-slaves as pure Qt5 using multithreading ====


'''Brief explanation:''' It would be nice to be able to encapsulate the Export/Import KIPI plugins directly in the GUI of the host application without opening a dedicated window. For the Export Plugins the place to load the plugins will be BQM and for the Import Plugins this can be in the digiKam import tool or in the main view. For this one must  factorize the export/import kipi plugin interface and to group the common calls into a virtual interface, to implement tree and list view for the plugins.
'''Brief explanation:''' Originally, KIO-Slaves have been implemented to run database queries in a separated process to prevent problem with SQlite. Since SQlite support re-entrancy and queries from separated threads, digiKam KIO-slaves used to process complex and long database queries can be re-written as core implementation using Qt thread API. This will improve digiKam availability in time when system is updated in low-level, and permit to adjust finely CPU cores assigned to database process.


'''Dependencies:''' : digiKam KIPI interface, libkipi, KIPI Plugins
'''Dependencies:''' : digiKam core from "framework" branch (KF5)


'''Bugzilla entries:''' [https://bugs.kde.org/show_bug.cgi?id=235572 235572], [https://bugs.kde.org/show_bug.cgi?id=221704 221704] ,[https://bugs.kde.org/show_bug.cgi?id=143978 143978]
'''Links:''' [https://www.sqlite.org/threadsafe.html Using Sqlite in multi-threaded application], [https://bugs.kde.org/show_bug.cgi?id=146557 Bug #146557]


'''Knowledge Prerequisite:''' C/C++, Qt/KDE, GUI
'''Knowledge Prerequisite:''' C/C++, Qt, database, multi-threading


'''Expected results:''' KIPI host apps that are compatible with the project will load KIPI Plugins in the BQM, the others will load the plugins as it's done right now without breaking any compatibility.
'''Expected results:''' Identify all parts of digiKam core which query database through KIO-slaves mechanism, factorize code in same interface and write a multi-threaded wrapper to run SQlite queries. Write test code to check quickly if database core implementation changes don't affect wrapper functionality. Note : digiKam use internally URL + XML formating to pass data to KIO-slaves and this not be changed.


'''Difficulty:''' high
'''Difficulty:''' high
Line 93: Line 215:
'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>
'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>


==== Project: Port Greystoration CImg interface to GMic ====
==== Project: Advanced Metadata HUB ====
 
'''Brief explanation:'''  digiKam has already some options to manage workflow between image metadata and database, through the setup/metadata configuration panel. The goal of this project is to write a more advance setup to control finely the most important metadata field in order to read from image and populate database and vis versa. The list of metadata to drive must be easily extensible and configurable. Also, the metadata workflow to synchronize image with database must be more flexible and must  provide a way to synchronize files at end of digiKam session and not only in real time (typical case : editing image tags to write in images). 


'''Brief explanation:''' digiKam include [https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/show/libs/3rdparty/cimg CImg library] to be able to use Greystoration algorithm which give nice fix to image based on Vortex theory, as [http://www.flickr.com/photos/digikam/8535414322/sizes/l/in/photostream/ Restoration tools]. Since CImg > 1.3.0, Greystoration algorithm have been moved in a new library named GMic with a completely different API. The goal of this project is to adapt digiKam Greystoration interface to GMic library.
'''Dependencies:''' : digiKam core and libkexiv2 from "framework" branch (KF5)


'''Dependencies:''' [https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/show/libs/dimg/filters/greycstoration digiKam core], [https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/changes/imageplugins/enhance/ Restauration and Inpaint editor tools], and [https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/show/utilities/queuemanager/basetools/enhance Restauration tool from Batch Queue Manager]
'''Links:''' [https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&component=Metadata&list_id=1205997&product=digikam&query_format=advanced&short_desc=HUB&short_desc_type=allwordssubstr Bugs list from bugzilla]


'''Knowledge Prerequisite:''' C/C++, math, Qt,  
'''Knowledge Prerequisite:''' C/C++, Qt, database, multi-threading


'''Expected results:''' port image restoration algorithm from [http://cimg.sourceforge.net/ CImg] to [http://gmic.sourceforge.net/ GMic] API
'''Expected results:''' Create metadata hub widget for settings panel, adjust current hub and image scanner implementations, add test code.


'''Difficulty:''' high
'''Difficulty:''' high
Line 107: Line 231:
'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>
'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>


==== Project: Add a quick access to Labels in dedicated tree-view ====
==== Project: Add WebP and WebM support  ====
 
'''Brief explanation:''' WebP/WebM is new wavelets based image/video format from Google, based on RIFF/MKV container. This format become more popular on the Web and both can be used through an open-source library. We need to support these formats as editable in digiKam (WebP) and manageable by database mechanism through metadata (WebP and WebM).
 
'''Dependencies:''' : digiKam core  and libkexiv2 from "framework" branch (KF5), Exiv2 library
 
'''Links:''' [http://en.wikipedia.org/wiki/WebM WebM format], [http://en.wikipedia.org/wiki/WebP WebP format]
 
'''Knowledge Prerequisite:''' C/C++, Qt, Metadata
 
'''Expected results:''' Patch Exiv2 library to support both formats in read/write meta-data mode and add optional WebP support in digiKam core to be able to edit images (read/write image contents in 16 bits color depth). Write test code to check new functionality in time.
 
'''Difficulty:''' high
 
'''Further Informations:''' [[GSoC/digikam/WebP_WebM_wazery_proposal]]


'''Brief explanation:''' It would be nice to be able show all items from collections in icon-view which has Rating, Pick Labels, and Color Labels attributed, as it's already do with Tags. The goal is to build a tree-view with all Labels available on digiKam and process database query to show items relevant. This view must include No rating, All Rating values, No Pick Label, All Pick Label values, No Color Label, all Color Labels, which must be selected individually or grouped. This Labels tree-view must be available in KIPI album selector widget, as it's done currently for Tags, to be able to export these virtual albums with kipi-plugins. Also, in this project a way to select No Tagged items must be add to current Tags tree-view, to be homogenous with new Labels tree-view feature.
'''Mentors:''' Gilles Caulier  <caulier dot gilles at gmail dot com> + Someone from Exiv2 team


'''Dependencies:''' : digiKam Database
==== Project: Factorize and port to KF5 all web service Import/Export KIPI tools ====


'''Bugzilla entries:''' [https://bugs.kde.org/show_bug.cgi?id=160363 160363],  
'''Brief explanation:''' All tools dedicated to import or export items from KIPI host applications to web services as Flickr, GDrive, Dropbox, Facebook, Picasa, etc... need to be factored and ported to KF5/Qt5. Factorization include to make common widgets (settings, GUI layout, rules, etc), and background processing to prevents duplicate code. Also, in order to reduce KIPI host application time loading, the number of tools must be limited. Tools must be grouped by categories, as Social Networks, Cloud Service, Photo Hosting, etc...


'''Knowledge Prerequisite:''' C/C++, Qt/KDE, GUI, Database
'''Dependencies:''' : digiKam KIPI interface, KIPI Plugins


'''Expected results:''' To have a quick acess tree-view in all relevant gui where Labels can be selected for photo workflow.
'''Bugzilla entries:''' [https://bugs.kde.org/show_bug.cgi?id=221704 221704]


'''Screenshots:''' [http://blogs.thesitedoctor.co.uk/tim/img/Windows-Photo-Gallery.JPG Microsoft Live Photo Rating tree-view], [http://images.apple.com/euro/aperture/features/images/video-audio-rating-20091020.jpg Apple Aperture Labels tree-view]
'''Knowledge Prerequisite:''' C/C++, Qt/KDE, GUI


'''Difficulty:''' medium
'''Expected results:''' KIPI web services tools ported to KF5 and running with digiKam 5.0.0.
 
'''Difficulty:''' high


'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>
'''Lead Mentor:''' Gilles Caulier  <caulier dot gilles at gmail dot com>
Line 130: Line 270:
* [http://marble.kde.org/ Marble project website]
* [http://marble.kde.org/ Marble project website]
* [https://mail.kde.org/mailman/listinfo/marble-devel Mailinglist]
* [https://mail.kde.org/mailman/listinfo/marble-devel Mailinglist]
* [Marble Google+ page]
* [http://webchat.freenode.net/?channels=marble #marble IRC channel on Freenode]
* [http://webchat.freenode.net/?channels=marble #marble IRC channel on Freenode]


==== Project: Interactive Tours ====
==== Project: Starting to edit OpenStreetMap Data ====


'''Brief explanation:''' A Tour is a set of related places along with supporting media (text, images, audio, video). Tours can be viewed (playback): The invididual places are visited in a defined timeline. They're useful for a wide range of tasks, like showing an interesting hike along with panorama pictures, highlighting places of interest for sightseeing or showing historic events and political changes happening over decades. The Marble library has been designed to support these use cases, but the user interface does not reveal all the features yet. This project is about changing that.
'''Brief explanation:''' During the last Google Summer of Code 2014 Cruceru Calin worked on an Edit mode for Marble. Right now it's possible to draw elementary shapes and features (Polygons/Polylines, Placemarks, GroundOverlays, etc.). These geometry primitives can be saved as KML files and there is some experimental OSM support already.
This project will be about extending the current Edit Maps mode. Focus will be especially towards enabling advanced editing that allows for more sophisticated drawing capabilities but also for tagging and other features that are required for OSM support. A special focus might also be on refactoring the existing code base where it's useful.


'''Expected results:'''  
* Extend the existing Tour widget for animated tour playback
'''Expected results:''' Reliable and useful means to create and edit OSM files using Marble.
* Improve the usability of the Tour widget
* Support interactive elements in tour playback
* Implement time support for tours for different time ranges (from eras to years to days to minutes to milliseconds)
* Add support for recording tours
* Enhance the screencast feature to generate videos from tours.
Optional:
* Extend Marble's owncloud synchronization feature for uploading tours to owncloud
* Add tour viewing support to the Marble owncloud app
* Implement tour viewing in the QML version of Marble
* Provide tours for existing map themes to highlight features of them


'''Knowledge Prerequisite:''' C++ and Qt. Would-be applicants are expected to work on junior jobs (possibly related to the project). Try to find your way into http://marble.kde.org/dashboard.php#contributors and solve as many tasks and bugfixes as possible.
'''Knowledge Prerequisite:''' C++, Qt,


'''Mentor:''' Dennis Nienhüser and other Marble developers.
'''Mentors:''' Torsten Rahn, Cruceru Calin, Dennis Nienhüser


==== Project: Marble Game ====
==== Project: Improve Printing Support and polish Marble rendering ====


'''Brief explanation:''' The latest introduction of a recent vector map inside Marble ("Natural Earth dataset") allows for interesting features: With recent and detailed political borders it's also possible to create a game based on Marble similar in spirit to KGeography. In terms of user-featureset the goal is to create an entertaining and educational game-application or game-plugin using Marble. Technically the goal is to extend Marble's framework to allow for this (there surely will be roadblocks).  
'''Brief explanation:''' Marble has good rendering and  basic printing of a screenshot already in place. However we'd like to see high resolution printing. This project should explore ways to improve printing support (e.g. by resizing the widget temporarily to a big geometry and printing the resized canvas). In order to adapt to the higher resolution the text size and the line widths need to adapt automatically to the increased resolution. As a result of this project Marble should feature largely improved printing of the current scenery (including the current map theme and projection) that is visible to the Marble user.
As a second part of this project regular Marble rendering should be improved. This would include:
* Improved rendering of Placemark Labels
* Improved rendering of Street labels (e.g. in OSM rendering)
* Improved OSM rendering
* Improved rendering of the OSM tiles to reduce bluriness during reprojection.
Depending on the skill-set of the student and depending on project progress code-refactoring of the Marble rendering in order to prepare for OpenGL support could be included with the project as well.
'''Expected results:''' Improved printing support with high resolution maps. Better rendering of Placemark/Street labels and better rendering of OSM textures.


'''Expected results:'''  
'''Knowledge Prerequisite:''' C++, Qt,
* An application that is based on the MarbleWidget which teaches Geography in a style similar to KGeography.
* OR/AND a plugin that extends Marble with a menu entry that invokes a Quiz-style educational game.
* Extend Marble's framework to allow for the features required
* Improve the Marble framework so that it provides a better experience for 3rd-party developers (by providing missing tutorials, documentation or even better APIs)


'''Knowledge Prerequisite:''' C++ and Qt. Would-be applicants are expected to work on junior jobs (possibly related to the project). Try to find your way into http://marble.kde.org/dashboard.php#contributors and solve as many tasks and bugfixes as possible.
'''Mentors:''' Torsten Rahn, Cruceru Calin, Dennis Nienhüser


'''Mentor:''' Torsten Rahn and other Marble developers.
==== Project: Turning Marble into a small GIS system  ====


==== Project: Marble Editing mode: Polygons ====
'''Brief explanation:''' During the last Google Summer of Code 2014 Cruceru Calin worked on an Edit mode ("Annotation Plugin") for Marble. Right now it's possible to draw elementary shapes and features (Polygons/Polylines, Placemarks, GroundOverlays, etc.). These geometry primitives can be saved as KML files.
During this project we'd like to extend the feature set towards classical requirements of a GIS system. Focus will be especially towards enabling advanced editing that allows for more sophisticated drawing capabilities but also for tagging and other features that are required for a GIS Editor. Depending on the experience of the student we might also focus on other topics like Data analysis or PostGIS support. 
'''Expected results:''' Adding capabilities to Marble that allow for using it for simple tasks that people would usually do using Quantum-GIS.


'''Brief explanation:''' During last GSoC a mode for editing ground overlays was added to the experimental editing Mode for Marble. During this GSoC the editing mode should be extended with polygon editing. The resulting editor should allow to create polygons and edit nodes of existing files in a way similar to inkscape. If there is enough time then the editing mode for Marble should be polished so that it can be included with the next release.
'''Knowledge Prerequisite:''' C++, Qt


'''Expected results:'''  
'''Mentors:''' Torsten Rahn, Cruceru Calin, Dennis Nienhüser
* An editing mode for polygons inside Marble.
* Adding, moving and removing nodes.
* Possibly merging nodes and other features that tools like inkscape provide for node interaction
* Assignment of lables, outline color and fill color.
* Possibly editing of "holes" inside the Polygon.


'''Knowledge Prerequisite:''' C++ and Qt. Would-be applicants are expected to work on junior jobs (possibly related to the project). Try to find your way into http://marble.kde.org/dashboard.php#contributors and solve as many tasks and bugfixes as possible.
==== Project: Statistical Data Visualization and Extending Marble Game  ====


'''Mentor:''' Torsten Rahn and other Marble developers.
'''Brief explanation:''' During the last Google Summer of Code 2014 Abhinav Gangwar created the "Marble Game".  
This project is about extending Marble's library in a way so that it's easy to display statistical data on maps in a color coded ("choropleth") way


http://www.coolgeography.co.uk/A-level/AQA/Year%2013/World%20Cities/Urbanisation/Urbanisation%20Map.png


=== KStars ===
The Marble application should include a default dataset that allows to display such maps for a set of important properties per country (e.g. life expectancy, literacy, etc.). A browser for statistical data should be added to Marble. The CIA Factbook data should be updated as well as the placemark data.
The Marble Game should be further improved and it should be possible to make use of the Statistics feature.


KStars is a very powerful tool for anyone interested in astronomy. It is part of the KDE Edu suite.
Possible additional tasks: Add streetview feature to Marble and the Marble Game.  


==== Project: Fix our deep-sky data handling ====
'''Expected results:''' Marble provides a tool that allows to visualize a ready-made dataset of statistical data in a color-coded choropleth way. The Marble Game should also be extended to make use of that feature.


'''Brief explanation:''' Currently, KStars handles data from deep-sky object catalogues in an SQLite database. While this is working well, there are some more features we would like to have, and some that should be implemented in order to sanitize the deep-sky data handling, such as automatic cross-referencing of deep-sky objects across catalogs, organizing deep-sky data better in the database etc using Hierarchical Triangular Mesh, etc.
'''Knowledge Prerequisite:''' C++, Qt


More details here: http://techbase.kde.org/Projects/Edu/KStars/Better_deep-sky_handling
'''Mentors:''' Torsten Rahn, Abhinav Gangwar, Dennis Nienhüser


'''Expected results:''' Some, or all of the improvements to deep-sky handling suggested above (or maybe even your own suggestions), implemented completely in solid, release-worthy code.
=== KStars ===


'''Knowledge Prerequisite:''' C++, Qt, understanding of astronomical catalogues, some experience with data structures.
KStars is a very powerful tool for anyone interested in astronomy. It is part of the KDE Edu suite.


'''Mentors:''' Rafal Kulaga (IRC: rkulaga)
==== Project: Ekos Scheduler ====


The student will need to:
'''Brief explanation:''' [http://www.indilib.org/about/ekos.html Ekos] is an advanced astrophotography tool for Linux. It utilizes [http://www.indilib.org INDI] for device control. With Ekos, the user can use the telescope, CCD, and other equipment to perform Astrophotography tasks. However, the user has to be present to configure the options and to command the actions to perform all the astrophotography related tasks, and hence a scheduler is required to automate observations to be constrained within certain limitations such as required minimum angular separation from the moon, whether conditions...etc. Furthermore, the observations should be triggered when certain conditions are met such as observation time, object's altitude...etc. The prospective student is expected to develop a ''Simple'' [http://indilib.org/forum/general/560-simple-ekos-schedular.html Ekos scheduler] to trigger observation runs when certain conditions are met and when the limitations are required.
'''Expected results:''' Simple scheduler to automate astrophotography runs based on some conditions and within user-configurable limitations.


* Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC timeframe.
'''Knowledge Prerequisite:''' C++, Qt, INDI
* Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2014.


PS: If all this looks daunting, that's because you have not (yet) talked to us. If you're really interested, get onto #kde-kstars and ping the mentors.
'''Mentors:''' Jasem Mutlaq (IRC: knro)


==== Project: Propose your own project ====
The student will need to:


'''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.
* Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC timeframe.
* Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2015.


'''Mentors:''' Rafal Kulaga (IRC: rkulaga)
==== Project: Constellation art ====


'''Brief explanation:''' KStars currently draws constellation lines, names, and boundaries, but constellation art is missing. The student is expected to study KStars API and develop a new SkyComponent to superimpose the constellation artwork unto the sky map while re-working other components in KStars to support this. The structure must support multiple sky cultures. The artwork itself must be available under a permissible license. New constellation artwork should be available for download using the KNewStuff framework. The user should be able to select the sky culture.


=== KDE Edu ===
'''Expected results:''' High quality artwork for Western constellations in addition to one non-western constellation artwork that can be switched on/off in the sky map.


==== Project:  Sound Visualization and Sound Effects in Artikulate ====
'''Knowledge Prerequisite:''' C++, Qt
'''Brief explanation:''' Artikulate is a language learning application that focus on improving a learner's pronunciation skills by repeating native speaker recordings, recording that try and comparing boths. By repeating these trials, a learner can continuously improve his/her language skills. There are areas for this project:
# native speaker recordings are recorded (either by GStreamer or QtMultimedia), converted to an OGG file and saved. What is missing is an application of noise cleanup filters, removing of no-sound intervals, and normalization (possibly combined with a very basic sound editor)
# when playing and comparing sounds, there is no visual feedback about how much the soundwaves differ: plotting the soundwaves in a reasonable format
'''Goals:''' The goal is to extend the sound processing in Artikulate to
# Implement simple sound filters for normalization, noise removal, removal of white noise and integrate sound postprocessing into the editor workflow
# Implement plotter for soundwaves and integrate this in the training mode
Yet for both it is important to research which libraries already exist and possibly could be reused. Also, research is needed about which techniques for comparing the soundwaves is appropriate. A proposal should already contain verbose information about these questions.


'''Knowledge Prerequisite:''' a must is knowledge of C++ and Qt, a plus is knowledge of sound processing libraries (e.g. GStreamer) or experience in sound processing
'''Mentors:''' Jasem Mutlaq (IRC: knro)


'''Mentor:''' Andreas Cord-Landwehr and/or other people from KDE Edu
The student will need to:


==== Project: Semi-Automatic Generation of Language Lessons for Parley ====
* Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC timeframe.
* Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2015.


'''Brief explanation:''' Parley is an advanced vocabulary trainer with features like 8 different learning modes, including flashcards, genders of nouns, conjugation of verbs and several more. A lesson for Parley is encoded in kvtml, KDE Vocabulary Training Markup Language which is an XML format for vocabulary lessons of many different types.
==== Project: Fix our deep-sky data handling ====


But it is a relatively demanding task to create good lessons for Parley. You need to manually edit a list of words in several different languages, add images and/or sound clips to them all, word class, pronounciation, etc.
'''Brief explanation:''' Currently, KStars handles data from deep-sky object catalogues in an SQLite database. While this is working well, there are some more features we would like to have, and some that should be implemented in order to sanitize the deep-sky data handling, such as automatic cross-referencing of deep-sky objects across catalogs, organizing deep-sky data better in the database etc using Hierarchical Triangular Mesh, etc.


We would like to create a semi-automatic generator for lessons using the Kexi database in the Calligra suite. The workflow will be something like this.
More details here: http://techbase.kde.org/Projects/Edu/KStars/Better_deep-sky_handling


# You use an import script to import a selected part of the word list in wiktionary.org, an online wiki dictionary, into Kexi. This will then form the basis for the work on the lessons.
'''Expected results:''' Some, or all of the improvements to deep-sky handling suggested above (or maybe even your own suggestions), implemented completely in solid, release-worthy code.
# You define a list of words in the so called primary language, which is the language that the lesson is supposed to teach. This list will be the words only and could be created either using the editor inside Parley or a standard text editor and then import it into Parley.
# You define which secondary languages you want in your lesson. These languages are the ones that the student is already familiar with. The training session will then consist of translations from one of the secondary languages (most often the native language of the student) and the primary language. At this point you also define which other parameters you want to include in the lesson, like image, sound clip, phonetic text, explanation, etc.
# You invoke the automatic lesson generator which will search for the words you have defined in the database, look up suitable translations and add the other fields that you asked for.
# If necessary, patch up the newly generated lesson with missing data that wasn't present in the database or add the information to the database and redo the generation.


'''Goals:''' The goal is to create software that supports the workflow above. It will at least comprise the following tasks:
'''Knowledge Prerequisite:''' C++, Qt, understanding of astronomical catalogues, some experience with data structures.
# Define an efficient database schema for the words and translations. Wiktionary.org has 3.6 million entries and even a subset of that can take significant amounts of storage.
# Implement a script that reads from wiktionary.org and enters the data into the Kexi database using the calligradb library. There is already a script for downloading and parsing the contents of Wiktionary at [1] but you will have to adapt it to Kexi.
# Implement the code that searches the database and populates the lesson with the data found.
# (If time permits) Implement a more advanced lesson editor than is currently present in Parley or a stand-alone editor.


'''Knowledge Prerequisite:''' Good knowledge of C++ and Qt, a plus is knowledge of of kvtml and the related C++ classes in the kde edu libraries. Also some knowledge of databases and database searches.
'''Mentors:''' Rafal Kulaga (IRC: rkulaga)


'''Mentor:''' Jaroslaw Staniek, the maintainer of Calligra Kexi, with help from Inge Wallin
The student will need to:


[1] http://en.wiktionary.org/wiki/Help:FAQ#Downloading_Wiktionary
* Look at the relevant code, and propose a tractable plan for implementing some of the improvements within the GSoC timeframe.
* Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2015.


==== Project: Kig - Geogebra Support ====
PS: If all this looks daunting, that's because you have not (yet) talked to us. If you're really interested, get onto #kde-kstars and ping the mentors.
[http://edu.kde.org/applications/mathematics/kig/ Kig] is an application for interactive geometry.


'''Goals:''' The overall goal is to support Geogebra files in KDE Edu. Because Geogebra is both a plotting tool and a tool for interactive geometry, the stated goal is very broad. For this particular project, we are interested in supporting interactive geometry in Kig. The current progress towards this goal is in the [https://projects.kde.org/projects/kde/kdeedu/kig/repository/show?rev=geogebra geogebra] branch of Kig's repository. Since there is some progress towards that goal, the particular goal of supporting these files in Kig may or may not be smaller than a GSoC project, in which case we can move forward to implement support for these files in the many plotting tools we have in KDE Edu.
==== Project: Propose your own project ====


'''Knowledge Prerequisite:''' By the start of GSoC you should
'''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.
# Be familiar with Kig as a user
# Be familiar with Geogebra as a user
# Be familiar with Git, you will have to work with branches
# Be able to build Kig
# Be familiar with Kig's filter code: Kig is a large code base, so you are not expected to know everything about it, but you should at least be familiar with how filters are created and be able to modify filters since this will be the part of the code that you will be working with.


'''Mentor:''' David Narvaez (IRC: dMaggot, please [[User:DMaggot/Mentoring|read this]] before applying)
'''Mentors:''' Rafal Kulaga (IRC: rkulaga)


==== Project: Kig - Analitza Integration (Experimental) ====
=== KDE Edu ===
[http://edu.kde.org/applications/mathematics/kig/ Kig] is an application for interactive geometry.
 
'''Goals:''' Kig's core is full of code to deal with finding solutions to linear or quadratic equations which are the bulk of interactive geometry. While this code works, in many cases it does so by approximations and it is, in general, very convoluted. The goal of this project is to implement all of this code in terms of a [https://en.wikipedia.org/wiki/Computer_algebra_system CAS] library to address both of the disadvantages mentioned before. Analitza is an "in-house" library that deals with mathematical expressions, and is thus a good candidate for a CAS provider in Kig. This project is experimental because:
# Implementing everything in terms of a CAS may or may not improve code quality in terms of readability. If it doesn't  (and we would only know this at the end of the project), the implementation of this project will not make it to the master branch.
# Analitza may or may not be up for all of the tasks we need to do in Kig, in which case improving Analitza is an option.
 
'''Knowledge Prerequisite:'''  By the start of GSoC you should
# Be familiar with Kig as a user
# Be familiar with Analitza as a consumer (it is a library, so you would not be a "user")
# Be able to build Kig
# Be able to build Analitza
# Be familiar with Kig
# Be familiar with Kig's object hierarchy and the mathematics behind that
 
'''Mentor:''' David Narvaez (IRC: dMaggot, please [[User:DMaggot/Mentoring|read this]] before applying)


==== Project: Integrate Cantor into LabPlot====
==== Project: Integrate Cantor into LabPlot====
Line 320: Line 424:


'''Application guide:'''
'''Application guide:'''
# Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphishm and the sounds are already available. You can count 1 week of development for a basic activity.
# Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphishm and the sounds are already available. You can count 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.
# 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 [http://gcompris.net/wiki/An_exercise_for_new_contributors instructions here] and provide your exercise as a pull request.
# You have to follow the [http://gcompris.net/wiki/An_exercise_for_new_contributors instructions here] and provide your exercise as a pull request.
Line 326: Line 430:
'''Mentor:''' Bruno Coudoin  (IRC: bdoin #gcompris on freenode)
'''Mentor:''' Bruno Coudoin  (IRC: bdoin #gcompris on freenode)


===Krita===
==== Project: Make an Editor Library/Plugin for KVTML Files ====
We welcome students who want to work on Krita for Google Summer of Code. If you want to work on Krita, keep in mind that we would like you to stay with the project, also outside Summer of Code. Summer of Code isn't just a summer job with some mentoring added -- it's a way of becoming part of the team.


If you haven't worked on Krita before, we want you to demonstrate your skill beforehand by fixing bugs or implementing some features. It's a good idea to start on that in January. Here is a list of pre-gsoc ideas:
[https://community.kde.org/KDEEdu/Language/Kvtml Kvtml] is a file format for vocabulary training that is used by all of the language applications in KDE Edu. The format is loaded into a KEduVocDocument class which is handled by a library with the same name. The format is reasonably rich with a tree structure for lessons and support for sound, images and any number of translations.


==== Project: Painting and Separation of 3D Textures====
To edit the KEduVocDocument many applications implement an editor. Some editors, like the one in Parley, are quite advanced with support for the whole format, as well as semi-automatic translations from websites like wiktionary.com and google search for images. Others are much simpler like the one in KWordQuiz, which is more or less only a simple table editor.


As one of it’s use cases, Krita’s vision statement includes painting textures for 3D. 3D textures are typically comprised of a number of separate black and white, RGB or RGBA images. Thus painting for textures typically requires painting on more than one single layer / channel at a time. For example painting a scratch into a metal surface may require painting black onto the bump channel, another colour on the diffuse channel, and another to the specularity channel (as well as possibly some others such as the displacement channel). All of these are affected simultaneously.


Currently Krita’s painting system is only able to paint onto single layers at a time and brushes have not been designed in such a way as to allow adjusting multiple channels simultaneously as would be needed. This topic would require looking at how Krita’s current painting system could be extended to paint the necessary adjustments to the channels used in 3D rendering, show the textures created in OpenGL and then export those channels for use in 3D applications.
'''Goals:'''


==== Project: 3D Material Image Maps====
The goal of the project is to separate the built-in editor in Parley into a library and/or plugin and make it available for other applications. This editor library should be made flexible and configurable so that applications with different needs could create an editor which supports the level of sophistication that suits that application best.


3D materials are made up of a bunch of images called image maps. If the user could associate layers as image maps in Krita, and paint on all of them at the same time, artists could paint whole 3D materials - something currently only available in high end 3d apps like zBrush (not even Photoshop / Corel Painter). The trick is that the position of what's painted needs to match on every map/layer, but the colours vary. For example, a scratch on a human characters skin would have a red colour map, a white (=raised) bump map, a light grey (=semi-shiny) specularity map etc, all in the exact same location on the each image map. Traditional methods of trying to create each image from scratch or by manipulating the colour map are very, very slow and painful. A simple version of this could be done as follows:
Summary of the goals:
# Separate the editor of Parley into a library. This library could either be placed into the current existing libkeduvocdocument repository or be placed into a library of its own.
# Remove all existing ties to other parts of Parley and generalize the settings to APIs.
# Make the editor more flexible and configurable so that the application can create its own level of sophistication of its editor. Note that this configurability is intended for the application programmer, not the end user of the application.
# Improve the documentation by providing a tutorial for the application programmer and also complete API documentation.
# Make Parley use this editor library instead of its current built-in one.


* Each layer has a toggle in the layers docker called "texture map" or similar. This is turned off by default. When active, the brush paints on *all* layers that currently have "texture map" active.
'''Knowledge Prerequisite:'''  By the start of GSoC you should
# be familiar with the kde edu language applications in general and Parley in particular
# be familiar with the kvtml format and the KEduVocDocument library.
# be familiar with C++ and Qt
# be familiar with building and running KDE applications


* When picking a colour, a dropdown lets the user pick "Default" or any active texture map layer. "Default" is just the current behaviour. If the user selects a layer in the dropdown, then the selected colour will be applied to that layer when painting on *any* layer.
'''Mentor:''' Inge wallin  (IRC: ingwa #kde-edu on freenode)
* In the file or layer menu is an option "Export texture maps" which saves each texture map layer as an image. The layer name and extension appended automatically to the file name. For example, on a file called character.kra, the layer titled "colour" would be saved as "character-colour.jpg" (or whatever format was selected).
   
For step 3, a simple, one click / shortcut, method is vital, as artists often have to check their material in their 3d app every few minutes, and wading through saving 10 layers individually, each with manual file naming and confirming file format settings each time is unacceptably slow. For any artist who requires this level of control, they can use Layers menu -> "Save Layer as Image" already in krita.


Allowing artists to paint a single material rather than creating multiple separate image maps by hand, would make Krita formidable for painting 3D textures, and the most advanced open source application for 3D texturing.
=== Keyboard Layouts ===


==== Project: Matte painting====
Keyboard layouts in KDE 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.


One of Krita's main use cases is as a professional tool for painting textures and mattes in digital film. Mattes are primarily made of sequences of images generated by a combination of two methods, first by animatable spline based shapes, which currently exists and is being developed in blender, and then after that, by hand painting frames for detailed areas and corrections. The trouble is that no currently maintained FOSS application currently tries to provide the ability to create hand painted mattes. This project is to extend Krita for this purpose. What's needed here is the following:
==== Project: Integrating Input Methods with keyboard layout configuration ====
* The ability for Krita to load manually selected sequences of color managed images as frames to be represented as a single layer in Krita. Optionally would be the ability to display playback at reduced resolutions to increase performance and to offset the time at which sequences were inserted.
* A “Timeline” docker which would display the current frame displayed, and allow clicking and dragging to different points in time, updating the image displayed in the canvas to match. Optional would be the ability to zoom and scroll the timeline, mark modified frames on the timeline, playback the image sequence, forwards and backwards as video (most likely only in the openGL mode of Krita or with an external tool like ffplay) and display times in a range of formate EG SMTP, PAL, NTSC, Secam etc.
* Updating the paint and transparency layer types, so that when Krita is using a frame sequence and one of these layer types is created, they also represent a series of frames rather than just a single image. This could possibly be a toggle switch on layers, much as visibility, alpha lock etc. are now.
* The ability to save layers that are displaying frame sequences out as frame sequences also, giving them user definable names (eg where to insert the frame number, how many digits to pad).
* Keyboard shortcuts to move forwards and backwards 1/10/100 frames, to jump to the start and end of the timeline and forward / backwards play if video playback is supported.


==== Project: Cartoon Text Balloon System====
'''Brief explanation:''' Input method and keyboard layout configuration are serving the same purpose - to allow users to type text in non-default language. Currently KDE has integrated system to configure keyboard layouts but IM need to be configured somewhere else. Also when IM is configured it takes over some functions of keyboard layout configuration. So it would be nice if we could have IM and keyboard layout configuration in one place.
It seems that IBus has already gained community acceptance so this will be the target for integration into KDE keyboard module.


Krita already has two text tools, but neither is suited for creating cartoon balloons. The system should allow the creation of vector-based balloons in different styles. The balloons can contain styled text. The text and balloons should be translatable and a system to select the current language should be created. It should be possible to save the balloon text to a separate file that can be used as input for translations. Finally, care must be taken to support right-left languages.
'''Expected results:''' Keyboard configuration module in System settings will include IM configuration and it will be integrated with existing keyboard layout options.


==== Project: Substrate simulation ====
'''Knowledge Prerequisite:''' good knowledge of C++, development experience with Qt and KDE, understanding of Input Methods (IBus)


'''Brief explanation''': Substrates for painting and drawing have a direct influence on the result of the art. The goal of this project is bringing this richness of these effects to Krita. There is an existing body of literature and academic projects on this topic, with Bill Baxter and Tom van Laerhoven being among the best known researchers. For the right effect, we need to take care of the 3d structure of the substrate, it’s effect on paint tools -- smoothness, absorbency and other parameters. An interesting option is to make it possible to apply different substrates to existing paintings.
=== KDevelop ===
Expected results: an optional substrate simulation that works with all current Krita tools


==== Project: Real Paint Emulation ====
==== Project: Clang Integration ====


We already did some research on the emulation of real-world paint and we do already have some essential pieces of it: Hairy Brush and Bumpmap filter. Now we need to bring this all together and allow a painter to use it easily, so that he could paint images like that: TODO. This project would involve creation of a special type of layer and a new colorspace, so the student should already be familiar with our layer stack and pigment code.
'''Brief explanation:''' Finish the kdev-clang plugin to make it a usable replacement for the existing C++ plugin.


==== Research Project: layer stack optimizations ====
'''Expected results:''' Find the still missing features from the KDevelop4's C++ support and port them over to kdev-clang, so it can become the mainstream C/C++ Solution


Right now when one layer got changed our merger should walk through all the layers of the current group and compose all of them into projection one by one. But this doesn't take into account that COMPOSITE_OVER (which is the most popular composition mode) has an associativity property, which means we can merge all the layers below and all the layers above dirty one into two groups, and calculate a group of any size with only two composition operations, which would give huge speed advantages.
'''Knowledge Prerequisite:''' C++, Qt. Knowledge about Clang is helpful


Unoptimized group:
'''Mentor:''' Kevin Funk


* layer 6
==== Project: Checker Framework ====
* layer 5
* layer 4
* layer 3 <-- active layer (becomes dirty quite often)
* layer 2
* layer 1


Optimized group:
'''Brief explanation:''' A generic framework should be created which provides the foundation for other plugins to report errors.


* <flattened 4-6>
'''Expected results:''' Right now we have the problems toolview but it is tightly coupled to the DUChain. This should be changed to use a separate item repository which stores the problems for a given path. The data stored would be: Path and range of where the issue is found, a short error message and optionally a long description. Furthermore, plugins might want to store additional info from which the problem could be fixed (compare to the 'add include path' or similar wizards we have already in the language framework).
* layer 3 <-- active layer (becomes dirty quite often)
* <flattened 1-2>


After this project is done, we can start implementing layer composition on the GPU using openGL.
This framework should then be used to integrate various tools.


==== Project: Improved Animation Brush System ====
First of all the existing language plugins should show the problems they find there.
This should result in animation brushes being more readily available and adjustable. The current way of doing this is not as userfriendly as it could be.
The existing playground plugins for krazy and cppcheck integration should reuse that framework
any other linters could be integrated, such as jslint, pylint, clang-check, etc. pp.
runtime checkers could be integrated, such as valgrind's memcheck, ptrcheck, helgrind, drd, ...


*Dedicated "Animation Brush GROUP"-> everything in group is a frame of the animation. (for use in current file,instead of in another instance of krita)
'''Knowledge Prerequisite:''' C++, Qt. Knowledge of debugging tools is helpful.
*Convert group to animation group ->Normal group becomes animation brush reference.
*Save as animation brush PRESET
*options to set animation brush continuity to custom, random, incremental, pressure,angular,loop...
*animation brush presets (in settings) need a timeslider to flip through the available frames


https://bugs.kde.org/show_bug.cgi?id=322159
'''Mentor:''' Milian Wolff


==== Project: seamless textures by using UV layout as self-wrapping paint mask====
==== Project: SVN Plugin Rewrite ====
This is a tool that should help in creating seamless (or as close as possible) textures for organic models. It will help in painting creases and other details across seams.
http://www.sintel.org/wp-content/uploads/2010/01/face_uv_export.png


*Convert intersections on uvlayout to seam transfer points.
'''Brief explanation:''' Rewrite the SVN plugin to use the C-API directly.
*use those points to transfer painted strokes to connected points on other side (set by user)
*create userfriendly way to add,manage those seam transfer points. (multiple should be active at once)


https://bugs.kde.org/show_bug.cgi?id=324072
'''Expected results:''' The existing SVN plugin uses an outdated kdevsvncpp checkout internally which causes troubles, warnings and licensing issues. Port the plugin to either the C-API of svn or alternatively try to reuse code from current kdevsvn. The result should be a tested, working plugin for SVN integration without licensing issues nor compile time warnings about usage of deprecated API.
 
'''Knowledge Prerequisite:''' C, C++, Qt, SVN


ALTERNATIVE
'''Mentor:''' Milian Wolff
*Similar to previous idea,but with movable curves/grid with adjustable seam transfer points in stead of converting a whole UV layout automaticly


https://bugs.kde.org/show_bug.cgi?id=321547
==== Project: LLDB Support ====


More ideas for projects can be found here:
'''Brief explanation:''' Write a new plugin to support LLDB on KDevelop
https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=Wishlist%20count&list_id=884686


=== Kexi ===
'''Expected results:''' 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.
Kexi is a visual database creator. It can be used for designing database applications, inserting and editing data, performing queries, and processing data.
 
'''Knowledge Prerequisite:''' C, C++, Qt, debugging intrinsic problems
 
'''Mentor:''' KDevelop team
 
=== KDE PIM ===
 
The KDE PIM community work on a set of libraries and applications for Personal Information Management, including email, calendaring, contacts, and feed aggregation.
 
==== Project: OpenHolidays ====


More info: [[Kexi|Developers' wiki]], [http://www.calligra.org/kexi web site for users], [https://mail.kde.org/mailman/listinfo/calligra-devel mailing list], IRC channel: #kexi and #calligra on Freenode.
'''Brief explanation:''' The KHolidays library provides KDE applications with information on public holidays around the world, however the file format is very hard to use and maintain and the library features are very limited and restricted to Qt users. The goal of the OpenHolidays project is to develop a new open standard and data repository that can be used by any project that needs the data. See http://community.kde.org/KDE_PIM/KHolidays for more details.


==== Project: Add support for importing tables from LibreOffice Base to Kexi ====
'''Expected results:''' Define the new JSON file format and port the existing data files to the new format.  Develop a shared Qt-only library to parse the holiday files and provide access to them with a iCal style event-based api.  Implement an Akonadi resource to access the data.  Extended goals: Develop a JavaScript library to use the files.  Develop a web site and web service at openholidays.org to provide online access to the data files.


Status: [[Kexi/Junior_Jobs/Add_support_for_importing_tables_from_LibreOffice_Base|assigned]].  
'''Knowledge Prerequisite:''' C++ and Qt for core goals, JavaScript and web services for extended goals.


'''Brief explanation:''' Add support for importing (Kexi calls it data/design migration) tables from LibreOffice (or OpenOffice) Base (ODB format) to Kexi. This task involves research on ODB format (it's relatively openly defined). Qt/C++ shall be used for the task together with Java engine (HSQLDB) and probably connected via JNI.  This could be introduction to later development of complete database import from ODB to a Kexi database.
'''Mentor:''' John Layt and other KDE PIM community members.


'''Expected results:''' In the GUI the feature shall be put in the same place as the import from MDB: External Data -> Import Tables -> Table Importing Wizard. Then user would see .odb support in the open file dialog, just like it has access to importing CSV or MDB.
==== Project: QtQuick ToDo API / Plasmoid====


'''Knowledge Prerequisite:''' C++, some Qt, some databases, some XML, software architecture
'''Brief explanation:''' KDE PIM wants to make it's data accessible for applications which use QML to declare their user interfaces, e.g. applications using QtQuick. For that they need data handling objects that are accessible through QML, e.g. item models that have a mapping of string based role names to enum value based roles in C++, etc.


'''Mentor:''' [[User:Jstaniek|Jarosław Staniek]] (Kexi maintainer)
'''Expected results:''' Define and implement a general QML API for accessing and creating Akonadis ToDo data. Write / Port a ToDo Plasmoid for Plasma Desktop  or Plasma Active to show off the new API. Bonus: Port Kontact Touch Task to the new API instead of,  or in addition to the Plasmoid.


'''First steps''':
'''Knowledge Prerequisite:''' C++, Qt, QtQuick
:*See [http://wiki.openoffice.org/wiki/FAQ_(Base)] for a start.
:*Sample .odb databases are available for [http://www.floppybunny.org/robin/web/virtualclassroom/chap8/libreoffice_base.html this] tutorial.
:*Studying kexi/migration/importtablewizard.cpp which is a GUI taking an instance of implementation of a migrate driver derived from KexiMigration::KexiMigrate (in your case - the ODB driver).  It's the m_migrateDriver attribute.
:*Implementing plugin (needed methods of the driver) in migration/odb/ by looking how it was performed for other cases, e.g. for mysql (see kexi/migration/mysql/ dir) or other cases such as pqxx, txt, xbase, sybase or mdb
:*In the actual C++ implementation, KoOdfReadStore class from calligra libs can be used to read contents of the .odb.


Other requirements in our way to success:
'''Possible Mentors:''' Kevin Krammer, and other KDE PIM community members
*commit changes to student's public branch at least once after each workday, not after a milestone
*developing wire-frames/prototypes of the software in advance, especially important since the solution is rather hybrid
*documenting them and developing/designing tests while the development progresses, not as the last step
*developing both C++/Qt side of the solution as well as the Java side in parallel to catch possible difficulties earlier
*putting the tasks in calendar (we may use e.g. a public Google calendar for that) so we can track the status


=== Calligra Plugins ===
=== Simon ===
Simon is a speech recognition suite.


Calligra is an office suite with lots of different applications with an user interface that is easy to use, highly customizable and extensible.
[http://simon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/kde-speech Mailing list] - IRC channel: #kde-speech on Freenode.


More info: [http://www.calligra.org web site for users], [https://mail.kde.org/mailman/listinfo/calligra-devel mailing list], IRC channel: #calligra on Freenode.
==== Project: Streamline handling of various resources ====


==== Project: Variable thickness lines ====
'''Brief explanation:''' Simon uses a multitude of different components: Scenarios, Base models, Shadow vocabulary, Language profiles, etc.


'''Brief explanation:''' One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.
While many of these components can be downloaded from within Simon, some can't and even for those that are better integrated, end-users still have to read additional documentation to know which components work together and which don't.
This proposal is to create a variable width path shape / tool, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.
As a plugin for the Calligra suite, this would clearly benefit apps as Karbon and also Krita.


'''Expected results:''' variable width path tool is able to change  the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup. The shape needs to be able to save and load in svg/odf.
The aim of this project is to bring the handling of these resources under a uniform and user-friendly interface.
Specifically, the interface should resolve conflicts automatically and deduce an optimal default setup by itself (e.g. based on the system language and installed programs).


'''Knowledge Prerequisite:''' C++, Qt, SVG?
'''Expected results:''' Much more user friendly setup.


'''Mentor:''' Thorsten Zachmann < zachmann @ kde dot org >
'''Knowledge Prerequisite:''' C++/Qt


=== Calligra Author ===
'''Mentor:''' Peter Grasch <peter {+at+} grasch.net>


==== Project: An Outliner for Calligra Author ====
'''Resources:''' Some work (mostly brainstorming and UI design) was already conducted during Season of KDE 2013. Please contact me for details. This does not mean that this project is already assigned!


'''Brief explanation:''' Calligra Author is a tool that will help writers create e-books. The two main target groups are novelists who write very long texts with complex and subtle relationships between different parts of the story and writers of e-textbooks that need features like multimedia and mathematical formulas.
=== Okular ===


The Calligra Author project has identified four main phases of the writing process, and we intend to support them all in various ways. They are:
Okular is a Document Viewer.  
* Concept and Planning
* Writing
* Review
* Publishing


Until now the new features have been mainly supporting the last 3: writing (distraction free writing mode, insertion of separators), review (notes/annotations) and publishing (support for book covers and export filters to epub and mobi formats). This project is about the first phase: concept and planning. What we want to do is an outliner, which is a well-known concept in other writer's tools. See [1] [2] [3] for all necessary details.
* [http://okular.kde.org Okular project web site]
* [https://mail.kde.org/mailman/listinfo/okular-devel Mailinglist]
* [http://webchat.freenode.net/?channels=okular #okular IRC channel on Freenode]


'''Goals:''' The goal is to create an outliner for Calligra Author. The following requirements will determine the project:
==== Project: Better Accessibility for Okular ====
* There should be user-definable categories in the database, but "Actors", "Items" and "Places" should be pre-defined by default.
'''Brief explanation:''' We should implement Qt accessibility APIs to make Okular usable by more users. This would allow blind people to read documents.
* The main object is the "scene" A scene is defined as a text snippet of any length with connections to the database so that objects, places and items that are used in the scene can be clearly marked as such. Note that this means both items that are actually present in the scene and those that are merely mentioned. Possible metadata for a scene includes a textual description, actors, items and places that appear and/or are mentioned or referred to.
* The users should have views that identify relationships between these categories, such as "this item is used in this scene by that actor in that place".
* There should be timing relationships between scenes so that mistakes can be avoided (like events that happen later are mentioned in a scene that happens earlier).
* The scenes should be groupable to any hierarchy forming chapters, subchapters, and even books. These groups will form an ordered tree.
* The final text will be created by an ordering of the scenes in the tree with suitable headers entered in between.
* File format for storing this is still an open question but using the Open Document Format is a big plus. An idea is to use so called ODF sections as the snippets because these are embeddable into each other and RDF triples for the metadata. The database format can also be RDF triples since this database will most likely not very big.


'''Knowledge Prerequisite:''' Good knowledge of C++ and Qt, a plus is knowledge of the open document format and the related C++ classes in the kde Calligra libraries.  
'''Expected results:''' You should be able to "read" Okular documents using Orca or other "screen reading" software. As long as the document exposes the contents in text form, we can let assistive technology pick it up and present it to the user in a different way (for example non-textual). An important goal is to transfer as much of the structure of the document as possible, so that ideally the sematics (this is a heading, here is normal text, page number) are preserved. Finding well working PDF solutions is still a challenge for blind people on any operating system. For now the focus will be on Orca since it's the best working screen reader on Linux used by most blind users.


'''Mentor:''' Inge Waliin, maintainer of Calligra Author
'''Knowledge Prerequisite:''' C++


[1] https://en.wikipedia.org/wiki/Outliner
'''Mentor:''' Albert, Frederik helping out with the accessibility parts
[2] http://en.wikipedia.org/wiki/Scrivener_%28software%29
[3] http://www.plume-creator.eu/site/index.php/en/


=== Calligra Sheets ===
==== Project: Implement PDF Poppler features ====
'''Brief explanation:''' Poppler has some support for features we don't support, implement them


Calligra Sheets is a spreadsheet application which is part of the Calligra Suite.
'''Expected results:''' Poppler has support for pdf layer views, tagged pdf support, linearized pdf support yet we in Okular don't offer that features to our users. The result from this project is having those exposed to the final users


==== Project: Improving Calligra Sheets ====
'''Knowledge Prerequisite:''' C++


'''Brief explanation:''' Calligra Sheets requires the 4 new features listed below:
'''Mentor:''' Albert


1) Split View: This feature would allow the user to split the view into 2 or 4 parts of the same sheet. The contents of the sheet do not change, just that the user can view and edit different parts of the sheets simultaneously.
==== Project: Implement SecurityHandler V6 in Poppler ====
'''Brief explanation:''' Poppler needs to support SecurityHandler V6 to be able to open some pdf files


2) Record Changes: This feature would allow the user to record the changes he/she is making while editing a sheet. This can be achieved by highlighting the content which is changed in the session or highlighting the cell itself.
'''Expected results:''' Poppler (and hence Okular) can open files with SecurityHandler V6 like the ones in https://bugs.freedesktop.org/show_bug.cgi?id=85368 and https://bugs.freedesktop.org/show_bug.cgi?id=88151


3) Auto-correct : This feature would allow the user to make less mistakes while working with a spreadsheet. It auto-corrects the contents of the cell while editing/writing into.
'''Knowledge Prerequisite:''' C++


4) Merge Documents: This feature would allow the user to merge different documents. For the first version, you can start by appending sheets from different documents into one. If a user has say, 4 different documents containing 1-2 sheets each and wants to merge them into one, he must be able to do it easily by just selecting "Merge Documents" option.
'''Mentor:''' Albert


'''Expected results:''' It is expected that by the end of summer of code, the above 4 features would be developed, integrated and ready for release or at least put up for review.
=== KDE Connect ===
==== Project: Improve KDE Connect encryption ====
'''Brief explanation:''' We want to implement a better encrypted protocol for KDE Connect, as discussed here: http://albertvaka.wordpress.com/2013/09/19/how-kde-connect-encryption-works/ I would like to see a solid and peer-reviewed design before accepting this project.


'''Knowledge Prerequisite:''' C++, Qt
'''Expected results:''' Have a secure encryption algorithm implemented in both KDE (C++/Qt) and Android (Java) clients.


'''Mentor:''' Jigar Raisinghani < jigarraisinghani@gmail.com >
'''Knowledge Prerequisite:''' Deep knowledge about encryption and security.


=== Keyboard Layouts ===
'''Mentor:''' Albert Vaca <albertvaka {+at+} gmail.com>


Keyboard layouts in KDE 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.
'''Resources:''' kdeconnect


==== Project: Integrating Input Methods with keyboard layout configuration ====
==== Project: Build a Qt-only multiplatform KDEConnect client ====
'''Brief explanation:''' We want to implement a cross platform client written in Qt that can run in virtually any platform supported by Qt (Windows Phone, Jolla, iOS, OSX, etc.) using the QPA (Qt Platform Abstraction) and QML. It will be challenging because Qt5 for phones is still quite new and implementing some features might not be possible yet, but it will be worth it to investigate what is possible and what not, and even contribute patches to Qt for some aspects. A lot of the core classes used in KDE Connect for Plasma could be reused and shared because they are mostly Qt (and would be part of the GSOC to make sure they end only using Qt, so we can get to re-use them). Not every feature is going to be available to every platform, and some plugins will be platform-specific, but as part of this GSOC project I would love to see it running as good as possible in one of the platforms already mentioned, and with basic functionallity in a couple more. (That is: center it around a platform and make it work well there, writting platform-specific plugins and code if needed, but making sure it still compiles and runs in other platforms).


'''Brief explanation:''' Input method and keyboard layout configuration are serving the same purpose - to allow users to type text in non-default language. Currently KDE has integrated system to configure keyboard layouts but IM need to be configured somewhere else. Also when IM is configured it takes over some functions of keyboard layout configuration. So it would be nice if we could have IM and keyboard layout configuration in one place.
'''Knowledge Prerequisite:''' Qt5 and building cross-platform code.
It seems that IBus has already gained community acceptance so this will be the target for integration into KDE keyboard module.


'''Expected results:''' Keyboard configuration module in System settings will include IM configuration and it will be integrated with existing keyboard layout options.
'''Mentor:''' Albert Vaca <albertvaka {+at+} gmail.com>


'''Knowledge Prerequisite:''' good knowledge of C++, development experience with Qt and KDE, understanding of Input Methods (IBus)
'''Resources:''' kdeconnect
=== Solid ===
==== Project: Improve sharing experience  ====
'''Brief explanation:''' Improve the content sharing experience in Plasma by extending and improving Samba share, implementing other ways of sharing and write new ways of discovering other people's shares.


=== KDevelop ===
'''Expected results:''' It should be possible to discover "shares" using dolphin (possibly via a new kioslave?) and it should be possible to share a folder between two Plasma computers really fast and easy (possibly implementing an http server plus discovery via avahi).


==== Project: Clang Integration ====
'''Knowledge Prerequisite:''' C++/Qt, extra points for KIO experience.


'''Brief explanation:''' Finish the kdev-clang plugin to make it a usable replacement for the existing C++ plugin.
'''Mentor:''' Àlex Fiestas <afiestas {+at+} kde.org>


'''Expected results:''' All advanced features of the KDevelop C++ are ported to the kdev-clang plugin. This includes code completion helpers, as well as basic refactoring and assistant integration.
'''Resources:''' avahi, http, kdenetwork-fileshare


'''Knowledge Prerequisite:''' C++, Qt. Knowledge about Clang is helpful
=== Muon ===
==== Project: Better support for your distribution  ====


'''Mentor:''' Milian Wolff
'''Brief explanation:''' Muon needs to be ensured to work perfectly on any distribution, this project should target one of the (major) distributions, enumerate the problems to solve and propose solutions.


==== Project: Checker Framework ====
'''Expected results:''' Muon users of your distribution will be happy ever-after.


'''Brief explanation:''' A generic framework should be created which provides the foundation for other plugins to report errors.
'''Knowledge Prerequisite:''' C++/Qt, the technology required for the platform


'''Expected results:''' Right now we have the problems toolview but it is tightly coupled to the DUChain. This should be changed to use a separate item repository which stores the problems for a given path. The data stored would be: Path and range of where the issue is found, a short error message and optionally a long description. Furthermore, plugins might want to store additional info from which the problem could be fixed (compare to the 'add include path' or similar wizards we have already in the language framework).
'''Mentor:''' Aleix Pol


This framework should then be used to integrate various tools.


First of all the existing language plugins should show the problems they find there.
=== KWin ===
The existing playground plugins for krazy and cppcheck integration should reuse that framework
==== Project: DRM/KMS backend for kwin_wayland ====
any other linters could be integrated, such as jslint, pylint etc. pp.
runtime checkers could be integrated, such as valgrind's memcheck, ptrcheck, helgrind, drd, ...


'''Knowledge Prerequisite:''' C++, Qt. Knowledge of linters such as Valgrind etc. is helpful.
'''Brief explanation:'''
KWin_wayland currently only supports rendering to another Wayland server. In future it should be possible to go down to the hardware directly. For this a DRM/KMS rendering backend is required. This requires that a new backend is implemented for the OpenGL compositor and maybe the QPainter compositor. As KWin needs to handle kernel mode settings in this mode the output information need to be queried from the hardware and an implementation for KWin::Screens needs to be provided and from there propagated to the Wayland clients. In addition if the time of the project permits it an interface should be exposed for KScreen to configure the outputs.


'''Mentor:''' Milian Wolff
'''Expected results:''' KWin_wayland can render to DRM/KMS and fetches output information from the hardware


==== Project: SVN Plugin Rewrite ====
'''Knowledge Prerequisite:''' C++/Qt, Wayland, KMS and C knowlege are from advantage


'''Brief explanation:''' Rewrite the SVN plugin to use the C-API directly.
'''Mentor:''' Martin Gräßlin <mgraesslin@kde.org>


'''Expected results:''' The existing SVN plugin uses an outdated kdevsvncpp checkout internally which causes troubles, warnings and licensing issues. Port the plugin to either the C-API of svn or alternatively try to reuse code from current kdevsvn. The result should be a tested, working plugin for SVN integration without licensing issues nor compile time warnings about usage of deprecated API.
===Trojitá===


'''Knowledge Prerequisite:''' C, C++, Qt, SVN
[http://trojita.flaska.net/ Trojitá] is a fast IMAP e-mail client. Since late 2012, it is a part of KDE's extragear. The project focuses on delivering a usable, fast, standards-compliant, cross-platform and reliable e-mail client which can scale from cell phones to huge e-mail archives without annoying slowdowns.


'''Mentor:''' Milian Wolff
==== Project: Port to BlackBerry OS 10 ====


=== KDE PIM ===
'''Brief explanation:'''
This work involves improving the separation of business logic from the UI concerns, an effort started and well-underway due to the Ubuntu Touch project, and adding a new GUI wirrten in QML for BlackBerry OS 10.


The KDE PIM community work on a set of libraries and applications for Personal Information Management, including email, calendaring, contacts, and feed aggregation.
'''Expected results:''' Trojitá running on BlackBerry Z10 with basic features, including reading and writing e-mails


==== Project: OpenHolidays ====
'''Knowledge Prerequisite:''' C++/Qt, QML


'''Brief explanation:''' The KHolidays library provides KDE applications with information on public holidays around the world, however the file format is very hard to use and maintain and the library features are very limited and restricted to Qt users.  The goal of the OpenHolidays project is to develop a new open standard and data repository that can be used by any project that needs the data.  See http://community.kde.org/KDE_PIM/KHolidays for more details.
'''Mentor:''' Jan Kundrát <jkt@kde.org>


'''Expected results:''' Define the new JSON file format and port the existing data files to the new format.  Develop a shared Qt-only library to parse the holiday files and provide access to them with a iCal style event-based api.  Implement an Akonadi resource to access the data.  Extended goals: Develop a JavaScript library to use the files.  Develop a web site and web service at openholidays.org to provide online access to the data files.
==== Project: Multiaccount support ====


'''Knowledge Prerequisite:''' C++ and Qt for core goals, JavaScript and web services for extended goals.
'''Brief explanation:'''
Trojitá's GUI only shows one IMAP account at once. The scope of this task is to analyze what needs to be done, and implement the required changes for making it possible to show multiple IMAP accounts. General bugfixes are expected in the rest of the time.


'''Mentor:''' John Layt and other KDE PIM community members.
'''Expected results:''' Full support for multiple IMAP accounts, including unit test coverage


==== Project: Enhanced Searching in KMail ====
'''Knowledge Prerequisite:''' C++, Qt


'''Brief explanation:''' KMail is the defacto email client in KDE. It currently has a complex search dialog which allows the users to configure many different parts of the search. While it is very powerful, it is not very usable. A better search dialog is required which allows the user to modify the initial search and filter the data appropriately. A good example of this would be the Thunderbird search dialog - https://support.mozillamessaging.com/media/uploads/gallery/images/2011-03-14-10-05-42-56151b.jpg
'''Mentor:''' Jan Kundrát <jkt@kde.org>


'''Expected results:''' Implementing the new search dialog and updating the backend search code to include whatever new features are required. Implementing this search dialog will require messing around with Akonadi, Baloo and KPeople.
=== Gluon ===
[http://gamingfreedom.org Gluon] is a project to build a Qt and KDE based game engine and game development tool. The engine is designed to support both mobile and desktop game development. We have ported the engine to Qt5 last year and are currently working on releasing a first Qt5 based version.


'''Knowledge Prerequisite:''' C++ and Qt. A basic understanding of Information Retrieval would be nice.
==== Project: Build a QtQml based script system ====
'''Brief explanation:''' In Qt4 QtScript was the solution to scripting support for applications. With the port to Qt5 the new QtQml module was introduced, including a new scripting system, but QtScript was still available. With Qt5.5 QtScript is planned to be deprecated and completely removed in Qt5.6. This means that our scripting system, which is currently built on QtScript, needs to be ported to QtQml.


'''Mentor:''' Vishesh Handa and other KDE PIM community members.
'''Expected results:''' A scripting system that can be used to write scripts for games.


==== Project: Active Mail ====
'''Knowledge Prerequisite:''' C++/Qt at least. Experience with QtQuick/QML is a strong advantage.
'''Brief explanation:''' Active Mail is a QtQuick based mail application, a touch input friendly version of KMail so to speak. Currently it still depends on QtWidget based user interfaces for certain tasks which will have to be replaced before Active Mail can live up to its promise. Such missing pieces are the email composer and the email viewer.  


'''Expected results:''' Define and implement a general QtQuick API for composing emails. Rework the Active Mail composer UI/UX with the help of our usability expert and make it shine.
'''Mentor:''' Arjen Hiemstra


'''Knowledge Prerequisite:''' C++, Qt, QtQuick
==== Project: Expand Gluon Input ====
'''Brief explanation:''' During the port to Qt5 we also overhauled the input system in Gluon to be more capable. However, we kept the implementation rather limited since we also had other elements to work on. This project would expand GluonInput with support for additional devices and platforms.


'''Possible Mentors:''' Thomas Pfeiffer, Michael Bohlender, Kevin Krammer
'''Expected results:''' Additional platform and device plugins for GluonInput.


==== Project: QtQuick ToDo API / Plasmoid====
'''Knowledge Prerequisite:''' C++/Qt at least. Experience with platform-specific input libraries like XInput2 for Xorg is an advantage.


'''Brief explanation:''' KDE PIM wants to make it's data accessible for applications which use QML to declare their user interfaces, e.g. applications using QtQuick. For that they need data handling objects that are accessible through QML, e.g. item models that have a mapping of string based role names to enum value based roles in C++, etc.
'''Mentor:''' Arjen Hiemstra


'''Expected results:''' Define and implement a general QML API for accessing and creating Akonadis ToDo data. Write / Port a ToDo Plasmoid for Plasma Desktop  or Plasma Active to show off the new API. Bonus: Port Kontact Touch Task to the new API instead of,  or in addition to the Plasmoid.
[[Category:Mentoring]]


'''Knowledge Prerequisite:''' C++, Qt, QtQuick
=== Krita ===
[http://www.krita.org Krita] is an advanced 2D painting application. 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.


'''Possible Mentors:''' Kevin Krammer, Michael Bohlender and other KDE PIM community members
==== Project: Integrate Animation in Krita's core ====
'''Brief explanation:''' We have gone through three iterations of animation support code in Krita. With this experience, it's become clear that we need to work the support for animatins right into Krita's core engine. This project comprises partly that, and partly updating the existing animation gui that was created in 2014.


====Project: KPeople / Kontact Touch People====
'''Expected results:''' by the end of the summer, the animation support in Krita should be ready for end-users to create 2D animations with, whether for game sprites or short cartoons.


'''Brief explanation:''' KPeople is a KDE framework for aggregating contact information of people from various data sources, e.g. the user's addressbook and instant messaging programs. For the future KDE would like this to be the main source of data for its address book application.
'''Knowledge Prerequisite:''' C++/Qt at least.


'''Expected results:''' Define and implement a QML API for accessing kPeoples features. Create a pretty QtQuick  example App/Plasmoid to show off and prove the API. Bonus:  Bonus: Port Kontact Touch Addressbook to the new API instead of, or in addition to the Example.
'''Mentor:''' Boudewijn Rempt


'''Knowledge Prerequisite:''' C++, Qt, QtQuick
==== 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.


'''Possible Mentors:''' Martin Klapetek, Thomas Pfeiffer and other KDE PIM community members
'''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.


==== Project: Akonadi Commandline/Shellscripting Interface ====
'''Knowledge Prerequisite:''' Deep knowledge of Python, SIP, C++ and Qt.


'''Brief explanation:''' Akonadi is a system that enables uniform access to various data formats across a wide range of data sources. Its main clients are graphics end user applications such as KMail. However, in some cases it is advantageous if data manipulation can be automated.
'''Mentor:''' Boudewijn Rempt
Power users or system administrators often employ the multitudes of Unix/Linux commandline tools to achieve such automation tasks. The idea is to provide a tool or set of tools that allow Akonadi operations to be used in such scripts.


'''Expected results:''' A non-GUI program able to perform useful tasks on Akonadi provided data, like creating folders, adding/deleting/copying/moving data such as contacts or emails, etc.
==== Project: Improve Normal Mapping Workflow ====
'''Brief explanation:''' Normal maps are textures that describe surface detail on a 3d model by describing how much each pixel deviates from the surface the texture is put on.  A normal map gives the ability to tell the renderer there's a different normal per texel(texture pixel), this way, you can describe subtle differences in surface without requiring the polygons for it. It does so by describing the normal angle to the surface by using the R, G and B channels. Now, normal maps, due to them being quite mathematical, are usually baked. But these bakes are not always perfect. furthermore, there's a lot of interest into handpainting textures, amongst which normal maps.


'''Knowledge Prerequisite:''' C++, Shell scripting
'''Expected results:''' by the end of the summer, a new brush engine, which takes the tilt-direction and has that control the redness and greenness. And then takes the tilt-elevation, and has that control the blueness.


'''Mentor:''' Jonathan Marten, Kevin Krammer and other KDE PIM community members
'''Knowledge Prerequisite:''' knowledge of C++, Qt. and mathematics


'''Resources:''' An early prototype can be found here https://projects.kde.org/projects/playground/pim/akonadiclient and there are two, non-Akonadi, clients which are part of KDE PIM: kabcclient (contacts), konsolecalendar (calendar)
'''Mentor:''' Boudewijn Rempt
Contact the kde-pim mailinglist for discussions: https://mail.kde.org/mailman/listinfo/kde-pim


===Calligra===
==== Project: Variable thickness lines ====


=== Simon ===
'''Brief explanation:''' One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width.
Simon is a speech recognition suite.
This proposal is to create a variable width path shape / tool, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node.
As a plugin for the Calligra suite, this would clearly benefit apps as Karbon and also Krita.


[http://simon.kde.org Website] - [https://mail.kde.org/mailman/listinfo/kde-speech Mailing list] - IRC channel: #kde-speech on Freenode.
'''Expected results:''' variable width path tool is able to change  the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup. The shape needs to be able to save and load in svg/odf.


==== Project: Streamline handling of various resources ====
'''Knowledge Prerequisite:''' C++, Qt, SVG


'''Brief explanation:''' Simon uses a multitude of different components: Scenarios, Base models, Shadow vocabulary, Language profiles, etc.
'''Mentor:''' Thorsten Zachmann < zachmann @ kde dot org >


While many of these components can be downloaded from within Simon, some can't and even for those that are better integrated, end-users still have to read additional documentation to know which components work together and which don't.
=== KIOSK ===
==== Project: KIOSK Tool ====


The aim of this project is to bring the handling of these resources under a uniform and user-friendly interface.
'''Brief explanation:''' Back in KDE 3 there was a tool to help administrators to configure the KDE Kiosk framework. The idea of this project is to start working on a new tool. The new application should be developed in close collaboration with the Visual Design Group to get a useful application for the targeted audience.
Specifically, the interface should resolve conflicts automatically and deduce an optimal default setup by itself (e.g. based on the system language and installed programs).


'''Expected results:''' Much more user friendly setup.
'''Expected results:''' a functional prototype for a new Kiosk tool with a working backend to configure and restrict actions and configuration options.


'''Knowledge Prerequisite:''' C++/Qt
'''Knowledge Prerequisite:''' C++/Qt


'''Mentor:''' Peter Grasch <peter {+at+} grasch.net>
'''Mentor:''' Martin Gräßlin <[email protected]>
 
=== Kubuntu ===
==== Project: Port Ubiquity to Qt 5 ====
 
'''Brief explanation:''' Ubiquity is the installer for Kubuntu. It should be ported to Qt 5. It is written in Python and can be fiddly to test because much of the development needs to be done on a live system.  Once the Qt 5 port is complete there are numerous other bugs that can be fixed.  Drop into #kubuntu-devel to say hi.  Code is in launchpad.net/ubiquity. Contact: [https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel Kubuntu-devel list].
 
'''Expected results:''' Ubiquity bug free and running with Qt 5
 
'''Knowledge Prerequisite:''' Python, PyQt
 
'''Mentor:''' Jonathan Riddell
 
=== Calamares ===
 
[http://calamares.io/about/ Calamares] is a distribution-independent installer framework ([https://github.com/calamares/calamares/ 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 [http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/ 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.
 
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.
 
'''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.


'''Resources:''' Some work (mostly brainstorming and UI design) was already conducted during Season of KDE 2013. Please contact me for details. This does not mean that this project is already assigned!
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.


=== KDE Telepathy===
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.


==== Project: Conference Video Call Support ====
Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.


'''Brief explanation:''' Our current IM client can handle a 1-1 video call reasonably well. It currently does not
'''Expected results:''' Equivalence between the Python, Ruby and C++ job module interfaces.
support conference calls (>2 people). Our backend Telepathy should support this, but we do not make use of it in our client. This project will involve
* some UI design
* some low level GStreamer work
* fixing parts of the Telepathy stack.


Current code is inside the repository ktp-call-ui.
'''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.


'''Expected results:'''
'''Mentor:''' Teo Mrnjavac <teo@kde.org>, teo- on Freenode; Rohan Garg <[email protected]>, shadeslayer on Freenode
Working multi conference video calls.


'''Knowledge Prerequisite:'''
==== Project: Python interface refactor + Python testing mechanism ====
* C++, Qt
* Ideally; QML, GStreamer and Telepathy


'''Mentor:''' David Edmundson and Diane Trout
'''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.


==== Project: Telegram Network Support ====
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.


'''Brief explanation:''' Telegram is an upcoming network that aims to replace WhatsApp. Unlike whatsapp it has an open protocol (https://telegram.org/) and is gaining popularity.
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 [http://calamares.io/ci/ Jenkins continuous integration system].


We want support in our IM client. This should be done by creating a connection manager using TelepathyQt service bindings.  
Once both subtasks are complete there are various related tasks to be done. Drop into #calamares to say hi and discuss your proposal.


When this is complete, not only will we get Telegram support, but due to the distributed nature of Telepathy it will also work for Jolla, Ubuntu Phone and Empathy.
'''Expected results:''' Equivalence between the Python and C++ job module interfaces, and a comprehensive testing mechanism for Python job modules.


'''Expected results:'''
'''Knowledge Prerequisite:''' At least some C++ and Python experience is required; experience with CMake, Boost.Python and software testing is a plus.
Working single and group chats using KDE Telepathy over the Telegram network


'''Knowledge Prerequisite:'''
'''Mentor:''' Teo Mrnjavac <[email protected]>, teo- on Freenode
C++, Qt, Reading Protocol Documentation


'''Mentor:''' David Edmundson
==== Project: Debian installer support ====


=== Solid ===
'''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.
==== Project: iOS Integration ====
'''Brief explanation:''' Integrate the iOS platform with the Plasma desktop using libraries like libimobiledevice and kdeconnect.


'''Expected results:''' Have an iOS application that is able to talk to KDE Connect and desktop integration using libimobiledevices.
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.


'''Knowledge Prerequisite:''' C++/Qt, Objective C
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.


'''Mentor:''' Àlex Fiestas <afiestas {+at+} kde.org>
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.


'''Resources:''' libimobiledevice, kdeconnect, plasma
'''Expected results:''' Calamares should be able to install a Debian based system using debian-installer as backend.


==== Project: Improve KDE Connect encryption ====
'''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.
'''Brief explanation:''' We want to implement better encryption algorithms in KDE Connect, as discussed here: http://albertvaka.wordpress.com/2013/09/19/how-kde-connect-encryption-works/


'''Expected results:''' Have a secure encryption algorithm implemented in both KDE (C++/Qt) and Android (Java) clients.
'''Mentors:''' Rohan Garg <rohan@kde.org>, shadeslayer on Freenode; Teo Mrnjavac <[email protected]>, teo- on Freenode


'''Knowledge Prerequisite:''' Deep knowledge about encryption and security.
==== Project: The Ultimate Calamares user experience ====


'''Mentor:''' Albert Vaca <albertvaka {+at+} gmail.com>
'''Brief explanation:''' Design and development of Calamares started in June 2014, with deliverables as early as Fall 2014, so some hard choices had to be made in order to ship quickly. While Calamares doesn't look intensely unpleasant when compared to some other system installers, it is not a triumph of user experience design either.


'''Resources:''' kdeconnect
The KDE Visual Design Group has already produced [https://community.kde.org/KDE_Visual_Design_Group/Calamares_Design_Project a design for Calamares] in agreement with the Calamares team. It is now time to implement this design.


==== Project: Make Libbluedevil Async ====
The student should propose a detailed action plan, with the ultimate deliverable being a complete visual overhaul of Calamares, including libcalamaresui and essential view modules. Intermediate deliverables must be listed in the proposal, with as much granularity as possible. The implementation should not deviate from the KDE VDG's design unless otherwise discussed, and during the coding season the student is expected to closely cooperate with both the Calamares team and the KDE VDG.
'''Brief explanation:''' Extend libbluedevil to have an asynchronous api, and port bluedevil to it.


'''Expected results:''' libbluedevil should have an asynchronous api, and bluedevil should be ported to them.
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:''' basic Qt and DBus
'''Attention''': This is a '''very challenging''' task, somewhat more demanding than the other ones we offer, and suitable for more experienced students. First time students are encouraged to consider our Python, Ruby or Debian tasks too. Exceptionally for this project we are requiring a '''qualification task''' to be completed by the prospective student. This qualification task should be delivered as a patch against master and sent to the mentor (Teo Mrnjavac <[email protected]>) ''before'' submitting a proposal for this project idea through the Google Summer of Code web application. Applicants that have not submitted a qualification task for this project will not be considered. The qualification task is defined as follows: '''implement the KDE VDG's design for the Users page (the Calamares module "users")'''. The webcam picture feature does not have to be implemented, but the avatar chooser is required. See [https://dl.dropboxusercontent.com/u/6631774/CalaUsersPageDesign.png this mockup].


'''Mentor:''' Àlex Fiestas <afiestas {+at+} kde.org>
'''Expected results:''' Calamares should look and feel as designed by the KDE Visual Design Group.


'''Resources:''' libbluedevil, bluedevil, afiestas
'''Knowledge Prerequisite:''' The student should have experience with Qt and C++; QML experience is a big plus.


==== Project: Improve sharing experience  ====
'''Mentors:''' Teo Mrnjavac <[email protected]>, teo- on Freenode
'''Brief explanation:''' Improve the content sharing experience in Plasma by extending and improving Samba share, implementing other ways of sharing and write new ways of discovering other people's shares.


'''Expected results:''' It should be possible to discover "shares" using dolphin (possibly via a new kioslave?) and it should be possible to share a folder between two Plasma computers really fast and easy (possibly implementing an http server plus discovery via avahi).
=== Kopete ===


'''Knowledge Prerequisite:''' C++/Qt, extra points for KIO experience.
[https://kopete.kde.org 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.


'''Mentor:''' Àlex Fiestas <afiestas {+at+} kde.org>
==== Project: Better history plugin ====


'''Resources:''' avahi, http, kdenetwork-fileshare
'''Brief explanation:''' History plugin is responsible for archiving chat history and also searching for old chat messages in archive. Currently Kopete has two history plugins: one which stores data to XML files and another one which stores data to SQLite database. Both plugins have some diffetent limitations like slow speed, bad search support, bad support for HTML messages, bad support for multiuser chat... This project aims to fix existing history plugin(s) or designing & implementing new one.


=== Plasma Media Center ===
'''Expected results:''' Working fast chat history plugin with support for handling HTML messages, multichat messages, ability to search for messages in history, import/export feature (importing from services like googletalk/facebook can be great too), ...
KDE's Plasma Media Center (PMC) is aimed towards a unified media experience on PCs, Tablets, Netbooks, TVs and any other device that is capable of running KDE software. PMC can be used to view images, play music or watch videos. Media files can be on the local filesystem or accessed with KDE’s Desktop Search.


===== Mentors =====
'''Knowledge Prerequisite:''' C++/Qt, XML or SQLite (or any other data storage usefull for chat messages)
Unless explicitly noted, one of the follwing will mentor for the selected proposals-
* Shantanu Tushar
* Sinny Kumari
Please use plasma-devel AT kde.org to discuss your ideas and proposals.


==== Project: Integrate with Simon ====
'''Mentor:''' Pali Rohár <[email protected]>, Pali on #kopete


'''Brief explanation:''' Simon is an open source speech recognition program that can replace your mouse and keyboard. The system is designed to be as flexible as possible and will work with any language or dialect. This project aims at integrating it with Plasma Media Center to control it.
'''Co-Mentor:''' Kaushik Saurabh <roideuniverse@gmail.com>, roide on #kopete


'''Expected results:''' Using Simon, the user should at least be able to use voice to -
'''Mailing list:''' [email protected] (archive at: [http://lists.kde.org/?l=kopete-devel&r=1&w=2 lists.kde.org])
* Control playback of media (images, music, videos)
* Navigate in the media browser (next page, previous page, "goto the 3rd item")
* Home Screen navigation
* Ability to switch to the player, image viewer, or playlist
* Play a media file in the browser (or the playlist, when its shown) using its name


'''Knowledge Prerequisite:''' Basic C++, Qt and QML
==== Project: Jabber message archive ====


'''Co-Mentor:''' Peter Grasch <peter {+at+} grasch.net>
'''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:


==== Project: Integrate with Plasma Next ====
XEP-0136: Message Archiving


'''Brief explanation:''' Plasma Next is the refreshed Plasma workspace written using the new KF5, Qt5 and QtQuick2 frameworks. Plasma Next is able to switch to different modes/formfactors on-the-fly (such as desktop, netbook, tablet). We want to be able to make Plasma Next able to switch into a media center mode.
XEP-0313: Message Archive Management


'''Expected results:''' After the project is complete, the Plasma Next shell should be able to switch to a Media Center mode and offer every feature that the standalone Plasma Media Center application provides. Examples are ability to browse media, playback, playlists etc.
'''Expected results:''' Working support for XEP-0136 or XEP-0313


'''Knowledge Prerequisite:''' Qt, QML is required. Understanding of Plasma Next is a huge plus
'''Knowledge Prerequisite:''' C++/Qt, Jabber protocol


'''Resources:''' Some info about Plasma Next
'''Mentor:''' Pali Rohár <pali.rohar@gmail.com>, Pali on #kopete
* http://vizzzion.org/blog/2014/01/plasma-new-beginning/
* http://vizzzion.org/blog/2014/02/next-means-focus-on-the-core/
* http://vizzzion.org/blog/2013/11/responsible-evolution/


==== Project: DVB Support for TV ====
'''Mailing list:''' [email protected] (archive at: [http://lists.kde.org/?l=kopete-devel&r=1&w=2 lists.kde.org])


'''Brief explanation:''' https://en.wikipedia.org/wiki/Kaffeine is a KDE media player which supports playing TV using DVB. Our users have ben requesting for this support in PMC as well so that it becomes possible to watch TV as well.
==== Project: PGP plugin ====


'''Expected results:''' Once the project is completed, Plasma Media Center should be able to play streams from a TV card with DVB support. There should be feature parity with Kaffeine.
'''Brief explanation:''' Kopete has plugin which can sign or encrypt outgoing messages using GPG. It can also verify signature and decrypt incoming messages. This plugin is old, uses private kdepim library and needs fixing. It is hard to compile and use it. For this project I would except fixing this plugin to work again or writing new PGP plugin from scratch.


'''Knowledge Prerequisite:''' Basic C++, Qt and QML. Access to DVB hardware and signal availability in student's region is mandatory for testing https://en.wikipedia.org/wiki/Digital_Video_Broadcasting
'''Expected results:''' Working support for PGP in Kopete


'''Mentor:''' Mentor wanted with DVB knowledge for the DVB bits.
'''Knowledge Prerequisite:''' C++/Qt, GPG


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


==== Project: KDE Reports ====
'''Mailing list:''' [email protected] (archive at: [http://lists.kde.org/?l=kopete-devel&r=1&w=2 lists.kde.org])


KDE reports is a project started during GSoC 2013. It currently displays reports about bugs, commits, mailing lists and IRC Channels.
==== Project: IRC protocol ====
Website: http://reports.kde.org
source code: http://projects.kde.org/projects/websites/reports-kde-org


'''Brief Explanation:''' The app currently uses Rails 3.2. The test suite needs to be completed and the project should be upgraded to use Rails 4. Also, more reports are to be added. For example, forum activity, social media activity, blog activity(dot.kde.org and planet.kde.org) and others.
'''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:''' Upgraded reports app with a complete test suite and more reports.
'''Expected results:''' Restore IRC protocol into Kopete


'''Knowledge Prerequisite:''' Ruby and Rails
'''Knowledge Prerequisite:''' C++/Qt, IRC protocol


'''Mentor:''' Ben Cooksley (bcooksley at kde.org)
'''Mentor:''' Pali Rohár <pali.[email protected]>, Pali on #kopete


===Trojitá===
'''Mailing list:''' [email protected] (archive at: [http://lists.kde.org/?l=kopete-devel&r=1&w=2 lists.kde.org])


[http://trojita.flaska.net/ Trojitá] is a fast IMAP e-mail client. Since late 2012, it is a part of KDE's extragear. The project focuses on delivering a usable, fast, standards-compliant, cross-platform and reliable e-mail client which can scale from cell phones to huge e-mail archives without annoying slowdowns.
=== Libreoffice ===


====Project: Add support for secure messaging to Trojitá====
==== Project: Port Libreoffice skin to Qt 5 ====


'''Brief explanation:''' It would be cool to have support for encrypted and signed messages, both with GnuPG and S/MIME (X.509). The [http://delta.affinix.com/qca/ QCA library] provides the required infrastructure, but this task would still require a fair bit of hacking, including working on a client-side MIME parser in Trojitá.
'''Brief explanation:''' LibreOffice uses its own widget toolkit.  This gets skinned in various ways by Qt and other toolkits. There is a skin for Qt 4 but not for Qt 5.


'''Expected results:''' Add support for creating, reading and verifying the GnuPG and X.509-wrapped messages.
'''Expected results:''' LibreOffice widgets looks like Qt 5 widgets


'''Knowledge Prerequisites:''' Decent knowledge of C++ programming, familiarity with Qt, willingness to use GPG. Being able and willing to work with the community.
'''Knowledge Prerequisite:''' C++/Qt, git


'''Must-have checklist:''' Get in touch with the developers, subscribe to the mailing list, learn how to use Trojitá. Perhaps there are some features that you find lacking -- go and add them. Perhaps there's a bug which is annoying -- fix it! Get involved in Trojita's development. It is a prerequisite to have at least one patch in Trojitá in order to be considered for application.
'''Mentor:''' Jonathan Riddell <jr@jriddell.org> Riddell on #kde-devel


'''Mentor:''' Jan Kundrát <[email protected]>
'''Co-Mentor:'''


[[Category:Mentoring]]
This patch takes the "kde4" skin and renames it to "kde5" still using Qt 4.  It can be used as the start framework to port to Qt 5.
https://gerrit.libreoffice.org/#/c/13078/

Latest revision as of 10:38, 9 March 2016

GSoC 2015 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.

Plasma

Project: Port various KDE4 Plasmoids to Plasma 5

Brief explanation: When we ported from Plasma 4 to Plasma 5 some useful Plasmoids ended up not being initially ported. We want the more important existing applets to continue to run which . Students should select a few Plasmoids which they deem useful for their proposal along with some innovative ideas for improvements. Students should show knowledge of the level of work related.

Expected results: A few fully working plasmoids, polished and better than before.

Knowledge Prerequisite: QML skills. Ideally some Plasmoid experience

Mentor: Sebastian Kugler with help of the Plasma team.

Project: Port KSystemLog to use journald as a backend

Brief explanation: KSystemLog is a tool for viewing log files. This has slowly started to fail as log files moved in various distributions. Journald provides a common interface to query programatically system and user logs which will fix the main issue. Applications should impress me with their ideas utilising the available features.

Expected results: A ported to frameworks journald powered log viewer.

Knowledge Prerequisite: C++, Qt.

Mentor: David Edmundson with help of the Plasma team.

Project: Port various Systemsettings KCMs to QML

Brief explanation: The codebase of the systemsettings modules is old and needs a redesign both code-wise and UI-wise. Students should select a few KCMs and propose how to port them to the new QML/C++ hybrid with some ideas on the improvement of their UI.

Expected results: A few fully working KCM modules ported to a mix of QML and C++ that still load correctly in Systemsettings and KCMshell.

Knowledge Prerequisite: QML and C++ skills.

Mentor: Marco Martin with help of the Plasma team.

Various Places

Project: package install for 3rd party applications

Brief explanation: KDE software needs to install software in various places. Investigate the best way to do this which is probably to use packagekit. Then implement this in the places which need it.

Expected results: Work out best way for 3rd party programs to query and install packages. Then adapt the following pieces of software to install the packages they need:

  • dolphin file share install samba
  • kcm access to install orca
  • gwenview to install kipi-plugins
  • kcm locale should install kde-l10n-xx
  • kickoff to implement package install like kicker?
  • k3b needs to install codecs (on ubuntu at least)

all this should be done in a way which works for the major distributions.

Appstream could be used to find package names to install although support for this in Ubuntu is incomplete.

Knowledge Prerequisite: C++

Mentor: Jonathan Riddell (Riddell in #plasma on freenode IRC) with help of the Plasma team.

Plasma and Gluon

Project: Extend gamingFreedom.org framework to be more generic

Brief explanation: Over the last couple of years, the gamingFreedom.org website and server side components have been created, which implement Open Collaboration Services (OCS) in a generic and reusable form. We are now at a point where it would make sense to attempt to use this for further purposes, rather than only for gamingFreedom.org. Specifically, a new implementation of the server component employed for hosting Plasma related content is needed, and a website for presenting this content on the web.

Expected results: A new website based on gamingFreedom.org's OCS client libraries, and a server implementation for hosting Plasma content.

Knowledge Prerequisite: PHP for the client and server code

Mentor: Claudio Desideri and Dan Leinir Turthra Jensen with help of the Plasma team.

Kdenlive

Kdenlive is an intuitive and powerful multi-track video editor, including most recent video technologies. Our software is completely free, as defined by the GNU foundation. Using Kdenlive is investing in a community driven project, which aims to establish relationships between people in order to built the best video tools.

Project: Add support for new Animation capabilities

Brief explanation: MLT, the media frameworks we use for rendering, has recently added a new property animation to its objects. This allows much simpler, smoother and more general animations than the traditional keyframes technology. We then need new widgets to edit these properties, and eventually evolve our on-monitor interactions.

Expected results: At the end of the project, we should be able to add and graphically adjust these animation parameters through controls in the effects stack panel, and bonus on the monitor.

Knowledge Prerequisite: In the end you will assemble QtWidgets and interact with MLT data through C++. So you should be at ease with C++ and Qt (no need to be an expert), and have a look to the MLT manual page about animation.

Mentor: Vincent Pinon with help of the Kdenlive team.

Project: Redesign titler using WebVFX

Brief explanation: Our titler, the tool we use to add text and drawing objects over the video, relies on a home made module added to the MLT framework. Our module is limited in features, quite slow to render, and demands work to maintain. MLT has since then been plugged into WebVFX engine, which provides infinite possibilities through web technologies, and it is certainly more robust. The goal is then to port our titler to this engine, then maybe evolve the interface to offer new possibilities.

Expected results: At the end of the project, the titler should rely only on MLT WebVFX module. Bonus we should be able to add and easily edit more objects types.

Knowledge Prerequisite: First step is to translate our XML to Web formats inside the C++ code, so you should understand those dialects. For the UI rework, you would then work with Qt, in either C++ or QML.

Mentor: Vincent Pinon with help of the Kdenlive team.

Project: add import/export filters for video editors exchange formats

Brief explanation: To reduce the barrier to switch to Kdenlive, users should be able to import and export with commercial editing softwares (at least partially). Some scripts already exist to crudely parse EDL or AAF formats, the goal is to do it cleanly integrated in Kdenlive.

Expected results: At the end of the project, we should be able to exchange projects with one or more commercial tools. Effects and transitions will probably be limited, but timeline construction should be transferable.

Knowledge Prerequisite: The work will consist in manipulating XML data with Qt (C++), so you should understand those dialects.

Mentor: Vincent Pinon with help of the Kdenlive team.

Project: make Kdenlive work on Windows and OSX

Brief explanation: All the frameworks Kdenlive relies on are working on other platforms, and Kdenlive used run on those long time ago. The goal here is to setup build environments on one or two other OS's, and fix the things that prevent Kdenlive to work.

Expected results: At the end of the project, Kdenlive should work reliably on one or two commercial OS's.

Knowledge Prerequisite: Setting up and running builds, fixing things in C++, CMake, dependencies.

Mentor: Vincent Pinon with help of the Kdenlive and KDE porting teams.

Amarok

Amarok is a Music player that helps you organize and rediscover your music.

Project: Port Amarok to Qt5/Kf5/Plasma5

Brief explanation: Currently Amarok still depends on kdelibs 4.x and Qt4.

Expected results: Amarok should compile with Qt 5.x, kdelibs4 dependencies should be replaced with kf5. Port most existing plasma widgets of the Context View to Plasma 5 (at least the most important should be ported). The default system themes should apply to Amarok flawlessly. A very important part of this project is testing the port and adapting the unit tests.

Knowledge Prerequisite: good knowledge of C++/Qt, ideally being familiar with kf 5 and Plasma 5. The student should have some basic knowledge of the Amarok project and its functions as well as its architecture. All relevant information about Amarok, Qt5, kf5 and Plasma 5 can be found online, every suitable applicant should be able to find this documentation on their own.

Mentor: To be determined. All discussions about the project should be held on the mailinglist and/or on IRC

digiKam

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

Project: Re-write database KIO-slaves as pure Qt5 using multithreading

Brief explanation: Originally, KIO-Slaves have been implemented to run database queries in a separated process to prevent problem with SQlite. Since SQlite support re-entrancy and queries from separated threads, digiKam KIO-slaves used to process complex and long database queries can be re-written as core implementation using Qt thread API. This will improve digiKam availability in time when system is updated in low-level, and permit to adjust finely CPU cores assigned to database process.

Dependencies: : digiKam core from "framework" branch (KF5)

Links: Using Sqlite in multi-threaded application, Bug #146557

Knowledge Prerequisite: C/C++, Qt, database, multi-threading

Expected results: Identify all parts of digiKam core which query database through KIO-slaves mechanism, factorize code in same interface and write a multi-threaded wrapper to run SQlite queries. Write test code to check quickly if database core implementation changes don't affect wrapper functionality. Note : digiKam use internally URL + XML formating to pass data to KIO-slaves and this not be changed.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>

Project: Advanced Metadata HUB

Brief explanation: digiKam has already some options to manage workflow between image metadata and database, through the setup/metadata configuration panel. The goal of this project is to write a more advance setup to control finely the most important metadata field in order to read from image and populate database and vis versa. The list of metadata to drive must be easily extensible and configurable. Also, the metadata workflow to synchronize image with database must be more flexible and must provide a way to synchronize files at end of digiKam session and not only in real time (typical case : editing image tags to write in images).

Dependencies: : digiKam core and libkexiv2 from "framework" branch (KF5)

Links: Bugs list from bugzilla

Knowledge Prerequisite: C/C++, Qt, database, multi-threading

Expected results: Create metadata hub widget for settings panel, adjust current hub and image scanner implementations, add test code.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>

Project: Add WebP and WebM support

Brief explanation: WebP/WebM is new wavelets based image/video format from Google, based on RIFF/MKV container. This format become more popular on the Web and both can be used through an open-source library. We need to support these formats as editable in digiKam (WebP) and manageable by database mechanism through metadata (WebP and WebM).

Dependencies: : digiKam core and libkexiv2 from "framework" branch (KF5), Exiv2 library

Links: WebM format, WebP format

Knowledge Prerequisite: C/C++, Qt, Metadata

Expected results: Patch Exiv2 library to support both formats in read/write meta-data mode and add optional WebP support in digiKam core to be able to edit images (read/write image contents in 16 bits color depth). Write test code to check new functionality in time.

Difficulty: high

Further Informations: GSoC/digikam/WebP_WebM_wazery_proposal

Mentors: Gilles Caulier <caulier dot gilles at gmail dot com> + Someone from Exiv2 team

Project: Factorize and port to KF5 all web service Import/Export KIPI tools

Brief explanation: All tools dedicated to import or export items from KIPI host applications to web services as Flickr, GDrive, Dropbox, Facebook, Picasa, etc... need to be factored and ported to KF5/Qt5. Factorization include to make common widgets (settings, GUI layout, rules, etc), and background processing to prevents duplicate code. Also, in order to reduce KIPI host application time loading, the number of tools must be limited. Tools must be grouped by categories, as Social Networks, Cloud Service, Photo Hosting, etc...

Dependencies: : digiKam KIPI interface, KIPI Plugins

Bugzilla entries: 221704

Knowledge Prerequisite: C/C++, Qt/KDE, GUI

Expected results: KIPI web services tools ported to KF5 and running with digiKam 5.0.0.

Difficulty: high

Lead Mentor: Gilles Caulier <caulier dot gilles at gmail dot com>

Marble

Marble is a virtual globe and world atlas — your swiss army knife for maps. Find your way and explore the world!

Project: Starting to edit OpenStreetMap Data

Brief explanation: During the last Google Summer of Code 2014 Cruceru Calin worked on an Edit mode for Marble. Right now it's possible to draw elementary shapes and features (Polygons/Polylines, Placemarks, GroundOverlays, etc.). These geometry primitives can be saved as KML files and there is some experimental OSM support already. This project will be about extending the current Edit Maps mode. Focus will be especially towards enabling advanced editing that allows for more sophisticated drawing capabilities but also for tagging and other features that are required for OSM support. A special focus might also be on refactoring the existing code base where it's useful.


Expected results: Reliable and useful means to create and edit OSM files using Marble.

Knowledge Prerequisite: C++, Qt,

Mentors: Torsten Rahn, Cruceru Calin, Dennis Nienhüser

Project: Improve Printing Support and polish Marble rendering

Brief explanation: Marble has good rendering and basic printing of a screenshot already in place. However we'd like to see high resolution printing. This project should explore ways to improve printing support (e.g. by resizing the widget temporarily to a big geometry and printing the resized canvas). In order to adapt to the higher resolution the text size and the line widths need to adapt automatically to the increased resolution. As a result of this project Marble should feature largely improved printing of the current scenery (including the current map theme and projection) that is visible to the Marble user. As a second part of this project regular Marble rendering should be improved. This would include:

* Improved rendering of Placemark Labels
* Improved rendering of Street labels (e.g. in OSM rendering)
* Improved OSM rendering
* Improved rendering of the OSM tiles to reduce bluriness during reprojection.

Depending on the skill-set of the student and depending on project progress code-refactoring of the Marble rendering in order to prepare for OpenGL support could be included with the project as well.

Expected results: Improved printing support with high resolution maps. Better rendering of Placemark/Street labels and better rendering of OSM textures.

Knowledge Prerequisite: C++, Qt,

Mentors: Torsten Rahn, Cruceru Calin, Dennis Nienhüser

Project: Turning Marble into a small GIS system

Brief explanation: During the last Google Summer of Code 2014 Cruceru Calin worked on an Edit mode ("Annotation Plugin") for Marble. Right now it's possible to draw elementary shapes and features (Polygons/Polylines, Placemarks, GroundOverlays, etc.). These geometry primitives can be saved as KML files. During this project we'd like to extend the feature set towards classical requirements of a GIS system. Focus will be especially towards enabling advanced editing that allows for more sophisticated drawing capabilities but also for tagging and other features that are required for a GIS Editor. Depending on the experience of the student we might also focus on other topics like Data analysis or PostGIS support.

Expected results: Adding capabilities to Marble that allow for using it for simple tasks that people would usually do using Quantum-GIS.

Knowledge Prerequisite: C++, Qt

Mentors: Torsten Rahn, Cruceru Calin, Dennis Nienhüser

Project: Statistical Data Visualization and Extending Marble Game

Brief explanation: During the last Google Summer of Code 2014 Abhinav Gangwar created the "Marble Game". This project is about extending Marble's library in a way so that it's easy to display statistical data on maps in a color coded ("choropleth") way

Urbanisation%20Map.png

The Marble application should include a default dataset that allows to display such maps for a set of important properties per country (e.g. life expectancy, literacy, etc.). A browser for statistical data should be added to Marble. The CIA Factbook data should be updated as well as the placemark data. The Marble Game should be further improved and it should be possible to make use of the Statistics feature.

Possible additional tasks: Add streetview feature to Marble and the Marble Game.

Expected results: Marble provides a tool that allows to visualize a ready-made dataset of statistical data in a color-coded choropleth way. The Marble Game should also be extended to make use of that feature.

Knowledge Prerequisite: C++, Qt

Mentors: Torsten Rahn, Abhinav Gangwar, Dennis Nienhüser

KStars

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

Project: Ekos Scheduler

Brief explanation: Ekos is an advanced astrophotography tool for Linux. It utilizes INDI for device control. With Ekos, the user can use the telescope, CCD, and other equipment to perform Astrophotography tasks. However, the user has to be present to configure the options and to command the actions to perform all the astrophotography related tasks, and hence a scheduler is required to automate observations to be constrained within certain limitations such as required minimum angular separation from the moon, whether conditions...etc. Furthermore, the observations should be triggered when certain conditions are met such as observation time, object's altitude...etc. The prospective student is expected to develop a Simple Ekos scheduler to trigger observation runs when certain conditions are met and when the limitations are required.

Expected results: Simple scheduler to automate astrophotography runs based on some conditions and within user-configurable limitations.

Knowledge Prerequisite: C++, Qt, INDI

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 timeframe.
  • Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2015.

Project: Constellation art

Brief explanation: KStars currently draws constellation lines, names, and boundaries, but constellation art is missing. The student is expected to study KStars API and develop a new SkyComponent to superimpose the constellation artwork unto the sky map while re-working other components in KStars to support this. The structure must support multiple sky cultures. The artwork itself must be available under a permissible license. New constellation artwork should be available for download using the KNewStuff framework. The user should be able to select the sky culture.

Expected results: High quality artwork for Western constellations in addition to one non-western constellation artwork that can be switched on/off in the sky map.

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 timeframe.
  • Implement some of the improvements, producing production-ready code that can be included in the next release of KStars after GSoC 2015.

Project: Fix our deep-sky data handling

Brief explanation: Currently, KStars handles data from deep-sky object catalogues in an SQLite database. While this is working well, there are some more features we would like to have, and some that should be implemented in order to sanitize the deep-sky data handling, such as automatic cross-referencing of deep-sky objects across catalogs, organizing deep-sky data better in the database etc using Hierarchical Triangular Mesh, etc.

More details here: http://techbase.kde.org/Projects/Edu/KStars/Better_deep-sky_handling

Expected results: Some, or all of the improvements to deep-sky handling suggested above (or maybe even your own suggestions), implemented completely in solid, release-worthy code.

Knowledge Prerequisite: C++, Qt, understanding of astronomical catalogues, some experience with data structures.

Mentors: Rafal Kulaga (IRC: rkulaga)

The student will need to:

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

PS: If all this looks daunting, that's because you have not (yet) talked to us. If you're really interested, get onto #kde-kstars and ping the mentors.

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: Rafal Kulaga (IRC: rkulaga)

KDE Edu

Project: Integrate Cantor into LabPlot

LabPlot is a KDE-application for interactive graphing and analysis of scientific data.

Brief explanation: The integration is twofold:

  1. currently, for the created plots LabPlot uses either the data provided by hand in a spreadseet or by using data imported from external ascii-files. By having Cantor within LabPlot it should be possible to access the data sets created in a computer algebra session (say Maxima) provided by Cantor. Cantor's session have to be integrated into LabPlot's model-view framework and have to be put onto the same foot as all the other objects managable in LabPlot (spreadsheet, worksheets etc.).
  2. By calling a CAS-specific command for creating a 2D-plot in Cantor, Cantor creates an external process that renders the plot and embeds the result as a pixmap. Instead of such a static pixmap, LabPlot's plots should be embeded. This would provide high degree of control of the plot appearance as provided by LabPlot.

Mentor: Alexander Semke

Project: Integrate VTK into LabPlot, investigate Tulip

LabPlot is a KDE-application for interactive graphing and analysis of scientific data.

Brief explanation:

  1. LabPlot lacks 3D-functionality. In the old KDE3-based LabPlot qwt3D was used for this that is not an option anymore. The task consists of the integration of VTK -libs. Also, the relevant widgets for 3D-plot editting should be created in a manner similar for all the other objects available in LabPlot now.
  2. Investigate whether it's reasonable to use LabPlot as a frontend (or to extend it to be a frontend) to the functionality provided by Tulip yes, how?

Mentor: Alexander Semke

Project: Port of GCompris in Qt Quick

GCompris is a an educational software suite comprising of numerous activities for children aged 2 to 10. Originaly written in Gtk+ it's development team decided to rewrite it from scratch in Qt Quick. It has also been decided that this version will be integrated in KDE which is the reason of the project being here.

Goals:

  1. Porting several GCompris activities in Qt Quick. There is a page that tracks the porting effort that will help you select the activity set you are interested in.
  2. 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.

Knowledge Prerequisite: By the start of GSoC you should

  1. Be interested in children education
  2. Be familiar with GCompris concept and content
  3. Basic knowledge in a programming language (a 1 year school course is enough)
  4. Be able to build the Qt Quick version of GCompris

Application guide:

  1. Writing or porting an activity takes about the same time. The advantage of the porting is that the tuning, the graphishm and the sounds are already available. You can count 2 weeks of development for an activity.
  2. 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.
  3. You have to follow the instructions here and provide your exercise as a pull request.

Mentor: Bruno Coudoin (IRC: bdoin #gcompris on freenode)

Project: Make an Editor Library/Plugin for KVTML Files

Kvtml is a file format for vocabulary training that is used by all of the language applications in KDE Edu. The format is loaded into a KEduVocDocument class which is handled by a library with the same name. The format is reasonably rich with a tree structure for lessons and support for sound, images and any number of translations.

To edit the KEduVocDocument many applications implement an editor. Some editors, like the one in Parley, are quite advanced with support for the whole format, as well as semi-automatic translations from websites like wiktionary.com and google search for images. Others are much simpler like the one in KWordQuiz, which is more or less only a simple table editor.


Goals:

The goal of the project is to separate the built-in editor in Parley into a library and/or plugin and make it available for other applications. This editor library should be made flexible and configurable so that applications with different needs could create an editor which supports the level of sophistication that suits that application best.

Summary of the goals:

  1. Separate the editor of Parley into a library. This library could either be placed into the current existing libkeduvocdocument repository or be placed into a library of its own.
  2. Remove all existing ties to other parts of Parley and generalize the settings to APIs.
  3. Make the editor more flexible and configurable so that the application can create its own level of sophistication of its editor. Note that this configurability is intended for the application programmer, not the end user of the application.
  4. Improve the documentation by providing a tutorial for the application programmer and also complete API documentation.
  5. Make Parley use this editor library instead of its current built-in one.

Knowledge Prerequisite: By the start of GSoC you should

  1. be familiar with the kde edu language applications in general and Parley in particular
  2. be familiar with the kvtml format and the KEduVocDocument library.
  3. be familiar with C++ and Qt
  4. be familiar with building and running KDE applications

Mentor: Inge wallin (IRC: ingwa #kde-edu on freenode)

Keyboard Layouts

Keyboard layouts in KDE 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: Integrating Input Methods with keyboard layout configuration

Brief explanation: Input method and keyboard layout configuration are serving the same purpose - to allow users to type text in non-default language. Currently KDE has integrated system to configure keyboard layouts but IM need to be configured somewhere else. Also when IM is configured it takes over some functions of keyboard layout configuration. So it would be nice if we could have IM and keyboard layout configuration in one place. It seems that IBus has already gained community acceptance so this will be the target for integration into KDE keyboard module.

Expected results: Keyboard configuration module in System settings will include IM configuration and it will be integrated with existing keyboard layout options.

Knowledge Prerequisite: good knowledge of C++, development experience with Qt and KDE, understanding of Input Methods (IBus)

KDevelop

Project: Clang Integration

Brief explanation: Finish the kdev-clang plugin to make it a usable replacement for the existing C++ plugin.

Expected results: Find the still missing features from the KDevelop4's C++ support and port them over to kdev-clang, so it can become the mainstream C/C++ Solution

Knowledge Prerequisite: C++, Qt. Knowledge about Clang is helpful

Mentor: Kevin Funk

Project: Checker Framework

Brief explanation: A generic framework should be created which provides the foundation for other plugins to report errors.

Expected results: Right now we have the problems toolview but it is tightly coupled to the DUChain. This should be changed to use a separate item repository which stores the problems for a given path. The data stored would be: Path and range of where the issue is found, a short error message and optionally a long description. Furthermore, plugins might want to store additional info from which the problem could be fixed (compare to the 'add include path' or similar wizards we have already in the language framework).

This framework should then be used to integrate various tools.

First of all the existing language plugins should show the problems they find there. The existing playground plugins for krazy and cppcheck integration should reuse that framework any other linters could be integrated, such as jslint, pylint, clang-check, etc. pp. runtime checkers could be integrated, such as valgrind's memcheck, ptrcheck, helgrind, drd, ...

Knowledge Prerequisite: C++, Qt. Knowledge of debugging tools is helpful.

Mentor: Milian Wolff

Project: SVN Plugin Rewrite

Brief explanation: Rewrite the SVN plugin to use the C-API directly.

Expected results: The existing SVN plugin uses an outdated kdevsvncpp checkout internally which causes troubles, warnings and licensing issues. Port the plugin to either the C-API of svn or alternatively try to reuse code from current kdevsvn. The result should be a tested, working plugin for SVN integration without licensing issues nor compile time warnings about usage of deprecated API.

Knowledge Prerequisite: C, C++, Qt, SVN

Mentor: Milian Wolff

Project: LLDB Support

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

Expected results: 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.

Knowledge Prerequisite: C, C++, Qt, debugging intrinsic problems

Mentor: KDevelop team

KDE PIM

The KDE PIM community work on a set of libraries and applications for Personal Information Management, including email, calendaring, contacts, and feed aggregation.

Project: OpenHolidays

Brief explanation: The KHolidays library provides KDE applications with information on public holidays around the world, however the file format is very hard to use and maintain and the library features are very limited and restricted to Qt users. The goal of the OpenHolidays project is to develop a new open standard and data repository that can be used by any project that needs the data. See http://community.kde.org/KDE_PIM/KHolidays for more details.

Expected results: Define the new JSON file format and port the existing data files to the new format. Develop a shared Qt-only library to parse the holiday files and provide access to them with a iCal style event-based api. Implement an Akonadi resource to access the data. Extended goals: Develop a JavaScript library to use the files. Develop a web site and web service at openholidays.org to provide online access to the data files.

Knowledge Prerequisite: C++ and Qt for core goals, JavaScript and web services for extended goals.

Mentor: John Layt and other KDE PIM community members.

Project: QtQuick ToDo API / Plasmoid

Brief explanation: KDE PIM wants to make it's data accessible for applications which use QML to declare their user interfaces, e.g. applications using QtQuick. For that they need data handling objects that are accessible through QML, e.g. item models that have a mapping of string based role names to enum value based roles in C++, etc.

Expected results: Define and implement a general QML API for accessing and creating Akonadis ToDo data. Write / Port a ToDo Plasmoid for Plasma Desktop or Plasma Active to show off the new API. Bonus: Port Kontact Touch Task to the new API instead of, or in addition to the Plasmoid.

Knowledge Prerequisite: C++, Qt, QtQuick

Possible Mentors: Kevin Krammer, and other KDE PIM community members

Simon

Simon is a speech recognition suite.

Website - Mailing list - IRC channel: #kde-speech on Freenode.

Project: Streamline handling of various resources

Brief explanation: Simon uses a multitude of different components: Scenarios, Base models, Shadow vocabulary, Language profiles, etc.

While many of these components can be downloaded from within Simon, some can't and even for those that are better integrated, end-users still have to read additional documentation to know which components work together and which don't.

The aim of this project is to bring the handling of these resources under a uniform and user-friendly interface. Specifically, the interface should resolve conflicts automatically and deduce an optimal default setup by itself (e.g. based on the system language and installed programs).

Expected results: Much more user friendly setup.

Knowledge Prerequisite: C++/Qt

Mentor: Peter Grasch <peter {+at+} grasch.net>

Resources: Some work (mostly brainstorming and UI design) was already conducted during Season of KDE 2013. Please contact me for details. This does not mean that this project is already assigned!

Okular

Okular is a Document Viewer.

Project: Better Accessibility for Okular

Brief explanation: We should implement Qt accessibility APIs to make Okular usable by more users. This would allow blind people to read documents.

Expected results: You should be able to "read" Okular documents using Orca or other "screen reading" software. As long as the document exposes the contents in text form, we can let assistive technology pick it up and present it to the user in a different way (for example non-textual). An important goal is to transfer as much of the structure of the document as possible, so that ideally the sematics (this is a heading, here is normal text, page number) are preserved. Finding well working PDF solutions is still a challenge for blind people on any operating system. For now the focus will be on Orca since it's the best working screen reader on Linux used by most blind users.

Knowledge Prerequisite: C++

Mentor: Albert, Frederik helping out with the accessibility parts

Project: Implement PDF Poppler features

Brief explanation: Poppler has some support for features we don't support, implement them

Expected results: Poppler has support for pdf layer views, tagged pdf support, linearized pdf support yet we in Okular don't offer that features to our users. The result from this project is having those exposed to the final users

Knowledge Prerequisite: C++

Mentor: Albert

Project: Implement SecurityHandler V6 in Poppler

Brief explanation: Poppler needs to support SecurityHandler V6 to be able to open some pdf files

Expected results: Poppler (and hence Okular) can open files with SecurityHandler V6 like the ones in https://bugs.freedesktop.org/show_bug.cgi?id=85368 and https://bugs.freedesktop.org/show_bug.cgi?id=88151

Knowledge Prerequisite: C++

Mentor: Albert

KDE Connect

Project: Improve KDE Connect encryption

Brief explanation: We want to implement a better encrypted protocol for KDE Connect, as discussed here: http://albertvaka.wordpress.com/2013/09/19/how-kde-connect-encryption-works/ I would like to see a solid and peer-reviewed design before accepting this project.

Expected results: Have a secure encryption algorithm implemented in both KDE (C++/Qt) and Android (Java) clients.

Knowledge Prerequisite: Deep knowledge about encryption and security.

Mentor: Albert Vaca <albertvaka {+at+} gmail.com>

Resources: kdeconnect

Project: Build a Qt-only multiplatform KDEConnect client

Brief explanation: We want to implement a cross platform client written in Qt that can run in virtually any platform supported by Qt (Windows Phone, Jolla, iOS, OSX, etc.) using the QPA (Qt Platform Abstraction) and QML. It will be challenging because Qt5 for phones is still quite new and implementing some features might not be possible yet, but it will be worth it to investigate what is possible and what not, and even contribute patches to Qt for some aspects. A lot of the core classes used in KDE Connect for Plasma could be reused and shared because they are mostly Qt (and would be part of the GSOC to make sure they end only using Qt, so we can get to re-use them). Not every feature is going to be available to every platform, and some plugins will be platform-specific, but as part of this GSOC project I would love to see it running as good as possible in one of the platforms already mentioned, and with basic functionallity in a couple more. (That is: center it around a platform and make it work well there, writting platform-specific plugins and code if needed, but making sure it still compiles and runs in other platforms).

Knowledge Prerequisite: Qt5 and building cross-platform code.

Mentor: Albert Vaca <albertvaka {+at+} gmail.com>

Resources: kdeconnect

Solid

Project: Improve sharing experience

Brief explanation: Improve the content sharing experience in Plasma by extending and improving Samba share, implementing other ways of sharing and write new ways of discovering other people's shares.

Expected results: It should be possible to discover "shares" using dolphin (possibly via a new kioslave?) and it should be possible to share a folder between two Plasma computers really fast and easy (possibly implementing an http server plus discovery via avahi).

Knowledge Prerequisite: C++/Qt, extra points for KIO experience.

Mentor: Àlex Fiestas <afiestas {+at+} kde.org>

Resources: avahi, http, kdenetwork-fileshare

Muon

Project: Better support for your distribution

Brief explanation: Muon needs to be ensured to work perfectly on any distribution, this project should target one of the (major) distributions, enumerate the problems to solve and propose solutions.

Expected results: Muon users of your distribution will be happy ever-after.

Knowledge Prerequisite: C++/Qt, the technology required for the platform

Mentor: Aleix Pol


KWin

Project: DRM/KMS backend for kwin_wayland

Brief explanation: KWin_wayland currently only supports rendering to another Wayland server. In future it should be possible to go down to the hardware directly. For this a DRM/KMS rendering backend is required. This requires that a new backend is implemented for the OpenGL compositor and maybe the QPainter compositor. As KWin needs to handle kernel mode settings in this mode the output information need to be queried from the hardware and an implementation for KWin::Screens needs to be provided and from there propagated to the Wayland clients. In addition if the time of the project permits it an interface should be exposed for KScreen to configure the outputs.

Expected results: KWin_wayland can render to DRM/KMS and fetches output information from the hardware

Knowledge Prerequisite: C++/Qt, Wayland, KMS and C knowlege are from advantage

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

Trojitá

Trojitá is a fast IMAP e-mail client. Since late 2012, it is a part of KDE's extragear. The project focuses on delivering a usable, fast, standards-compliant, cross-platform and reliable e-mail client which can scale from cell phones to huge e-mail archives without annoying slowdowns.

Project: Port to BlackBerry OS 10

Brief explanation: This work involves improving the separation of business logic from the UI concerns, an effort started and well-underway due to the Ubuntu Touch project, and adding a new GUI wirrten in QML for BlackBerry OS 10.

Expected results: Trojitá running on BlackBerry Z10 with basic features, including reading and writing e-mails

Knowledge Prerequisite: C++/Qt, QML

Mentor: Jan Kundrát <[email protected]>

Project: Multiaccount support

Brief explanation: Trojitá's GUI only shows one IMAP account at once. The scope of this task is to analyze what needs to be done, and implement the required changes for making it possible to show multiple IMAP accounts. General bugfixes are expected in the rest of the time.

Expected results: Full support for multiple IMAP accounts, including unit test coverage

Knowledge Prerequisite: C++, Qt

Mentor: Jan Kundrát <[email protected]>

Gluon

Gluon is a project to build a Qt and KDE based game engine and game development tool. The engine is designed to support both mobile and desktop game development. We have ported the engine to Qt5 last year and are currently working on releasing a first Qt5 based version.

Project: Build a QtQml based script system

Brief explanation: In Qt4 QtScript was the solution to scripting support for applications. With the port to Qt5 the new QtQml module was introduced, including a new scripting system, but QtScript was still available. With Qt5.5 QtScript is planned to be deprecated and completely removed in Qt5.6. This means that our scripting system, which is currently built on QtScript, needs to be ported to QtQml.

Expected results: A scripting system that can be used to write scripts for games.

Knowledge Prerequisite: C++/Qt at least. Experience with QtQuick/QML is a strong advantage.

Mentor: Arjen Hiemstra

Project: Expand Gluon Input

Brief explanation: During the port to Qt5 we also overhauled the input system in Gluon to be more capable. However, we kept the implementation rather limited since we also had other elements to work on. This project would expand GluonInput with support for additional devices and platforms.

Expected results: Additional platform and device plugins for GluonInput.

Knowledge Prerequisite: C++/Qt at least. Experience with platform-specific input libraries like XInput2 for Xorg is an advantage.

Mentor: Arjen Hiemstra

Krita

Krita is an advanced 2D painting application. 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.

Project: Integrate Animation in Krita's core

Brief explanation: We have gone through three iterations of animation support code in Krita. With this experience, it's become clear that we need to work the support for animatins right into Krita's core engine. This project comprises partly that, and partly updating the existing animation gui that was created in 2014.

Expected results: by the end of the summer, the animation support in Krita should be ready for end-users to create 2D animations with, whether for game sprites or short cartoons.

Knowledge Prerequisite: C++/Qt at least.

Mentor: Boudewijn Rempt

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

Project: Improve Normal Mapping Workflow

Brief explanation: Normal maps are textures that describe surface detail on a 3d model by describing how much each pixel deviates from the surface the texture is put on. A normal map gives the ability to tell the renderer there's a different normal per texel(texture pixel), this way, you can describe subtle differences in surface without requiring the polygons for it. It does so by describing the normal angle to the surface by using the R, G and B channels. Now, normal maps, due to them being quite mathematical, are usually baked. But these bakes are not always perfect. furthermore, there's a lot of interest into handpainting textures, amongst which normal maps.

Expected results: by the end of the summer, a new brush engine, which takes the tilt-direction and has that control the redness and greenness. And then takes the tilt-elevation, and has that control the blueness.

Knowledge Prerequisite: knowledge of C++, Qt. and mathematics

Mentor: Boudewijn Rempt

Calligra

Project: Variable thickness lines

Brief explanation: One of the most fundamental basics of drawing is varying the width of your lines to show shape, form and perspective. Almost every line tapers at either end, and often gets thicker and thinner in different places as needed. For purely technical and histrorical reasons though, every vector program (Illustrator, Inkscape, Karbon etc) make curves all one hard width. This proposal is to create a variable width path shape / tool, much like the path tool, would allow drawing curves, but where each node could have its width set so that the line width changed smoothly from node to node. As a plugin for the Calligra suite, this would clearly benefit apps as Karbon and also Krita.

Expected results: variable width path tool is able to change the width of any path node to an arbitary percentage (say 155%) of the stroke width. See http://bugsfiles.kde.org/attachment.cgi?id=56995 for mockup. The shape needs to be able to save and load in svg/odf.

Knowledge Prerequisite: C++, Qt, SVG

Mentor: Thorsten Zachmann < zachmann @ kde dot org >

KIOSK

Project: KIOSK Tool

Brief explanation: Back in KDE 3 there was a tool to help administrators to configure the KDE Kiosk framework. The idea of this project is to start working on a new tool. The new application should be developed in close collaboration with the Visual Design Group to get a useful application for the targeted audience.

Expected results: a functional prototype for a new Kiosk tool with a working backend to configure and restrict actions and configuration options.

Knowledge Prerequisite: C++/Qt

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

Kubuntu

Project: Port Ubiquity to Qt 5

Brief explanation: Ubiquity is the installer for Kubuntu. It should be ported to Qt 5. It is written in Python and can be fiddly to test because much of the development needs to be done on a live system. Once the Qt 5 port is complete there are numerous other bugs that can be fixed. Drop into #kubuntu-devel to say hi. Code is in launchpad.net/ubiquity. Contact: Kubuntu-devel list.

Expected results: Ubiquity bug free and running with Qt 5

Knowledge Prerequisite: Python, PyQt

Mentor: Jonathan Riddell

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.

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.

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.

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.

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.

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.

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: The Ultimate Calamares user experience

Brief explanation: Design and development of Calamares started in June 2014, with deliverables as early as Fall 2014, so some hard choices had to be made in order to ship quickly. While Calamares doesn't look intensely unpleasant when compared to some other system installers, it is not a triumph of user experience design either.

The KDE Visual Design Group has already produced a design for Calamares in agreement with the Calamares team. It is now time to implement this design.

The student should propose a detailed action plan, with the ultimate deliverable being a complete visual overhaul of Calamares, including libcalamaresui and essential view modules. Intermediate deliverables must be listed in the proposal, with as much granularity as possible. The implementation should not deviate from the KDE VDG's design unless otherwise discussed, and during the coding season the student is expected to closely cooperate with both the Calamares team and the KDE VDG.

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.

Attention: This is a very challenging task, somewhat more demanding than the other ones we offer, and suitable for more experienced students. First time students are encouraged to consider our Python, Ruby or Debian tasks too. Exceptionally for this project we are requiring a qualification task to be completed by the prospective student. This qualification task should be delivered as a patch against master and sent to the mentor (Teo Mrnjavac <[email protected]>) before submitting a proposal for this project idea through the Google Summer of Code web application. Applicants that have not submitted a qualification task for this project will not be considered. The qualification task is defined as follows: implement the KDE VDG's design for the Users page (the Calamares module "users"). The webcam picture feature does not have to be implemented, but the avatar chooser is required. See this mockup.

Expected results: Calamares should look and feel as designed by the KDE Visual Design Group.

Knowledge Prerequisite: The student should have experience with Qt and C++; QML experience is a big plus.

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

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.

Project: Better history plugin

Brief explanation: History plugin is responsible for archiving chat history and also searching for old chat messages in archive. Currently Kopete has two history plugins: one which stores data to XML files and another one which stores data to SQLite database. Both plugins have some diffetent limitations like slow speed, bad search support, bad support for HTML messages, bad support for multiuser chat... This project aims to fix existing history plugin(s) or designing & implementing new one.

Expected results: Working fast chat history plugin with support for handling HTML messages, multichat messages, ability to search for messages in history, import/export feature (importing from services like googletalk/facebook can be great too), ...

Knowledge Prerequisite: C++/Qt, XML or SQLite (or any other data storage usefull for chat messages)

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

Co-Mentor: Kaushik Saurabh <[email protected]>, roide on #kopete

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

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

Project: PGP plugin

Brief explanation: Kopete has plugin which can sign or encrypt outgoing messages using GPG. It can also verify signature and decrypt incoming messages. This plugin is old, uses private kdepim library and needs fixing. It is hard to compile and use it. For this project I would except fixing this plugin to work again or writing new PGP plugin from scratch.

Expected results: Working support for PGP in Kopete

Knowledge Prerequisite: C++/Qt, GPG

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

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

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

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

Libreoffice

Project: Port Libreoffice skin to Qt 5

Brief explanation: LibreOffice uses its own widget toolkit. This gets skinned in various ways by Qt and other toolkits. There is a skin for Qt 4 but not for Qt 5.

Expected results: LibreOffice widgets looks like Qt 5 widgets

Knowledge Prerequisite: C++/Qt, git

Mentor: Jonathan Riddell <[email protected]> Riddell on #kde-devel

Co-Mentor:

This patch takes the "kde4" skin and renames it to "kde5" still using Qt 4. It can be used as the start framework to port to Qt 5. https://gerrit.libreoffice.org/#/c/13078/