GSoC/2014/Ideas: Difference between revisions

From KDE Community Wiki
< GSoC‎ | 2014
(→‎KDE PIM: Added Enhanced Searching in KMail)
Line 171: Line 171:


===Krita===
===Krita===
We welcome students who want to work on Krita for Google Summer of Code. If you want to work on Krita, keep in mind that we would like you to stay with the project, also outside Summer of Code. Summer of Code isn't just a summer job with some mentoring added -- it's a way of becoming part of the team.
If you haven't worked on Krita before, we want you to demonstrate your skill beforehand by fixing bugs or implementing some features. It's a good idea to start on that in January. Here is a list of pre-gsoc ideas:
== Pre-GSOC ideas ==
==== Idea: Integration with Web-Services ====
* https://bugs.kde.org/show_bug.cgi?id=274866
==== Idea: Extended history manipulation ====
* Cumulative Undo/Redo (needs modifications to tiles engine to be able to merge several undo revisions)
* Snapshots?
==== Small Project: Wavelet Filter====
==== Small Project: Virtual Second Tip of the Stylus ====
==== Small Project: Lazy Brush ====
==== Small Project: Advanced Composition Docker ====
The Compostion docker needs some work to make it's use more fluent and useful to artists (comics,textures, regular export setups)
*Compositions should be updatable and have managment options (renaming,ordering)
*Workflow improvements for more easy use (selecting should not activate composition immediately)
*Save locks and other layer settings (preserve alpha,collapse state of groups etc.)
*Storage of exported image links
*Selective export (selection options to export all or some compositions)
*Snapshot preview of composition (optional)
https://bugs.kde.org/show_bug.cgi?id=322159
== GSOC ideas ==
We really like students who come up with their own project ideas. To get you started, however, here are some ideas we've come up with:
==== 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: 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.
==== 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
==== Project: Real Paint Emulation ====
We already did some research on the emulation of real-world paint and we do already have some essential pieces of it: Hairy Brush and Bumpmap filter. Now we need to bring this all together and allow a painter to use it easily, so that he could paint images like that: TODO. This project would involve creation of a special type of layer and a new colorspace, so the student should already be familiar with our layer stack and pigment code.
==== Research Project: layer stack optimizations ====
Right now when one layer got changed our merger should walk through all the layers of the current group and compose all of them into projection one by one. But this doesn't take into account that COMPOSITE_OVER (which is the most popular composition mode) has an associativity property, which means we can merge all the layers below and all the layers above dirty one into two groups, and calculate a group of any size with only two composition operations, which would give huge speed advantages.
Unoptimized group:
* layer 6
* layer 5
* layer 4
* layer 3 <-- active layer (becomes dirty quite often)
* layer 2
* layer 1
Optimized group:
* <flattened 4-6>
* layer 3 <-- active layer (becomes dirty quite often)
* <flattened 1-2>
After this project is done, we can start implementing layer composition on the GPU using openGL.
==== Project: Improved Animation Brush System ====
This should result in animation brushes being more readily available and adjustable. The current way of doing this is not as userfriendly as it could be.
*Dedicated "Animation Brush GROUP"-> everything in group is a frame of the animation. (for use in current file,instead of in another instance of krita)
*Convert group to animation group ->Normal group becomes animation brush reference.
*Save as animation brush PRESET
*options to set animation brush continuity to custom, random, incremental, pressure,angular,loop...
*animation brush presets (in settings) need a timeslider to flip through the available frames
https://bugs.kde.org/show_bug.cgi?id=322159
==== Project:  seamless textures by using UV layout as self-wrapping paint mask====
This is a tool that should help in creating seamless (or as close as possible) textures for organic models. It will help in painting creases and other details across seams.
http://www.sintel.org/wp-content/uploads/2010/01/face_uv_export.png
*Convert intersections on uvlayout to seam transfer points.
*use those points to transfer painted strokes to connected points on other side (set by user)
*create userfriendly way to add,manage those seam transfer points. (multiple should be active at once)
https://bugs.kde.org/show_bug.cgi?id=324072
ALTERNATIVE
*Similar to previous idea,but with movable curves/grid with adjustable seam transfer points in stead of converting a whole UV layout automaticly
https://bugs.kde.org/show_bug.cgi?id=321547
More ideas for projects can be found here:
https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=Wishlist%20count&list_id=884686
== Past GSOC projects ==


