GSoC/2013/Ideas

From KDE Community Wiki
< GSoC‎ | 2013
Revision as of 09:35, 10 May 2013 by Nightrose (talk | contribs) (revert)

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

Note

Ladies: You are also invited to apply for the OutreachProgramForWomen.


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.

Web

Project: Simple project report

Brief explanation: Create a web service with web frontend that is able to fetch data from different sources (bugzilla, git, mailist) to concentrate the activity of a project in a single site. Some simple statistics will be awesome.

Expected results: Web interface plus service

Knowledge Prerequisite: Ruby

Mentor: Rafael Fernández López ([email protected])

Project: Localization team management Tool

Brief explanation: Create a web application that handle all the localization (translation) team management (apps booking, and review process). Some details here: http://community.kde.org/KDE_Localization/LTMT

Expected results: Working web application with proper documentation and help translation teams to join the new tool

Knowledge Prerequisite: PHP and MySQL.

Mentor: : Luigi Toscano (luigi.toscano at tiscali.it), Sebastien Renard (renard at kde.org)

Zeitgeist

Project: Port libqzeitgeist to libzeitgeist2

Brief explanation: Just recently, Zeitgeist released libzeitgeist2, which inclues direct database access as a performance boost. libqzeitgeist is still using the raw DBus API which is slower.

Expected results: Port libqzeitgeist to use libzeitgeist2 and make sure there are no regressions

Knowledge Prerequisite: C, C++, Vala (C#/Java is close enough)

Mentor: Seif Lotfy [email protected] and Trever Fischer [email protected], #zeitgeist on Freenode IRC.

KDE Multimedia

Project: KMix2 Sound Menu

Brief explanation: KMix2 is mostly ready for daily use. However, the system tray popup is nothing special. A long time ago, KMix started to include Ubuntu's Sound Menu design. Development stalled, and a new rewrite of KMix is around the corner. Ubuntu's Sound Menu concept condenses all your multimedia controls into one notification area icon: volume, playlists, now playing, pulseaudio controls, etc.

Expected results: See https://wiki.ubuntu.com/SoundMenu

Knowledge Prerequisite: C++, Qt, Qt Widgets, basic understanding of media players

Mentor: Trever Fischer, #kde-multimedia on Freenode IRC. All applications should be sent to [email protected]

The student will need to:

  • Understand principals of KMix2's architecture
  • Implement the SoundMenu proposed designs
  • Implement MPRIS controls

Project: Improvements and enhancements for Plasma Media Center

Brief explanation: Plasma Media Center (PMC) is a KDE's media centric interface to view different media like Music, Pictures and Videos together at one place. Recently Plasma Media Center 1.0 has been released. It is optimized to work on different kind of devices.

Expected results: Some of the improvements that PMC can have

  • Categorizing media better like pictures on the basis of tags, videos according to different filters - length, quality etc
  • Improving playlist search - should be able to search through artist, album etc
  • Folder preview in Local Media Browsing

Note: Students are encouraged (and plus points) to research and come up with their own ideas. Ideas should be related to improvement of existing features that Plasma Media Center already have.

Knowledge Prerequisite: C++ is required. Basic knowledge of Qt/QML is a huge plus.

Mentor: Sinny Kumari <[email protected]> , #plasma on Freenode, Mailinglist

Amarok

Project: Reimplement Amarok 1.4/iTunes import on top of Statistics Synchronization and add more synchronization targets

Brief explanation: Since early 2.x versions, Amarok had an ability to import personal track metadata such as play count, rating and last played time from either Amarok 1.4 database or iTunes datbase. This works fine, but once the data are imported and one still uses the other audio player, the metadata of both players drift away. A new statistics synchronization framework was added in Amarok 2.7. This project would deal with reimplementing the medatada importers on top of the new StatSyncing framework and adding 2 new synchronization targets: one for synchronizing with another Amarok 2.x database and one for synchronizing with another popular audio player of student's choice (which needs to support the personal metadata; perhaps Clementine).

Implementing the import on top of StatSyncing will have following advantages:

  • it can be used repeatedly to synchronize data rather than one-time to overwrite them
  • it increases code reuse, the code to match tracks by metadata and to visualize the synchronization is already there
  • StatSyncing works with any set of collections, not just with Local Collection (useful e.g. if one wants to use just Nepomuk Collection)

Expected results: Importing metadata from Amarok 1.4 or iTunes will work no worse than it does currently (with the exception that matching will be done solely by track metadata such as title and album) and synchronizing with more players (Amarok 2.x and at least one more) will be possible.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers)

The student will need to:

  • understand principles of Amarok StatSyncing framework (under src/statsyncing/ in source code repository)
  • understand how current database importers work (these are under src/databaseimporter/)
  • understand how the other audio player of choice stores personal metadata (this is student's own work, mentors cannot help much here)

...before the coding period starts.

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Rewrite Audio CD Collection so that it doesn't use deprecated technologies

Brief explanation: As of version 2.7, Amarok supports audio CDs, somehow. Somehow means that it isn't reliable, uses technologies (audiocd KIO) in a way they weren't meant to be used and prevents deprecated Amarok frameworks (MediaDeviceFramework) from being ditched. Aim of this project is to rewrite the AudioCD Collection from scratch to use appropriate libraries and to be more reliable. The new AudioCD collection should:

  • use KDE's Solid to detect and enumerate CD drives and any CD media present. (it does currently, but it needs to be factored out of AudioCdConnectionAssistant to AudioCdCollectionFactory)
  • use MemoryCollection, MemoryMeta and MapChanger components to represent and manage its tracks
  • use libkcddb to asynchronously query CDDB information about the CD tracks
  • audiocd KIO may be retained just for copying tracks out of AudioCD Collection or replaced by other solution
  • (bonus point) if CD detection and track enumeration also works on Windows


Note that actual CD playback is handled by Phonon and is out of scope of this project.

Expected results: Reliable audio CD detection and track enumeration with asynchronous CDDB metadata fetching. This is a small to medium size project, so high level of polish will be expected.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers)

