GSoC/2011/Ideas: Difference between revisions

From KDE Community Wiki
< GSoC‎ | 2011
m (move calligra apps karbon and krita to the calligra section)
Line 286: Line 286:


[http://www.calligra-suite.org/ Web] -  [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.
[http://www.calligra-suite.org/ Web] -  [https://mail.kde.org/mailman/listinfo/calligra-devel Mailinglist] - IRC channel: #calligra on Freenode.
==== Karbon ====
'''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 modify the path a tool that, 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 Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.
'''Expected results:'''
Modify path tool is able to scale 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.
'''Technologies Used:'''
C++,Qt,SVG?
'''Mentor:'''
Jan H? jaham @t gmx,net (need to ask :P )


==== Words: Improve quality of ODF write support ====
==== Words: Improve quality of ODF write support ====
Line 343: Line 360:
'''Mentor:'''
'''Mentor:'''
Casper Boemann, please contact [email protected]
Casper Boemann, please contact [email protected]
=== Krita  ===
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/
Project Page: http://www.krita.org/
Irc channel: #krita on irc.freenode.net
Forums: http://forum.kde.org/viewforum.php?f=136.
Wiki: http://community.kde.org/Krita
==== Krita: ABR Brush Support ====
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.
'''Mentor''':  Lukáš Tvrdý
'''Used technologies''': C++, Qt
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita
==== Krita: PSD File import/export Support ====
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt,
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd
==== Krita: Flow and drying: real media support ====
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects.  Particularly challenging is the flow of undo and redo.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven
==== Krita: 3D Sketching tool ====
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup
'''Mentor''':  Lukáš Tvrdý or Cyrille Berger
'''Used technologies''': C++, Qt,
==== Krita: Text Balloon support for Comics work ====
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt, SVG
'''Expected results''':  a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon
==== Krita: Painting and Separation of 3D Textures ====
'''Brief Explanation''': 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.
'''Mentor''':  Lukáš Tvrdý
'''Used technologies''': C++, Qt
'''Resources''': http://www.krita.org
==== Krita: Advanced selection using SIOX ====
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.
'''Possible mentor''': Cyrille Berger  (or Sven Langkamp)
'''Used Technologies''': C++, Qt
'''Resources:'''
* http://www.siox.org/ website describing the algorithm,
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction
==== Krita: Tagging and management for Krita resources ====
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.
'''Expected results''': A functioning implementation of resource management and tagging.
'''Used Technologies''': C++, Qt, digital art.
'''Mentor''': Boudewijn Rempt
==== Krita: GPU-acceleration for Krita ====
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support,  Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.
Expected results: optimized composition operators, transformation code
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding
'''Mentor''':  Lukáš Tvrdý
==== Krita: GPU-backend for OpenGTL ====
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.
There are two possibilities to implement such a change:
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.
This is a very challenging task!
'''Resources''': http://www.opengtl.org
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)
'''Mentor''': Cyrille Berger
==== Krita: Substrate simulation ====
'''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.
Expected results: an optional substrate simulation that works with all current Krita tools
'''Used Technologies''': C++, Qt, OpenGL
'''Mentor''': Boudewijn Rempt
==== Krita: Color Mixing ====
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.
'''Expected results''': a color mixer that works, layer composition and painting.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt
==== Krita: 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:
1. 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.
2. 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.
3. 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.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt
==== Krita: Shift drag sensors ====
Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt


=== KDE on Windows  ===
=== KDE on Windows  ===
Line 482: Line 673:


'''Mentor:'''
'''Mentor:'''
=== Karbon ===
'''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 modify the path a tool that, 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 Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.
'''Expected results:'''
Modify path tool is able to scale 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.
'''Technologies Used:'''
C++,QT,SVG?
'''Mentor:'''
Jan H? jaham @t gmx,net (need to ask :P )


=== Kate  ===
=== Kate  ===
Line 549: Line 723:


'''Mentor:'''
'''Mentor:'''
=== Krita  ===
Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.
Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/
Project Page: http://www.krita.org/
Irc channel: #krita on irc.freenode.net
Forums: http://forum.kde.org/viewforum.php?f=136.
Wiki: http://community.kde.org/Krita
==== Project: ABR Brush Support ====
'''Brief Explanation''': Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.
'''Mentor''':  Lukáš Tvrdý
'''Used technologies''': C++, Qt
'''Resource''': http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita
==== Project: PSD File import/export Support ====
'''Brief Explanation''': The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt,
'''Resources''': existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd
==== Project: Flow and drying: real media support ====
'''Brief Explanation''': As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects.  Particularly challenging is the flow of undo and redo.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt
'''Resources''': http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven
==== Project: 3D Sketching tool ====
'''Brief Explanation''': When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup
'''Mentor''':  Lukáš Tvrdý or Cyrille Berger
'''Used technologies''': C++, Qt,
==== Project: Text Balloon support for Comics work ====
'''Brief Explanation''': Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.
'''Mentor''': Boudewijn Rempt
'''Used technologies''': C++, Qt, SVG
'''Expected results''':  a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.
'''Resources''': http://en.wikipedia.org/wiki/Speech_balloon
==== Project: Painting and Separation of 3D Textures ====
'''Brief Explanation''': 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.
'''Mentor''':  Lukáš Tvrdý
'''Used technologies''': C++, Qt
'''Resources''': http://www.krita.org
==== Project: Advanced selection using SIOX ====
'''Brief explanation''': SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.
'''Possible mentor''': Cyrille Berger  (or Sven Langkamp)
'''Used Technologies''': C++, Qt
'''Resources:'''
* http://www.siox.org/ website describing the algorithm,
* https://bugs.kde.org/show_bug.cgi?id=110617 tracking of the wish list on our bug reporting tool,
* http://websvn.kde.org/branches/koffice/1.6/koffice/krita/plugins/tools/tool_siox/?pathrev=579976 code to a first attempt at implementing SIOX into Krita,
* http://en.wikipedia.org/wiki/Simple_Interactive_Object_Extraction
==== Project: Tagging and management for Krita resources ====
'''Brief explanation''': Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.
'''Expected results''': A functioning implementation of resource management and tagging.
'''Used Technologies''': C++, Qt, digital art.
'''Mentor''': Boudewijn Rempt
==== Project: GPU-acceleration for Krita ====
'''Brief explanation''': Although Krita was one of the first painting applications with OpenGL and shader support,  Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming.
Expected results: optimized composition operators, transformation code
Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding
'''Mentor''':  Lukáš Tvrdý
==== Project: GPU-backend for OpenGTL ====
'''Brief explanation''': Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements.
There are two possibilities to implement such a change:
* Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend
* The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library
The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.
This is a very challenging task!
'''Resources''': http://www.opengtl.org
'''Expected results''': OpenCL AST generator, report on the possibility to interface OpenGTL with mesa
'''Used Technologies''': C++, GLSL, OpenCL (possibly LLVM)
'''Mentor''': Cyrille Berger
==== Project: Substrate simulation ====
'''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.
Expected results: an optional substrate simulation that works with all current Krita tools
'''Used Technologies''': C++, Qt, OpenGL
'''Mentor''': Boudewijn Rempt
==== Project: Color Mixing ====
'''Brief explanation''': Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.
'''Expected results''': a color mixer that works, layer composition and painting.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt
==== 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:
1. 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.
2. 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.
3. 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.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt
==== Shift drag sensors ====
Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.
'''Used Technologies''': C++, Qt, color theory, mathematics
'''Mentor'': Boudewijn Rempt


=== KDE Finance ===
=== KDE Finance ===

Revision as of 10:23, 9 February 2011

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

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

How to find ideas? To see previous Project ideas, see: 2010 ideas. Obvious sources of projects are the bugs database, the forum, and your list and IRC channel ideas.


Amarok

Amarok is a powerful KDE based music player for Linux and Unix, MacOS X and Windows with an intuitive interface. It makes playing the music you love and discovering new music easier than ever before - and it looks good doing it!


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

Project: Playlist sharing

Brief explanation: Amarok playlist sharing will allow you to select a set of tracks and share them with friends over chat. By using Telepathy lots of IM networks are available including jabber, google talk, AIM, MSN and facebook chat.

Expected results: A plugin will add a PlaylistProvider to Amarok that enable the user to share via HTTP streaming (P2P) a playlist with online friends.

Knowledge Prerequisite: Qt/KDE development (includes C++ & git), Telepathy, HTTP streaming and NAT traversal.

Any of these are optional but not all of them.

Skill level: medium to high.

Mentor: Bart Cerneels or Ian Monroe

Project: Self Contained Collection

Brief explanation: sqlite file saved in collections own folder. Tie in with USB media device. More info to follow.

Expected results:

Knowledge Prerequisite: Qt/KDE development (includes C++ & git), SQL.

Skill level: medium.

Mentor: Unless someone else from the Amarok team can be convinced: Bart Cerneels

digiKam

Photo Management program

digiKam project web site - Mailinglist - IRC channel: #digikam on Freenode.

Project: Camera UI Revamp

Brief explanation: DigiKam features a UI for accessing and downloading pictures from cameras. The code is rather old, using Qt3Support classes for the icon view, the UI code intermangled deeply with backend code, and has not seen very much care and love for some years.

This project would involve taking the old code apart, rewriting a clean code base backend and frontend, but also adding user interface elements to make the most important everyday task as easy as possible.

In more detail: Write a model listing images on a camera (There are two backends, USB mass storage cameras, which are basically files on disk, and gphoto2 cameras, which require access through a library). Take the existing digikam icon view and delegate classes, which are prepared for code reuse, and put together an icon view for the model. Cleanly separate the code that does the actual work (downloading, converting, renaming) from the UI. Wrap that in the main window.

UI design: The current interface is powerful, exposing many options. We want to preserve that. But at the same time, there are three very common actions: a) Download all new files to the last used album b) Download all new files to a new album c) Download all new files to an existing album.
It should be possible to carry out task (a) with one click, task (b) and (c) with two or three clicks, without opening a dialog. Friendly to the new user, preserving access to all options for the poweruser.

Expected results: A camera UI based on Qt model/view and clean code which provides the currently available functionality, offering a quick path to download new pictures.

Knowledge Prerequisite: Qt, C++. Interest in Qt model/view and UI code.

Mentor: Gilles Caulier? (Marcel Wiesweg)


Project: Presentation View

Brief explanation: The presentation view is a full-screen workplace which you can use to present photos to yourself or your audience. At first glance it is looking like the current slide show, but then it is much more flexible: At any moment, you can access UI components like the map view, the metadata tab, the image properties tab, to access information, assign metadata, or show your audience the location of the picture on OpenStreetMap. You can access an icon view component to change the collection your are currently presenting, or a thumbbar component to switch to a different image.

The main view typically shows one image full screen, but you can zoom; You can also change to a layout that shows four or five images at a time, like images put in a paper album. You can change the order of images presented, and store order and layout (preferably in some XML format). You can load these presentations later, playing them automatically, coming back to the traditional slide show.

Technically, it should be future proof as much as possible (Qt Quick. QGraphicsView. scene graph in the future? Will embed QWidgets though) The job is not to develop any of the components mentioned above, but to avoid that, and reuse the existing digikam components and models.

Expected results: Something resembling the vision outlined above

Knowledge Prerequisite: C++, Qt

Mentor: Marcel Wiesweg


Project: MacOSX support

Brief explanation:

digiKam needs to be available under MacOSX in native. Currently, - Macports project is the only way to get last digiKam under Mac. Macports require to compile all depencies and digiKam as well. It's a long and hazardous solution to see digiKam running under Mac.

Also, current digiKam implementation is not optimized for Mac desktop. A lots of point need to be improved to support better this operating system. Graphical interface need to polished too.

See relevant entries in KDE bugzilla about MacOSX support :

257679 257773

Expected results: Provide scripts and configurations to build automatically a DMG archive of digiKam for MacOSX. Improve digiKam GUI everywhere to be more elegant and more optimized for MacOSX.

Knowledge Prerequisite: C++, Qt, MacOSX, scripting, DMG, packaging

Mentor: Julien Narboux ? (Gilles Caulier)


Project: Video metadata support

Brief explanation:

All recent digital-still camera device provide video capture. digiKam must be able to manage these files as images. digiKam can already play video and register files to the database, but it lack important metadata used to catalog and sort item (as date, camera name, and all record condition).

To improve video file support, video metadata management done in background need to be improved, to patch Exiv2 shared library (already used by digiKam)

See relevant entries in KDE bugzilla about video support :

164442 229543

Expected results: Add video files support to Exiv2. Patch digiKam metadata interface to handle video information.

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

Mentor: Gilles Caulier, Andreas Huggel

Project: Clone Tool for Image Editor

Brief explanation:

In digiKam image editor we need a simple clone tool to be able to remove quickly dusts, spots, and other unwanted artefact from an image.

See relevant entry in KDE bugzilla about it :

132483

Expected results: add a new tool (as new image editor plugin) with the clone feature.

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier

Project: Panorama Tool

Brief explanation:

With recent digital still camera, it's possible using a tripod to take images to create panoramic view. We need a tool to assemble these images automatically. Common image corners must be detected and merged without to ask any settings to user. Colors and luminosity of each shot must be adjusted automatically too.

See relevant entry in KDE bugzilla about it :

235766

Expected results: add a new tool (as kipi plugin) with auto-panorama feature.

Knowledge Prerequisite: C++, Qt

Mentor: Gilles Caulier

KDE Edu

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE Games

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:


KDevelop

KDE-based Integrated Development Environment, specializing in c++ support, but including a powerful generic framework (definition use chain) which makes it possible to relatively easily support multiple different languages.

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

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:


KDE Core

KDE Core is the interest group working on the underlying KDE development platform such as kdelibs and kde-runtime. KDE Core provides libraries that are used by all KDE applications and so essentially define what a KDE application is. Working on KDE Core is highly challenging as it requires much forward thinking for maximum utility and flexibility as well as guaranteeing backwards compatibility and cross-platform support.

Project: Support for astronomical calendar systems

Brief explanation: Add support for astronomical calendar systems. KDE is unique in the Linux eco-system for providing support for alternative calendar systems, such as the Hebrew, Islamic Civil, and Japanese calendar systems. Support for such calendar systems is standard in the Windows and Mac worlds. However, KDE does not as yet support calendar systems that require astronomical calculations, such as the Chinese and Islamic Lunar calendars, This project would fill this gap.

Expected results: Documentation, design and production of Chinese, Indian, Islamic and Jalali/Persian calendar systems and their numerous derivatives. The documentation to be of a high enough standard to submit to various standardization bodies. Production of an astronomical library for calculating sunrise, sunset and moon phase (and any other useful calculations) for shared use between the calendar systems and other KDE libraries and applications such as KHolidays, KStars and Marble.

Knowledge Prerequisite: C++, especially an understanding of Binary Compatibility rules and good API design. Some knowledge of Celestial Mechanics and good mathematical literacy. Any experience with regular cultural use of astronomical calendars would be highly useful.

Mentor: John Layt

KDE PIM

KDE PIM is the interest group working on applications related to personal information management, e.g. contacts, calendar, mails, etc.

There are interesting projects on all levels of the software stack: libraries, application porting, new applications, access to online resources, etc.

Website - Project Wiki - Mailing list - IRC channel: #kontact and #akonadi on Freenode.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Calligra

KDE's integrated work applications suite

Web - Mailinglist - IRC channel: #calligra on Freenode.

Karbon

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 modify the path a tool that, 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 Karbon is part of the Calligra suite, this would clearly benefit apps such as Krita, also.

Expected results: Modify path tool is able to scale 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.

Technologies Used: C++,Qt,SVG?

Mentor: Jan H? jaham @t gmx,net (need to ask :P )

Words: Improve quality of ODF write support

Brief explanation: While a lot of work went into improving the quality of loading ODF text-documents, saving them can still be improved a lot. The goal of the gsoc would be to improve the quality of the by Calligra Words produced ODF. This means fixing the produced ODF text-documents so they a) do validate against the ODF XML-schema and b) are proper loaded with Calligra Words, LibreOffice.org/OpenOffice.org, Microsoft Word, etc. By identifying and fixing bugs and adding unittests for regression-testing we could improve the quality of the core of Calligra significantly.

Mentor: Sebastian Sauer, please contact [email protected]

Words: Implement notes-support

Brief explanation: Implement and extend the notes-support in Calligra Words to view+add+edit+delete+load+save notes/comments/annotations in Calligra Words.

See also bugs 260138 and 260184 and 260102 and 260127.

Mentor: Sebastian Sauer, please contact [email protected]

Words: Fix and extend LaTEX support

Brief explanation: Calligra Words has an import and export filter for LaTEX documents. Those need to be extended to proper import/export and produce better results. We could also implement a new view in Calligra Words to support latex like working.

See also bugs 260063 and 260056.

Mentor: Sebastian Sauer, please contact [email protected]

Words: PDF-Import and/or PDF-Export

Brief explanation: Currently Calligra Words supports exporting the drawn canvas as images using the File=>ExportPDF menu-item. The idea is to create an export and/or import filter to import and/or export to/from PDF (not as images but as text) using poppler.

Mentor: Sebastian Sauer, please contact [email protected]

Words: Integrate with Akonadi

Brief explanation: Integrate with Akonadi to provide access to resources (contacts-variables, mail-merge, ...).

See also bug 260220.

Mentor: Sebastian Sauer, please contact [email protected]

Words: References tool

Brief explanation: Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we don't have yet is a references tool that provide the ui for creating table of contents, citations/bibliography, and end notes. Table of centents has all the underlying engine in place. That same engine can be reused/copied/modified for bibliography (maybe planning for the use of http://www.zotero.org )

Mentor: Casper Boemann, please contact [email protected]

Words: Layout tool

Brief explanation: Words is tools based and has a write tool, a review tool as well as the beginings of a layout tool. What we need is completion of this layout tool. Much of it is just ui allowing the user to set all sorts of layout options using the engine which is already in place.

As it's not such a big project, we expect everything about this tool to be perfect so it can enter directly into the next version of Calligra Words.

Mentor: Casper Boemann, please contact [email protected]

Krita

Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Mailing-list: https://mail.kde.org/mailman/listinfo/kimageshop/

Project Page: http://www.krita.org/

Irc channel: #krita on irc.freenode.net

Forums: http://forum.kde.org/viewforum.php?f=136.

Wiki: http://community.kde.org/Krita

Krita: ABR Brush Support

Brief Explanation: Your task will be implement support for various features from brushes available in Photoshop. You will be extending current brush engines in Krita with set of features like texture painting, shape dynamics, flow, wet edges...The format is not documented and you will work with reverse-engineered information. Your task is to implement missing features, add mapping of the binary format to Krita XML format and possibly improve the reverse-engineering information.

Mentor: Lukáš Tvrdý

Used technologies: C++, Qt

Resource: http://community.kde.org/Krita/ActionPlan2#Photoshop_brush_support_in_Krita

Krita: PSD File import/export Support

Brief Explanation: The industry standard for raster graphics is still Photoshop. This file format is closed. This project will entail bringing together the freely available information on the PSD file format and build an import/export filter upon the existing framework in Krita.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt,

Resources: existing open source implementations like http://sourceforge.net/projects/libpsd/ and http://git.gnome.org/browse/gimp/tree/plug-ins/file-psd

Krita: Flow and drying: real media support

Brief Explanation: As a painting application, Krita tries to make things possible for digital artists that were previously only available in “real” media. The effects of paint flowing, drying and being absorbed can be used to create interesting effects. Particularly challenging is the flow of undo and redo.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt

Resources: http://www.billbaxter.com , http://www.levien.com/gimp/wetdream.html , http://research.edm.uhasselt.be/~tvanlaerhoven

Krita: 3D Sketching tool

Brief Explanation: When drawing comics, it can be particularly challenging to draw in the correct perspective. With a similar interface to Manga Studio, this project entails extending the guided painting interface of Krita into the third dimension, making sure parallel lines drawn by hand will have the correct perspective. This project can be extended by making it possible to import 3D objects created by, e.g. Google Sketchup

Mentor: Lukáš Tvrdý or Cyrille Berger

Used technologies: C++, Qt,

Krita: Text Balloon support for Comics work

Brief Explanation: Comic books artists are one of the target user groups for Krita. A challenge when working on comic books is the placement and lettering of the text balloons -- and the internationalization! This project will entail creating vector-based support for translatable balloons that contain text that looks hand-written.

Mentor: Boudewijn Rempt

Used technologies: C++, Qt, SVG

Expected results: a layer type that contains vector-shaped balloons of various types and textual content that can easily be internationalized.

Resources: http://en.wikipedia.org/wiki/Speech_balloon

Krita: Painting and Separation of 3D Textures

Brief Explanation: 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.

Mentor: Lukáš Tvrdý

Used technologies: C++, Qt

Resources: http://www.krita.org

Krita: Advanced selection using SIOX

Brief explanation: SIOX stands for Simple Interactive Object Extraction and is a solution for extracting foreground from still images with very little user interaction.

Possible mentor: Cyrille Berger (or Sven Langkamp)

Used Technologies: C++, Qt

Resources:

Krita: Tagging and management for Krita resources

Brief explanation: Krita comes with a rich selection of resources: patterns, gradients, brushes, brush presets, soon materials for texture painting. These resources need to be managed: added, deleted, changes and tagged. Existing tagging specifications exist for Gimp and for Viaduct, and Krita should be compatible here. Integration with Get Hot New Stuff and Nepomuk are important aspects of this project. Especially interesting here is to make this system fit in the workflow of artists working on textures. There will be data structures and gui work.

Expected results: A functioning implementation of resource management and tagging.

Used Technologies: C++, Qt, digital art.

Mentor: Boudewijn Rempt

Krita: GPU-acceleration for Krita

Brief explanation: Although Krita was one of the first painting applications with OpenGL and shader support, Krita uses the CPU for all its calculations. Until now the OpenGL and shader support have been used solely for display purposes, like the 3D brush model, real-time preview of gradients on the canvas. We would like to improve on this by using the GPU to improve the performance of blending layers, painting and transforming. Expected results: optimized composition operators, transformation code Used Technologies: C++, Qt, OpenGL, GLSL, OpenCL, General-Purspose GPU coding

Mentor: Lukáš Tvrdý

Krita: GPU-backend for OpenGTL

Brief explanation: Krita uses the OpenGTL family of languages for easy creation of filters, colorspaces and possibly brush engines. OpenGTL currently uses LLVM to compile these scripts to code that runs on the CPU. Alternatively, compiling to the GPU would mean considerably performance improvements. There are two possibilities to implement such a change:

  • Convert from the OpenGTL languages to OpenCL/GLSL and then run the converted shader on the GPU, this can be done by writing an AST output backend
  • The mesa library uses llvm for compiling to the GPU from OpenCL/GLSL, so it should be possible to bypass the conversion and plug OpenGTL directly on the mesa library

The first possibility has the advantage to be more portable, the second solution might offer performance gain. The conversion approach should be implemented first, and then, the students could investigate the use of the mesa library when available.

This is a very challenging task!

Resources: http://www.opengtl.org

Expected results: OpenCL AST generator, report on the possibility to interface OpenGTL with mesa

Used Technologies: C++, GLSL, OpenCL (possibly LLVM)

Mentor: Cyrille Berger

Krita: Substrate simulation

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. Expected results: an optional substrate simulation that works with all current Krita tools

Used Technologies: C++, Qt, OpenGL

Mentor: Boudewijn Rempt

Krita: Color Mixing

Brief explanation: Building on Emanuele Tamponi’s ground-breaking work on spectral colorspaces and color mixing, the topic of this project is to extend and finish this work and make is usable in Krita. Spectral colorspaces have the advantage that mixing colors produces the same result as in when mixing real-world paints. Problems are transparency (alpha channel) and composition.

Expected results: a color mixer that works, layer composition and painting.

Used Technologies: C++, Qt, color theory, mathematics

'Mentor: Boudewijn Rempt

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


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

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

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


Used Technologies: C++, Qt, color theory, mathematics

'Mentor: Boudewijn Rempt

Krita: Shift drag sensors

Currently shift+dragging the left mouse button horizontally can be used to alter the brush size. This is awesome as it minimises time wasted going back and forward between where you're painting and the brush editor a million times. It would be even better if brush softness, hue, value, page zoom etc could be changed in a similar way. Shift + drag could be used with any othe three mouse/stylus buttons (left - LMB, middle - MMB, and right - RMB click) both horizontally and vertically, giving us up to 6 things that could be quickly changed, right at the users cursor. This proposal is to make a system to link any of these shift+drag options to modify brush properties or page zooming in a fast, intuitive manner. For example shift + vertical LMB drag could modify brush softness, shift+rmb horizontal drag could be assigned to changing opacity, shift + mmb horizontal could be assigned to modifying brush hue, shift + mmb + vertical drag could be assigned to adjusting brush value and so on. Possibly these could be implemented as sensors and thus assigned to anything in a brush that currently has a curve.

Used Technologies: C++, Qt, color theory, mathematics

'Mentor: Boudewijn Rempt

KDE on Windows

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:


KWin

KDE's window manager

Techbase page - Mailinglist - IRC channel: #kwin on Freenode.

Project: Modularization of Workspace

Brief explanation: The Workspace class is the monolithic core of KWin. Nevertheless many parts of it do not depend on each other and can be split out of Workspace into own classes. The modularization is an important prerequisite to a port of KWin to Wayland and providing a small window manager for mobile devices.

Expected results: A concept for what can be moved into own classes exists and several classes have been split out of Workspace. The X11 dependend code is moved into an own plugin. Plus if tests for the new classes are written.

Knowledge Prerequisite: Qt/C++ and general understanding of window management. Plus for X11 knowledge

Mentor: Martin Gräßlin (mgraesslin)

Project: Unit Testing Framework

Brief explanation: Testing a window manager is rather difficult as it requires a running instance and windows need to be created and interacted with. This project should set up a test framework based on Xephyr, KWin's scripting interface and QTest.

Expected results: An infrastructure to test the core of KWin with simple KWin scripts should exist and several unit tests for existing functionality should be implemented

Knowledge Prerequisite: Qt/C++, JavaScript, QTest

Mentor: Martin Gräßlin (mgraesslin)

Project: Initial Support for Wayland Clients

Brief explanation: Wayland is the next iteration for composited window management. The task of this project is to add support for managing Wayland clients on X11 and integrate them into the existing compositing rendering code for GLES.

Expected results: KWin is able to manage Wayland clients and can render the clients. Plus for support to interact with them (move/activate/restack).

Knowledge Prerequisite: Qt/C++ and general understanding of Window management. Plus for OpenGL knowledge

Mentor: Martin Gräßlin (mgraesslin)

Nepomuk

Website- Documentation/Howtos - Ontologies - Mailing list - IRC channel: #nepomuk-kde on Freenode.

(Also see the Nepomuk techbase page for a long list of Nepomuk-related ToDos and ideas.)

IRC channel: 

#strigi on Freenode

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Plasma

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

Project: QML QtComponents set

Brief explanation: The QtComponents project is aiming to provide an api and a series of widget sets completely based upon QML. the actual implementation is platform-dependent, so KDE needs its own platform specific set made with the plasma theming mechanism,for both the desktop and the mobile.

Expected results: A complete set of QtComponents for the use in QML based plasmoid for the desktop, if there is enough time, the start of a mobile version (with as less as possible changed from the desktop case)

Knowledge Prerequisite: both QML and Qt C++ programming are useful (and preferred), most of it can be learned on the way

Mentor: either Marco Martin and/or Artur De Souza

Project: Plasma media center first release

Brief explanation: The Plasma media center project needs some work to get to a first alpha release quality: mostly a reingeneering of the components of the main gui and porting the graphical elements to qml

Expected results: a basically working media center at least with an index of local media files (videos, pictures and music)

Knowledge Prerequisite: Qt C++, QML and some ideas on the Plasma architecture, QML can be learned on the way

Mentor: Marco Martin

Project: QML-ify Plasma widgets

Brief explanation: The Plasma2 library will be heavily based on QML, probably dropping qgraphicswidget support altogether. All the default plasmoid set will heve to be ported to be either pure QML/Javascript or QML/C++ in the meantime.

Expected results: At least 6-7 minor plasmoids ported to QML or some (to define) of the main ones (like kickoff,taskbar, systray, whatever)

Knowledge Prerequisite: Qt C++ some idea on Plasma and kdelibs arch, already knowing something of QML helps

Mentor: Marco MArtin

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Phonon

Abstraction library for sound and video support. Used by KDE notifications, Amarok, Dragon Player and Qt Software.

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

Community wiki with TODOs and outstanding issues.

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Kate

Kate is a powerful programmer's editor.


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

Project: Modeline Editor

Brief explanation: Kate supports modelines, also called document variables. Through this, users can configure individual settings for specific documents. The task of this project is to add a modeline editor, that can write/change the document variables in the document.

Expected results: A modeline editor that is able to edit the current modeliens. This editor could be reused in the "Modes" tab in Kate's config page.

Knowledge Prerequisite: C++/Qt, Qt-Designer, high motivation

Mentor: Dominik Haumann / Christoph Cullmann

Project: Further improve the Vi Input Mode

Brief explanation: Kate supports a modal, Vi[m]-like editing mode. The support for Vim features is already quite good in some areas, but there is more to be done:

  • A “jump list” should be maintained of the last cursor positions, making it possible to jump back to earlier positions and forward again (ctrl+i/ctrl+o in vim)
  • More command line mode commands should be supported, and it should be possible to use marks in ranges, i.e. “:'a,'bs/foo/bar/”
  • A thorough test suite
  • [your favourite feature]

Expected results: An improved vi input mode for kate

Knowledge Prerequisite: C++/Qt, high motivation

Mentor: Erlend Hamberg



Konqueror

Mailing-list: https://mail.kde.org/mailman/listinfo/kfm-devel/ https://mail.kde.org/mailman/listinfo/kfm-devel/

Project Page: http://www.konqueror.org/

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

KDE Finance

KDE Finance is an emerging group of applications dedicated to financial topics, such as Personal Finances Management, Invoices Management, Point of Sales...

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Rekonq

Rekonq is a web browser for KDE based on WebKit. It first focuses on being a light, fast & clean way to access to net. Its development is doubly based on using the new amazing features offered by the WebKit rendering engine and on the rock solid network KDE technologies.

Project: Adblock improvements & elements manipulation

Brief explanation:

Rekonq currently has an initial implementation of an ads blocking mechanism. This project aims to expand it providing the feature parity with AdBlockPlus and implement a sort of HTML elements manipulation system (enable it, and then click on the page on the elements you want to hide. When you're ok, save your changes, reset them or leave them just for this time)


Expected results:

An improvements in the adblock rules handling, some (new) tests to check adblock behavior and performance, the elements manipulation feature with (possibly) the ability to save and remember applied changes.

Knowledge Prerequisite:

C++ programming and hopefully Qt


Mentor: Andrea Diamantini

ownCloud

An open personal cloud which runs on your personal server. It enables accessing your data from all of your devices. Sharing with other people is also possible. It support automatic backups, versioning and encryption.


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

Project:

Brief explanation: Build a client to sync your ownCloud files with your local disc to enable offline use.

Expected results: Development of an application you run on your local PC. This applications syncs local folders with folders on your personal ownCloud server everytime you are online. This applications needs a GUI written in KDE/Qt to configure the ownCloud url, folders, login and password. The applications sits in the systray and informs the user about the syncing progress or sync conflicts. The idea is that the clients mounts the ownCloud folders via WebDAV into a "hidden" directory and syncs the folders via rsync or an own syncing script. Errors should be reported to the user. To quote Frank from the mailing list:

"The client should: 

1. read a configuration file so see which folders to sync and which owncloud server to use.
2. mount the owncloud server via fuse or a different tool into a hidden directory.
3. call a syncing tool like csync to sync between the local directory and the mounted directory
4. unmount owncloud
5. write a log-file about the synced files and potential conflicts which the user has to solve.

The client should be as portable as possible of course."

Current inactive projects such as Cloudsync or owncloud-sync-client (both on Gitorious) may possibly be starting places worth investigating.

Knowledge Prerequisite: Python, Ruby, PHP or C++ and KDE/Qt depending on the technology you choose for the desktop syncing client. Enthusiasm for Cloud/Desktop integration and trying new things.

Mentor: Kyle Cunningham? Robin Appleman? Frank K?

KDE Usability

Project: Usability Survey Framework

Brief explanation: Surveys are one of many methods used in creating more usable software. Surveys allow designers to collect information about user's experiences and usability problems with software. A Usability Survey Framework would allow designers and developers to create small, custom surveys that can be attached to events or services. Users could subscribe to the Usability Survey Service and opt in to current studies. Survey studies could be one-time surveys, or several survey entries over a period of time.

For example, if we wanted to learn more about how users interact with workspaces, a survey could occasionally open when a user accesses or configures the workspace. If we wanted to learn more about the Plasmoid installation process, we could open a survey when a user installs the next plasmoid.

A Usability Survey Framework would help users become more involved in KDE through direct participation. Developers would be able to easily design and launch surveys to collect important usability feedback. Designers would be able to easily conduct usability studies.

Expected results: The Usability Survey Framework could be implemented as a web service, downloadable Plasma widget, or mini application. It should be an easily configurable survey that collects data based on an event.

Possible features:

  • Uses XML for survey design to make it easy to create and launch new surveys
  • Uploading or emailing data at end of study
  • Can be a single survey, or a survey study over a period of time
  • Configured to open on a specific event

Knowledge Prerequisite: JavaScript, C++. Qt/KDE/Plasma knowledge would help greatly.

Mentor: Celeste Lyn Paul, someone else?

KDE SDK

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:


KDE Language Bindings

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:


Solid

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Wikis

Project: One-click Spammer removal

Brief explanation: Currently Wiki administrators have to go to the spammer's user page and block him for a specified time. Then any pages added by him must be deleted and finally any images added must be found and deleted.

Expected results:

Knowledge Prerequisite:

Mentor:


It would be very useful if administrators could call up the Ban page and be able to remove pages and images with a single click from there. Ideally if spam had been added to an existing page that would be reverted, but this is a less common scenario.

The work should be presented as a mediawiki extension.

Okular

Project: Advanced text layout recognition engine

Advanced text layout recognition engine Brief explanation: Okular has a very naive algorithm to detect the layout in text in which basically everything is considered to be layouted in a line. You will need to know some text layouting algorithms to improve the detection of columns in text so that text selection works better.

See relevant entry in KDE bugzilla about it: 161324

Expected results A better text selection experience for the user.

Knowledge Prerequisite C++, Qt

Mentor Albert Astals Cid

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