=== Kexi ===
=== Kexi ===

Revision as of 10:08, 10 February 2014

See also: GSoc Instructions, Last year ideas

Guidelines

Information for Students

These ideas were contributed by our developers and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the developers and find out more about the particular suggestion you're looking at.

Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

When writing your proposal or asking for help from the general KDE community don't assume people are familiar with the ideas here. KDE is really big!

If there is no specific contact given you can ask questions on the general KDE development list [email protected]. See the KDE mailing lists page for information on available mailing lists and how to subscribe.

Adding a Proposal

Note

Follow the template of other proposals!


Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

When adding an idea to this section, please try to include the following data:

  • if the application is not widely known, a description of what it does and where its code lives
  • a brief explanation
  • the expected results
  • pre-requisites for working on your project
  • if applicable, links to more information or discussions
  • mailing list or IRC channel for your application/library/module
  • your name and email address for contact (if you're willing to be a mentor)

If you are not a developer but have a good idea for a proposal, get in contact with relevant developers first.


Ideas

Your Own Idea

Project: Something that you're totally excited about

Brief explanation: Do you have an awesome idea you want to work on with KDE but that is not among the ideas below? That's cool. We love that! But please do us a favor: Get in touch with a mentor early on and make sure your project is realistic and within the scope of KDE. That will spare you and us a lot of frustration.

Expected results: Something you and KDE loves

Knowledge Prerequisite: Probably C++ and Qt but depends on your project

Mentor: Try to see who in KDE is interested in what you want to work on and approach them. If you are unsure you can always ask in #kde-soc on Freenode IRC.

Web

KDE Multimedia

Amarok

digiKam

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

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>

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>

Project: Add a quick access to Labels in dedicated tree-view

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

Dependencies: : digiKam Database

Bugzilla entries: 160363,

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

Expected results: To have a quick acess tree-view in all relevant gui where Labels can be selected for photo workflow.

Screenshots: Microsoft Live Photo Rating tree-view, Apple Aperture Labels tree-view

Difficulty: medium

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

Calligra Words

KDE Telepathy

Marble

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

Interactive Tours

Brief explanation: A Tour is a set of related places along with supporting media (text, images, audio, video). Tours can be viewed (playback): The invididual places are visited in a defined timeline. They're useful for a wide range of tasks, like showing an interesting hike along with panorama pictures, highlighting places of interest for sightseeing or showing historic events and political changes happening over decades. The Marble library has been designed to support these use cases, but the user interface does not reveal all the features yet. This project is about changing that.

Expected results:

  • Extend the existing Tour widget for animated tour playback
  • Improve the usability of the Tour widget
  • Support interactive elements in tour playback
  • Implement time support for tours for different time ranges (from eras to years to days to minutes to milliseconds)
  • Add support for recording tours
  • Enhance the screencast feature to generate videos from tours.

Optional:

  • Extend Marble's owncloud synchronization feature for uploading tours to owncloud
  • Add tour viewing support to the Marble owncloud app
  • Implement tour viewing in the QML version of Marble
  • Provide tours for existing map themes to highlight features of them

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

Mentor: Dennis Nienhüser and other Marble developers.

KDE Edu

Sound Visualization and Sound Effects in Artikulate

Brief explanation: Artikulate is a language learning application that focus on improving a learner's pronunciation skills by repeating native speaker recordings, recording that try and comparing boths. By repeating these trials, a learner can continuously improve his/her language skills. There are areas for this project:

  1. native speaker recordings are recorded (either by GStreamer or QtMultimedia), converted to an OGG file and saved. What is missing is an application of noise cleanup filters, removing of no-sound intervals, and normalization (possibly combined with a very basic sound editor)
  2. when playing and comparing sounds, there is no visual feedback about how much the soundwaves differ: plotting the soundwaves in a reasonable format

Goals: The goal is to extend the sound processing in Artikulate to

  1. Implement simple sound filters for normalization, noise removal, removal of white noise and integrate sound postprocessing into the editor workflow
  2. Implement plotter for soundwaves and integrate this in the training mode

Yet for both it is important to research which libraries already exist and possibly could be reused. Also, research is needed about which techniques for comparing the soundwaves is appropriate. A proposal should already contain verbose information about these questions.

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

Mentor: Andreas Cord-Landwehr and/or other people from KDE Edu

KStars

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

Krita

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

If you haven't worked on Krita before, we want you to demonstrate your skill beforehand by fixing bugs or implementing some features. It's a good idea to start on that in January. Here is a list of pre-gsoc ideas:

Pre-GSOC ideas

Idea: Integration with Web-Services

Idea: Extended history manipulation

  • Cumulative Undo/Redo (needs modifications to tiles engine to be able to merge several undo revisions)
  • Snapshots?

Small Project: Wavelet Filter

Small Project: Virtual Second Tip of the Stylus

Small Project: Lazy Brush

Small Project: Advanced Composition Docker

The Compostion docker needs some work to make it's use more fluent and useful to artists (comics,textures, regular export setups)

  • Compositions should be updatable and have managment options (renaming,ordering)
  • Workflow improvements for more easy use (selecting should not activate composition immediately)
  • Save locks and other layer settings (preserve alpha,collapse state of groups etc.)
  • Storage of exported image links
  • Selective export (selection options to export all or some compositions)
  • Snapshot preview of composition (optional)


https://bugs.kde.org/show_bug.cgi?id=322159

GSOC ideas

We really like students who come up with their own project ideas. To get you started, however, here are some ideas we've come up with:

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

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

Project: Real Paint Emulation

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

Research Project: layer stack optimizations

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

Unoptimized group:

  • layer 6
  • layer 5
  • layer 4
  • layer 3 <-- active layer (becomes dirty quite often)
  • layer 2
  • layer 1

Optimized group:

  • <flattened 4-6>
  • layer 3 <-- active layer (becomes dirty quite often)
  • <flattened 1-2>

After this project is done, we can start implementing layer composition on the GPU using openGL.


Project: Improved Animation Brush System

This should result in animation brushes being more readily available and adjustable. The current way of doing this is not as userfriendly as it could be.

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

https://bugs.kde.org/show_bug.cgi?id=322159

Project: seamless textures by using UV layout as self-wrapping paint mask

This is a tool that should help in creating seamless (or as close as possible) textures for organic models. It will help in painting creases and other details across seams. face_uv_export.png

  • Convert intersections on uvlayout to seam transfer points.
  • use those points to transfer painted strokes to connected points on other side (set by user)
  • create userfriendly way to add,manage those seam transfer points. (multiple should be active at once)

https://bugs.kde.org/show_bug.cgi?id=324072

ALTERNATIVE

  • Similar to previous idea,but with movable curves/grid with adjustable seam transfer points in stead of converting a whole UV layout automaticly

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


More ideas for projects can be found here: https://bugs.kde.org/buglist.cgi?cmdtype=runnamed&namedcmd=Wishlist%20count&list_id=884686

Past GSOC projects

Kexi

Kexi is a visual database creator. It can be used for designing database applications, inserting and editing data, performing queries, and processing data.

More info: Developers' wiki, web site for users, mailing list, IRC channel: #kexi and #calligra on Freenode.

Calligra Plugins

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

More info: web site for users, mailing list, 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

KDE Workspaces

KDE Games

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

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.

KDENetwork

Solid

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

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

Simon

Simon is a speech recognition suite.

Blog - Mailing list - IRC channel: #kde-accessibility on Freenode.

Jovie

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++, Qt, understanding of Input Methods

Mentor: Andriy Rysin <[email protected]>

KDevelop

KDE PIM

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

OpenHolidays

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

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

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

Mentor: John Layt and other KDE PIM community members.

Enhanced Searching in KMail

Brief explanation: KMail is the defacto email client in KDE. It currently has a complex search dialog which allows the users to configure many different parts of the search. While it is very powerful, it is not very usable. A better search dialog is required which allows the user to modify the initial search and filter the data appropriately. A good example of this would be the Thunderbird search dialog - 2011-03-14-10-05-42-56151b.jpg

Expected results: Implementing the new search dialog and updating the backend search code to include whatever new features are required. Implementing this search dialog will require messing around with Akonadi, Baloo and KPeople.

Knowledge Prerequisite: C++ and Qt. A basic understanding of Information Retrieval would be nice.

Mentor: Vishesh Handa and other KDE PIM community members.