The student will need to understand how Amarok represents so-called Meta objects (tracks, albums...), Collections and track providers before the coding period starts. See the HACKING subfolder of Amarok source code, especially HACKING/architecture.

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Improving and modularizing tag guessing

Brief explanation: Amarok has been long able to get track tags (title, artist...) from MusicBrainz using either existing tags or using MusicIP audio fingerprints. In the mean time, MusicBrainz is phasing out MusicIP (PUIDs) in favour of AcousID and more services to guess/correct tags emerged. Goal of this project would be to:

  • create generic framework for tag getters (may be similar in design to StatSyncing::Controller + StatSyncing::Provider)
  • port existing (tag-based) MusicBrainz tag getter to it
  • port and rewrite existing fingerprint-based MusicBrainz tag getter out of ffmpeg + libofa to Phonon + chromaprint (library to compute AcoustIDs) Viability of Phonon for this task needs to be verified
  • create new tag-based tag getter that uses Last.fm web service to get metadata corrections
  • make MusicBrains Tagger use the new framework instead of hard-coding MusicBrainz usage. It will just run the invidual getters in parallel (using some kind of Tag Getter Controller) and display the results along with their source and score. Note that there is a pending review request dealing with MusicBrainz tagging and the dialog
  • (bonus point) create new tag getter using the Last.fm Fingerprinter

Expected results: Getting tags from MusicBrainz will work the same, albeit with a better UI, using Last.fm to correct tags will get implemented and adding new tag guessers will be just a matter of implementing a documented abstract base class.

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers), understanding how Web Services work

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Revamping Amarok Scripting Interface

Brief explanation: Since version 2.0 Amarok features a new QtScript Scripting Interface that allows to extend its functionality. Developers and power users have created and published hundreds of scripts to kde-apps.org. On the other hand, the interface is not unit-tested, is documented only manually on wiki, allows dangerous direct SQL access to the database and doesn't feature access to new Amarok functionality that has been meanwhile added. This project would fix those shortcomings, make Amarok Scripting Interface shine again and promote its usage.

Expected results:

  • existing scripting API is reviewed, dangerous/unused/obsolete (research of existing scripts needed) methods are deprecated and new interfaces are added (SavedPlaylists and playlist object, CollectionManager and more generic collection object, query for tracks using CollectionBrowser-like queries...)
  • scripting interface objects & methods are documented in-source and an automatic way of generating scripting API documentation (to replace manual wiki page) is created
  • the scripting interfaces are unit-tested within Amarok testing framework using dedicated scripts

Knowledge Prerequisite: C++, Qt, JavaScript, C++ <-> QtScript binding

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

Project: Unified CUE File and Audiobook Chapter Support in Amarok

Brief explanation: Amarok has been long able to support so-called cue-sheeted music (an entire album is in a single audio file accompanied by a "cue" file that lists track times and name), however that much-requested (Bug #187587) support was never complete. Lately there have been another request for Amarok to support navigation in MP4 audiobooks that embed chapter information. Because both are in principle the same (just the way to read parts info is different), this project's goal is to implement support for both of these using common code in Local Collection and in other places.

Expected results:

  • CUE-sheeted music as well as chapter-enabled audiobooks are displayed as individual tracks/parts in the Local Collection, when dragged to playlist etc. (bonus point: also in UmsCollection)
  • TagLib is extended to support reading chapter metadata from audiobooks
  • code for different collections/places and types of "part" metadata is not needlessly duplicated
  • cuesheeted playback is retested and possible glitches fixed (Amarok already does it to some extent)

Knowledge Prerequisite: C++, Qt, understanding multithreading, memory management (stack vs. heap allocation, smart pointers), SQL

Mentor: The Amarok Team, [email protected], #amarok on Freenode IRC, see Amarok/Development/Join

digiKam

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

Project: Tags Manager

Brief explanation: Moving tags around in the small tags views from right or left digiKam sidebar can be fastidious, especially with a huge collection of items. A new dedicated windows must be created to manage all tags and relevant properties hosted by digiKam database. This tool must support drag and drop, multiple selections, copy/move operations, properties edition and duplication.

Dependencies: : digiKam core implementation

Bugzilla entries: 263299

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

Expected results: new window to edit and manage all digiKam tags

Difficulty: medium

Lead Mentor: Smit Metha <smit dot meh at gmail dot com>

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

Project: HDR Composer

Brief explanation: digiKam already include a tool to make pseudo HDR image through ExpoBlending tool, based on align_image_stack program from Hugin project and Enfuse command line tool. ExpoBlendin is limited to improve a litlle bit exposure latitude of images. It has creativity limitations and cannot reproduce nice HDR images, as LuminanceHDR can do. The goal of this project is to extend current ExpoBlending tool to add new advanced HDR worklflow or create a new one, depending of complexity . Also, some GUI improvement need to be done to be able to process more that on set of bracketing shots at the same time.

Bugzilla entries: 275364, 273254

Dependencies: ExpoBlending tool or a new tool to design from scratch

Knowledge Prerequisite: C/C++, Qt, Imagery, math

Expected results: new tool to perform high quality HDR composing as items visible in this Google+ group.

Difficulty: high

Lead Mentor: Janardhan Reddy <annapareddyjanardhanreddy at gmail dot com>

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

Project: Cloud Integration Export Plugin

Brief explanation: Creating a kipi export plugin for putting the pictures on cloud storage devices like Google Drive, DropBox, Skydrive, etc. Depends on the availability of an open source API. For any cloud storage facility, there are two possibilities, either they give an API in a common programming language, which is freely distributed and is easily implementable in our codebase. Or someone else than the service provider has created an open source API. You should be able to see some examples on github or sourceforge. Some service providers want only their API to be used, some dont mind other tool accessing the cloud using OAuth, etc. The student is expected to go through both the options for a particular cloud storage, identify the solution which is best suitable for already existing kipi-plugins framework, i.e. C++ / Qt, and implement it over the summer for atleast two major cloud services Google Drive and Dropbox.

Bugzilla entries: 300445

Dependencies: APIs from G+, Dropbox, Skydrive tool

Knowledge Prerequisite: C/C++, Qt

Expected results: new tool to import/export items to Cloud web service

Difficulty: easy / medium

Lead Mentor: Smit Mehta <smit dot meh at gmail dot com>

Alternative Mentor: ???

Project: Port Showfoto thumb-bar to Qt model/view

Brief explanation: ThumbBarView is a Qt3Support class based on Q3ScrollView class which will disappear with next Qt5. This class still only used by Showfoto editor. It must be ported to Qt model/view implementation using already existing common classes used in digiKam core.

Dependencies: digiKam core, Qt model view

Knowledge Prerequisite: C/C++, Qt, model/view

Expected results: implement Showfoto thumb-bar to model/view

Difficulty: medium

Bugzilla entries: 296654

Lead Mentor: Islam Wazery <wazery at ubuntu dot com>

Alternative Mentor: ???

Project: Port image editor Canvas classes to Qt model/view

Brief explanation: Image Editor canvas classes are Qt3Support classes based on Q3ScrollView which will disappear with next Qt5. This class is used by digiKam Image editor to render lead editor canvas and some tools canvas as ColorCorrection, CurvesAdjust, LevelAdjust, etc. It must be ported to Qt4 model/view implementation using already existing common classes used in digiKam core.

Dependencies: digiKam core, Image Editor, Qt model view

Knowledge Prerequisite: C/C++, Qt, model/view

Expected results: implement image editor canvas to model/view

Difficulty: high

Lead Mentor: Islam Wazery <wazery at ubuntu dot com>

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

Project: Port Greystoration CImg interface to GMic

Brief explanation: digiKam include CImg library to be able to use Greystoration algorithm which give nice fix to image based on Vortex theory, as 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, Restauration and Inpaint editor tools, and Restauration tool from Batch Queue Manager

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

Expected results: port image restoration algorithm from CImg to GMic API

Difficulty: high

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

Alternative Mentor: ???

Project: Video Metadata Support Improvements

Brief explanation: All recent digital-still camera devices provide video capture. digiKam must be able to manage these files as it do with images, to catalog and sort items (by date, camera name, and all record conditions). Through Exiv2 shared library improvement done at GSoC 2012, digiKam is now able to manage some video metadata from avi, divx, mkv, WebM, mp4, mov, 3gp, wmv, asf, but it lack some important video format metadata as MPEG and VOB used in video workflow. To improve video files support, video metadata management done in background need to be improved, to patch Exiv2 shared library, already used by digiKam to handle metadata.

Bugzilla entries: 164442

Knowledge Prerequisite: C++, Qt, video format, metadata

Expected results: Add missing video files support to Exiv2. Patch digiKam advanced search tool to handle video information.

Difficulty: high

Lead Mentor: Andreas Huggel <ahuggel at gmx dot net>

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

Project: Exiv2 "Cloud Ready" Project

Brief explanation:

Add web protocol support to Exiv2.

Exiv2 is a C++ library and a command line utility to manage image metadata. It provides fast and easy read and write access to the Exif, IPTC and XMP metadata of images in various formats. Exiv2 is available as free software and with a commercial license, and is used in many projects including DigiKam.

This project extends the reach of Exiv2 from the desktop and server to both mobile and the cloud. All Exiv2 clients – including DigiKam will gain from this development.

There are four subprojects:

  • HTTP I/O support (GSoC 2013 Student)
  • exiv2(.exe) to run as a service (daemon) on a web socket.
  • client-side use of the exiv2 service (using the web socket)
  • JSON support

The student is welcome to contribute to any part of the project. However the HTTP I/O Support will be "owned" by the student.

Exiv2 Project Web Site: http://www.exiv2.org

Cloud Ready Specification: http://dev.exiv2.org/projects/exiv2/wiki/GSoC_2013_%22Cloud_Ready%22_Project_Specification

Bugzilla entries: 224923

Knowledge Prerequisites:

  • Essential: C++ on Linux
  • Desirable: Web Technologies. JavaScript, http protocol.
  • Desirable: WebSockets. JSON. Scripting Language (Python or Perl)

Expected results:

  1. To read and write metadata on a web URL (http/ftp/ssh)
  2. Test the implementation using the Exiv2 WebSocket Server
  3. An engineering assessment of providing support for other cloud services such as AWS and Dropbox.

Difficulty: High

Mentor: Robin Mills http://clanmills.com and http://clanmills.com/files/CV.pdf and [email protected] [[1]] [[2]] [[3]]

Robin has been a volunteer with Exiv2 project for 5 years and has provided build support for several platforms, and Visual Studio (MSVC) in particular. Via the Exiv2 Forum, he has provided support for many users wishing to build and integrate Exiv2 technology into their products.

Today, Robin is a freelance contractor in Silicon Valley, California and has recently worked on a mobile app which uses WebSockets. He has worked on client and server code in JavaScript and C++. Robin was a Senior Computer Scientist at Adobe for 10 years, and (among many projects) implemented reading PDF and JDF files over http (without copying the complete file).

Project: Integrate KIPI Export Plugins directly in the GUI of KIPI host applications

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.

Dependencies: : digiKam KIPI interface, libkipi, KIPI Plugins

Bugzilla entries: 235572, 221704 ,143978

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

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.

Difficulty: high

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

Alternative Mentor: ???

Calligra Words

Project: Implement Change Tracking Backend

Brief explanation: Implement the change tracking backend (load,save,record, reject, accept). Implementing Ui and visualizing is _not_ part of the project.

Expected results: Fully working changetracking engine as far as the ODF 1.3 standard has evolved (which by now (feb.2013) is just insert and delete characters, but it will grow in scope). We also expect that you contribute to the development of the standard with feedback and suggestions. There needs to be documentation and unit tests as well.

Knowledge Prerequisite: C++, Qt, basic understanding of Operatonal Transform, basic understanding of the ODF spec, Well versed in the Calligra codebase with proven commitment

Mentor: Camilla Boemann you can calso contact us on irc #calligra

Project: Implement Change Tracking User Interface

Brief explanation: Implement the change tracking user interface (visualize changes, buttons). Implementing the backend is _not_ part of the project. A lot of the work will be to work together with the student getting the backend project

Expected results: Fully working changetracking user interface built on top of the backend. It needs to be completely polished with all details taken under consideration.

Knowledge Prerequisite: C++, Qt, usabillity and interaction design experience. Well versed in the Calligra codebase with proven commitment

Mentor: Camilla Boemann you can calso contact us on irc #calligra

Nepomuk

Project: A "real" query parser and Query Builder Widget

Brief explanation: Nepomuk has a query parser which is used to handle input from the user in such situations as the KRunner interface or the Dolphin search bar. Currently this parser is one big HACK and in dire need of reimplementation.

In addition we have no dedicated widget for query input which provides good auto-completion. The idea is fancy auto-completion in the search line-edit that proposes types, properties, and other resources. It should take usage frequency of properties, types, and property values into account (when that does not mean too big a performance downer). It could even try to use some built-in thesaurus allowing to match "nfo:Audio" from "audio", "music", "song", and others.

Expected results: A desktop query parser which is based on an actual grammar including support for nested terms (important when it comes to querying a graph), quotes (used to group keywords into one search term), resource URIs (it should be able to detect that a string is a resource URI and not a full text search term), namespace abbreviations ("nao:hasTag" should match exactly the one property while "hastag" can match multiple properties), as well as property and type expansion (this means that in "hastag:xyz" "hastag" should be expanded to an actual property URI.)

The query parser should support the syntax supported by the current query parser and build upon that. One could think of extensions like mapping localized terms like "today" or "yesterday" to QDate or QDateTime values (depending on the range of the queried property), excluding unused properties altogether, supporting a deeper nesting of query terms like "author:(related:(hastag:nepomuk))", and so on.

This parser should be used to implement auto-completion in a line-edit. Ideally this auto-completion would work well (only propose used properties, give preference to type, and so on) and look good (give multiple propositions in one widget, maybe with a result count). Examples include a simple expansion of "hastag:" to existing tags (sorted by use and not the complete list) or an expansion of "music" to "Query all music files" (ie. giving an explanation of query terms in the completion widget.

Knowledge Prerequisite: Previous experience with a parser generator would be good but is not required. A bit of Qt experience would be nice but again, is not required.

Mentor: Vishesh Handa <[email protected]>

KDE Telepathy

Project: Add ConnectionManager bindings to send SMS' using QtModemManager

Brief explanation: KDE Telepathy, the IM client, uses the backend library TelepathyQt to power everything. This library is also used by Nokia N9's, and soon Ubuntu's phones and much more.

The system consists of two parts; clients which display things to the user and connection managers which do the talking to the various IM servers.

ModemManager has bindings for talking to a mobile network but no UI on top. By making it act as a telepathy connection manager we will be able to send/retrieve SMS messages in KTP.

This project is the same as [4], and is a partnership with the solid and KTp team.

Expected results: At the end of the summer we should have a completely working connection manager showing SIM card contacts and being able to retrieve send SMS messages.

Knowledge Prerequisite: Qt, and ideally usage of TelepathyQt already.

Mentor: KTp GSOC ML Group

Project: Collaborative text editor powered by Telepathy Tubes

Brief explanation: With Telepathy we can set up P2P DBus session between two contacts without the difficulty of servers and firewalls and low level TCP details. It would be great to use this to create a collaborative text editor that can be used for writing documents, or code.

What I expect to see in your proposal: Knowledge of collaborative text editors, and the main difficulty analysed. I expect to see what libraries you can re-use and a detailed list of what needs to be created.

Expected results: A working telepathy powered collaborative real-time text editor.

Knowledge Prerequisite: Qt, C++, Dbus, Telepathy

Mentor: KTp GSOC ML Group

Project: Finish KTp-Active

Brief explanation: KTp Active is our touch screen version of KDE Telepathy primarily for Plasma Active touch devices. It was started, but needs a lot to be release-able. Please read https://projects.kde.org/projects/playground/network/telepathy/ktp-active) and (http://www.blog.mentero.net/kde/ktp-active/bringing-ktp-active-to-life/

What I expect to see in your proposal: Knowledge of the current state of ktp-active, and a list of everything that doesn't work, and a plan of what needs doing

Expected results: A working tablet IM client that we can release as part of Plasma Active

Knowledge Prerequisite: Qt, C++, advanced QML

Mentor: KTp GSOC ML Group

Marble

Project: Marble meets owncloud

Brief explanation: Marble wants to be your swiss army knife for maps, owncloud brings your data under your control. Let's marry the two and bring cloud storage advantages to Marble without the usual loss of control: Enable Marble to store important data in owncloud and make it accessible (sync) to all Marble versions running on your desktop, laptop, smartphone.

Expected results:

  • Marble: Sync bookmarks (and routing targets) with owncloud
  • Marble: Save routes to owncloud, load routes from owncloud
  • owncloud: View Marble bookmarks and routes on top of leaflet
  • owncloud: Manage bookmarks and routes (view as list, delete)

And some possible extensions:

  • workout mode: save tracks from jogging and other activities to owncloud
  • track sharing: record your favorite bike, motorcycle, hike track along with pictures from your smartphone and share via kml and owncloud

Knowledge Prerequisite: Qt, C++, Javascript

Mentor: earthwings at gentoo dot org

Project: Marble KML Map Editor

Brief explanation: Marble can display map data from various sources and file formats. An important file format is KML: It's an open standard that has been popularized by Google Earth and internally Marble's class design is modelled after KML. Now wouldn't it be great if the user could also edit KML files using Marble? What would a swiss army knife for maps be without an editor mode? This would also provide the foundation for a future OSM editing mode: Internally all file formats (like OSM) get handled as a KML document. So the work on a KML edit mode would also automatically allow for editing OSM, GPX and Shapefile documents in a very basic way.

Expected results:

  • Add a framework to save to different file formats
  • Improve Layer handling (placemark and geometry)
  • Improve KML support (possible example: GroundOverlays which are currently only supported partially)

Knowledge Prerequisite: Qt, C++, Javascript

Mentor: earthwings at gentoo dot org , rahn at kde dot org

Project: OpenGL-Scenegraph for Marble

Brief explanation: For awesome visual results - even on low-powered devices such as tablets and smartphones - Marble could benefit greatly from using modern OpenGL. However, spreading OpenGL code all over Marble's source code (and forcing plugin writers to switch to OpenGL) is no option for various reasons. A much smarter way is to introduce a scenegraph, where data (e.g. Marble::GeoDataLineString, Marble::BillboardGraphicsItem) that is to be visible is first added to a tree (the scene), and rendered afterwards. Since this approach decouples data and rendering, OpenGL code can be centralized in one place and e.g. plugin writers don't have to use OpenGL directly. In addition, the data inside the tree can be preprocessed and stored on the GPU, allowing for great performance improvements using modern OpenGL.

The task is to create such a scenegraph. It shall allow to group related data together in order to process this data in a batch manner (e.g. rendering or adding to/from the tree). Grouping is the key to high performance. Inspiration can be taken from OpenSceneGraph and Qt3D.

Expected results:

  • Scenegraph which allows to group related data
  • Scenegraph that "knows" how to render Marble's primitives, such as Marble::GeoDataLineString, Marble::BillboardGraphicsItem
  • Some key plugins should be ported to use the scenegraph for demonstrating its feasibility.

Knowledge Prerequisite: Qt, Marble::GeoPainter internals and Modern OpenGL when GSoC 2013 begins

Mentor: marble-devel at kde dot org

KStars

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

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: Rishab Arora <[email protected]> (spacetime), Akarsh Simha <[email protected]> (kstar)

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 2013.

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: Rishab Arora <[email protected]> (spacetime), Akarsh Simha <[email protected]> (kstar)

Krita

Krita is a large and complex application. This year's project proposals are all heavy-weight and not suitable for someone who still needs to learn C++ and Qt. We also expect people to fix bugs and start working on Krita code before the summer of code starts. You need to prove that you can find your way around Krita's codebase and that you can code! Contact boud on #krita for more information. Note that these are just suggestions: your own ideas are very welcome!

For Krita projects, contact: Boudewijn Rempt ([email protected])

Project: Rewrite the OpenGL canvas mode

Currently, the OpenGL canvas uses outdated api's and doesn't work on Windows. We need a more modern approach, using the OpenGL 2ES subset to be compatilbe with mobile environments, as well as direct integration of OpenColorIO. There are a couple of issues to keep under consideration:

  • integration with both lcms2 and opencolorio color correction
  • support for monitors that do 10 bits/channel or higher
  • efficient updating the textures that represent the image
  • rotation, zoom, pan and image quality
  • cross-platform: must work on Windows
  • integration with tools that show decorations
  • integration with 3D models that can be loaded as painting assistants
  • performance: the current canvas limits the rate at which input events can be handled to the display update rate

You need good knowledge of OpenGL for this project, in addition to C++, Qt and a good grounding in multi-threading.

Project: Painting and Separation of 3D Textures

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.

Project: Animation Support

Animation is a hot topic among Krita users. Working together with professional animators in our community, you will design and implement the features necessary to use Krita in film, storyboarding, animation and games.

This involves implementing:

  • A new file format for animations based on Krita's native file format.
  • A timeline interface for quickly navigating and managing frames on multiple layers.
  • Rendering, exporting and importing of frames.

A strong foundation is needed as we hope to expose Krita's existing features to use in animation, as well as allow the creation of animation-specific functions like onion-skinning. The functionality we're hoping to support by doing this has been sorely needed by the open source community for many years, this extends to a wide variety of use cases with no sufficient alternatives available.

Game artists need it to animate sprites, film producers need it to do effects and touchups, animators need it not only for 2D productions but 3D as well, and all of them need it to produce storyboards and animatics to plan their projects. The features you develop will be put into immediate use in many of these areas.

Project: 3D Material Image Maps

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:

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

Project: Matte painting

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:

  • 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

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.

Calligra Plugin

Calligra is an office suite with lots of different applications with an user interface that is easy to use, highly customizable and extensible.

[5] - Mailinglist - IRC channel: #calligra on Freenode.

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 >

Gluon

Project: Make the Create > Play > Discuss workflow work

Brief explanation: Gluon is a project that aims to deliver a complete framework for creating and playing videogames. Gluon comes in mind with a predefined game-production-path that takes care of creating, distributing and playing games. This path isn't still working even if most of the tools are already there. Currently the project has: the Gluon creator which effectively takes care of creating the game from scratch. Creator has the ability to connect to an OCS server (thanks to libAttica) for publishing games online. Gluon has also an OCS server, as a result of a past GSoC project. Unfortunatly Gluon Creator and the OCS server still can't communicate. Same for the Gluon Player, the application that plays videogames, but not only. It's more of a complete interface for the remote OCS server, storing all the games, comments etc... letting the user interact with data. My idea consists mainly into 2 parts: make every piece of this puzzle work together and redesign all the Gluon Player, porting it to QML. It's very important for Gluon to have a starting point to build a community made also by players, and this can achieved only giving players and developers the right tools to use.

Expected results:

  • A complete redesign of the Gluon Player to work on QML, assuring it will work with the official website & OCS server.
  • Fixes and updated to the OCS server, in order to work with Gluon Player and Gluon Creator.
  • Gluon Creator fixes if needed in order to make it work with the OCS server.

Knowledge Prerequisite: C++, QML, php, OCS

Mentor: Arjen Hiemstra

Kexi

Project: Improve stability and packaging of the MS Access driver

Brief explanation: Current mdbtools sources included with Kexi for MS Access support are long outdated. Importing an mdb on a 64bit machine, crashes Kexi. Mdbtools sources should not be in Kexi, so that they can be updated separately. Mdbtools project is back on the run, and the user should be able to use the installed libraries. Trying to get people to move to Kexi from Access at some point, means the should be able to move their existing data/design also. This wish has been filed at https://bugs.kde.org/show_bug.cgi?id=277583.

Expected results:

  • Use the newest mdbtools code from https://github.com/brianb/mdbtools and merge patches made by the Kexi project.
  • Provide the patches upstream for the mdbtools project, which would improve packaging.
  • Prepare Kexi buildsystem and/or code to switch to the original mdbtools package.
  • Update instructions for the packagers
  • Propose, publish early research in the student application, design and implement three or more extra features for MDB importing. Without fulfilling this requirement the task will not be considered as done.

Knowledge Prerequisite: C, basic C++

Mentor: Jarosław Staniek (staniek at kde.org)

Project: Add support of Mail Merge to Calligra

Brief explanation: Mail merge is a software function describing the production of multiple (and potentially large numbers of) documents from a single template form and a structured data source. The objective is to add support of Mail Merge feature to Calligra. At technical level, this task is closely related to both Kexi and Words.

More information at http://community.kde.org/Kexi/Integration/Mail_Merge.

Expected results:

  • The Mail Merge feature should be functional in Calligra and visible in Words application with some optional visibility in Kexi.


Knowledge Prerequisite: Qt, C++ (some ODF and database knowledge will be a plus)

Mentor: Jarosław Staniek (Kexi maintainer, staniek at kde.org), Camilla Boemann (Words maintainer, cbr @ boemann.dk)

KDE Workspaces

Project: Port plasmoids to plasma2

Brief explanation: The plasma workspace is being rewritten on top of Qt5, Frameworks5 and Qml2. Some plasmoids are still in C++, some are already ported to QML1 (some to pure QML some mixed QML and C++). Some work will be needed both to port old c++ plasmoids (needing a complete rewrite) or QML1 plasmoids, that will need adaption in the parts where the plasma api changed.

Expected results: Production/port of at least 3-4 plasmoids loading and all their features working on the plasma2 shell prototype.

Knowledge Prerequisite: Good knowledge of QML, basic knowledge of C++ and some experience Qt programming

Mentor: Marco Martin <[email protected]>

Project: load plasmoids in the QML lock screen

Brief explanation: Since KDE Plasma Workspaces 4.10, the old lock screen and screen saver have been migrated to a fully customizable QML implementation. It is also present an alternative lock screen that can load plasmoids. The two should be merged, having the normal QML lockscreen with the possibility to load plasmoids in it, eliminating any duplication in code and in the user interface.

Expected results: a basic infrastructure capable of loading plasmoids into the lock screen

Knowledge Prerequisite: Good knowledge of QML, basic knowledge of C++ and some experience Qt programming

Mentor: Marco Martin or Aaron Seigo

Project: Port kde-workspace applications away from XLib

Brief explanation: In Qt 5 the XLib integration got dropped and (partially) replaced by XCB. The KDE workspaces have a tight integration with X11 and use many of the removed features like for example QPixmap::handle(). Most of these usages can be changed already now in the Qt 4 world which reduces the actual porting overhead. Another important area is the XEvent handling which is no longer possible. For easier porting this should be abstracted as much as possible. A summary of common problems can be found in http://community.kde.org/KWin/Qt5

Expected results: Kde-workspace is free of problematic code.

Knowledge Prerequisite: C++ idioms like RAII should be known. Knowledge about the X11 protocol is a clear plus

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

Project: KWin Effect Viewer

Brief explanation: With 4.9 KWin Effects can be written in JavaScript, but there is no convenient way to test the scripts. In this project a viewer application similar to plasmoidviewer should be developed. This could be achieved by using Xephyr and starting a dedicated KWin instance on the embedded X-Server which is just running the effect.

Expected results: Effect Viewer application to test effects including simulation of all possible Windowing events

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Martin Gräßlin

Project: Present Windows/Desktop Grid rewrite in QML

Brief explanation: Present Windows and Desktop Grid are two KWin effects which could nowadays be better implemented using a QML based KWin Script. From the QML site everything is there except providing KWin's Clients as a model. Part of the project would be to write this model and some filter models to get e.g. Clients for just one desktop and the QML view to be shared between desktop grid and present windows on top of Plasma Components.

Expected results: Present Windows and Desktop Grid rewritten in QML, Model for KWin Clients added

Knowledge Prerequisite: QML, QAbstractItemModel and QSortFilterProxyModel

Mentor: Martin Gräßlin

Project: Improved KWin effects configuration

Brief explanation: Provide a better user interface for managing KWin effects, so that a user can see which effects are mutual exclusive, which work together and which hardware is required for an effect. The module should be written with Qt 5's desktop components for QML. It should be possible to embedd only content to e.g. get a video preview.

Expected results: A new compositing configuration module supporting use cases like "effect for minimizing" and "effect for closing window" should be implemented.

Knowledge prerequisite: QML, usability experience

Mentor: Martin Gräßlin

Project: Integrate Android with the Workspace and vice versa

Brief explanation: Provide a tight integration between the Android platform and our's by making things like Android Notifications be shown in our Workspaces.

Expected results: Android platform should integrate seamlesss with KDE's using some kind of connectivity (p2p if possible and going trhough the cloud when not).

Knowledge prerequisite: Java, C++/Qt

Mentor: Àlex Fiestas

Project: Integrate iOS with the Workspace

Brief explanation: Provide a tight integration between iOS platform and our's by using libimobiledevice

Expected results: Producing a kio_afc, iPhone information (battery, disk usage, phone number...), backup and restore devices...

Prerequisite: Owning an iOS device

Knowledge prerequisite: C/C++/Qt

Mentor: Àlex Fiestas

Project: Polish KDE for netbooks

Brief explanation: Improve netbook user experience.

1. Netbooks are usually used w/o mouse, thus as many common actions as possible should be triggable via keyboard, and amount of them can be reduced. For example what is the sequence of actions for launching some application in KDE 4.10? Alt+F2 doesnt work, so user has to click on 'Search and launch', then click on search field (it is not focused by default!), then type the name of application (Gnome does this better, see kde bug 315136, and generally search bugs.kde.org for 'netbook').

2. Netbooks have slow CPUs and not so much memory. A special profile should be automatically activated for plasma-netbook: disable nepomuk, use sqlite for akonadi (+interaction with distro packagers); reduce amount of applets ran, especially python ones; activate printer support only when user explicitly asks for it. Also KDE has memory leaks which make running it for more than ~5 hours impossible. So at some point instead of hibernating it one has to really shut it down. proof screenshot. A good task for student is to find and eliminate the leaks.

3. Polish KDE behaviour for the case of frequent suspend/resume: update clock immediately on resume, check if power source was attached/detached during sleep and so on. Any possible improvements for the case of attaching/detaching external monitor/projector (reduce amount of manual configuration actions)

4. Conduct usability study: where KDE newbies expect to find configuration options for plasma-netbook appearance, and such. Suggest solution and implement it (if agreed with community)

Expected results: This is a high-level overview task, a concrete list of minimum and maximum results should be prepared by the student.

Knowledge prerequisite: C++/Qt, C, plasma/kdelibs, kubuntu; software integration/packaging and usability is a big plus. a student should have a powerful machine to run devtools fast enough ;)

Mentor: Nick Shaforostoff (find me on a facebook or g+) or a plasma/kdelibs developer

KDE Games

About KDE games: http://games.kde.org/

Project: Port a KDE game to QtQuick/QML

Brief explanation: QtQuick is the new (well not so new anymore) library for creating user interfaces very quickly with the easy-to-code Qt's declarative language QML. All of our games use the legacy C++ QGraphicsView library to paint the game frontend, aka, the canvas (except KBreakout and few others in the works). Writing UIs in QML is much easier and simpler than the QGraphicsView counterpart. This project is about porting the game canvas of any one of the existing games to QtQuick, keeping the backend code as intact as possible.

Expected results: Port one game completely to QtQuick to display the game canvas using QML. Additional animations over and above that in the original game would be a plus, since QtQuick provides rich and easy-to-use animation capabilities.

Knowledge Prerequisite: Good knowledge of QML, basic knowledge of C++ and some experience with Qt programming.

Mentor: Viranch Mehta <[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: Add support for secure messaging to Trojitá

Brief explanation: It would be cool to have support for encrypted and signed messages, both with GnuPG and S/MIME (X.509). The 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á.

Expected results: Add support for creating, reading and verifying the GnuPG and X.509-wrapped messages.

Knowledge Prerequisites: Decent knowledge of C++ programming, familiarity with Qt, willingness to use GPG.

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

Project: Android version of Trojitá

Brief explanation: The primary platform which sees most development and takes most attention is the regular desktop, but there is an existing port to MeeGo Harmattan with some limited functionality. This project is about porting that to Andorid and extending the functionality so that the features offered by the mobile port make it possible to effectively work with e-mail on that platform.

Expected results: An Andorid version of Trojitá (with Harmattan backports, if feasible) supporting other features already found in the desktop version -- composing and sending e-mails, searching them, filtering, threading etc.

Knowledge Prerequisities: Candidates shall be fluent in QML and have some Qt/C++ experience.

Project: Integrating Trojitá with KDE's Kontact

Brief explanation: Trojitá a pure Qt application with no KDE dependency. It would be great to add optional integration with the KDE's PIM tools, so that it will work as a part of the Kontact suite, be able to read the KDE's addresbook etc.

Expected results: Make a variant of Trojita which will act as a drop-in replacement for KMail (at least from the user's point of view).

Knowledge Prerequisities: Decent knowledge of C++ programming, familiarity with Qt, lack of alergy towards KDE's classes.

KDENetwork

Project: Improve Krfb

Brief explanation: Krfb is the KDE VNC (desktop sharing) server application. It is part of the KDENetwork module and its codebase lives in svn.

Krfb's UI consists of a systray icon and a simple dialog for inviting people to see your desktop. To invite someone, Krfb generates a random password and starts listening to a random port, then it gives this information to the user, who is responsible for sending this information to the other person.

Apart from this simple invitation-password-based model, krfb also supports desktop sharing over telepathy tubes. Unfortunately, krfb itself has no UI for sharing the desktop with one of the user's contacts. To use this feature, the user needs to use the KDE Telepathy contact list.

The VNC implementation behind the scenes is functional, but not perfect.

The whole application could use some love in various areas. Improving the UI, for example, could be one. Telepathy contacts could be shown in krfb's main UI, for example. Another example is adding support for a non-invitation-based models. X11VNC options are a good example of what could be supported... Improving the backend, fixing bugs, etc, could be another one.

Expected results: Make krfb a first-class citizen in KDE.

This is just an idea and not a ready proposal. If you are interested in desktop sharing, have a look at krfb and come up with some cool ideas that could achieve this goal.

Knowledge Prerequisite: Qt, experience with desktop sharing. Related knowledge (telepathy, vnc/libvncserver, Xlib) is a plus, but not required.

Mentor: [email protected]

Solid

Solid is the KDE sub-community of everything related to Hardware support.

Website - Mailing list - IRC channel: #solid on Freenode.

Project: Improve Plasma NetworkManagement's information details panel

Brief explanation: Plasma NetworkManagement (Plasma NM for short) is the software used to manage network connections in KDE. One of its feature is a panel that shows information about one of the current activated connections, information like IPv4 address, wifi channel, card driver, etc. Panel needs improvements like:

To manage mobile connections, such as gsm, Plasma NM uses ModemManager through dbus. Actually, Plasma NM does not talk to ModemManager directly, it uses a wrapper library (libmm-qt) to do that. The interface exposed by ModemManager has changed, then libmm-qt must be updated to reflect that and to allow Plasma NM to get the connection's details it needs to fill in the details panel for mobile connections. It will be very usefull to create unit tests for libmm-qt too.

The IPv6 connection details are already in NetworkManager, we just need to update the panel to get and show them. The VPN details are more complicated to get. The student that creates a QML version of the information details panel gets a bonus :-)

Expected results: libmm-qt and Plasma NM are able to talk to newer versions of ModemManager (>= 0.7), Plasma NM can show connection details for IPv6 and VPN connections.

Knowledge Prerequisite: C++/Qt (specially meta objects), dbus, computer network and API development.

Mentor: Lamarque V. Souza <[email protected]>

Project: Send SMS using ModemManagerQt

Brief explanation: Mobile devices (gsm and cdma) are capable of sending/receiving Short Message Service (SMS) messages. ModemManager is a non-GUI software used in Linux to manage 3G modems and cell phones capable of working as modems (I think all cell phones are nowadays). ModemManager already supports the low level part of sending/receiving SMS messages, this project means to improving Solid's Qt bindings for ModemManager (known as ModemManagerQt or libmm-qt) and to implement a GUI for reading, typing and sending SMS.

After some discussions with KTp guys we realised that it makes sense to implement the GUI for sending/typing SMS in KDE Telepathy. Most contacts in Telepathy already contains a cell phone number, ModemManager can be used to manage contacts stored in sim card and in the cell phone itself, then this is a good way to keep everything easy for KDE users.

Currently ModemManagerQt supports old SMS API only (ModemManager <= 0.5), which has has never been tested too due to lack of working 3G modem by the time the it was created. Implementing unit tests for ModemManagerQt API is also an important goal.

Expected results: ModemManagerQt is able to talk to newer versions of ModemManager (>= 0.7), KTp can send/receive/show SMS messages and new unit tests in ModemManagerQt.

Knowledge Prerequisite: C++/Qt, dbus, computer network and API development.

Mentor: Lamarque V. Souza <[email protected]>

Simon

Simon is a speech recognition suite.

Blog - Mailing list - IRC channel: #kde-accessibility 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 <me {+at+} bedahr.org>

Jovie

Project: Jovie on Plasma Active

Brief explanation: Jovie is a basic wrapper around speech dispatcher for KDE, Making it usable on Plasma Active would go a long ways towards making Plasma Active more accessible.

Expected results: Jovie packaged and running on Plasma Active with a touch friendly UI for customization. Possibly also a touch friendly application to allow easy invoking of speech (Touch friendly port of kmouth maybe?)

Knowledge Prerequisite: C++/Qt

Mentor: Jeremy Whiting <jpwhiting {+at+} kde.org>


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 IM with keyboard layout configraiton

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.

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

Knowledge Prerequisite: C++ and Qt

Mentor: Andriy Rysin <[email protected]>


Project: Provide "in-line" keyboard layout indicator

Brief explanation: Currently when user has multiple keyboard layouts and types in some text he often must look at the tray icon to tell which layout is current. With multiple windows opened for different tasks that use different languages this may be quite a burden to what the tray for layout. Also sometimes the task bar is minimized adding more burden on the user. Often user will start typing and then realize the wrong layout is selected. It would be much nicer if text input cursor (AKA caret) would display current layout - this way when user fixes his eyes on the text field he'll be typing in he can tell right away which layout is active. This can be as simple as color or the caret or more complex, like a flag, or layout label.

Expected results: New option to indicate current keyboard layout with text input cursor. Potential solutions: configuring color of the caret for each layout; allowing flag or label to appear on the caret. Note: this display should not be intrusive so it may need to be of small size, semi-transparent etc.

Knowledge Prerequisite: C++ and Qt

Mentor: Andriy Rysin <[email protected]>


Project: Automatic layout switching based on text input context

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

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

Knowledge Prerequisite: C++ and Qt.

Mentor: Andriy Rysin <[email protected]>

KDevelop

Project: Ruby Language Support for KDevelop

Brief explanation: You'll be improving Ruby Language support for KDevelop. The ultimate goal is to release 1.0 version of the plugin. You should determine/set specific subgoals yourself.

Expected results: Ideally, you are already coding in Ruby and you know what you miss in the IDE. Alternatively, Alexander Dymo has a large ruby on rails project, he will help you identify weak parts of the language support.

Knowledge prerequisite: C++, Qt, KDE libs, KDevPlatform API

Other requirements: KDevelop language support is a very complicated piece of software. The project will require a lot of dedication and hard work. And you also need to demonstrate your ability before the project is accepted. If you're not KDevelop developer, you should have a couple of patches to ruby language support submitted and applied before the GSoC review period ends (May, 22th). This way we'll know you can do the job.

Mentors: Alexander Dymo <[email protected]>, adymo on IRC (freenode) or Miquel Sabaté <[email protected]>, msola on IRC (freenode)

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