Jump to content

GSoC/2013/Ideas: Difference between revisions

From KDE Community Wiki
Halla (talk | contribs)
Mgraesslin (talk | contribs)
Line 167: Line 167:


'''Mentor:''' Martin Gräßlin <[email protected]>
'''Mentor:''' Martin Gräßlin <[email protected]>
==== Project: KWin Effect Viewer ====
'''Brief explanation:''' With 4.9 KWin Effects can be written in JavaScript, but there is no convenient way to test the scripts. In this project a viewer application similar to plasmoidviewer should be developed. This could be achieved by using Xephyr and starting a dedicated KWin instance on the embedded X-Server which is just running the effect.
'''Expected results:''' Effect Viewer application to test effects including simulation of all possible Windowing events
'''Knowledge Prerequisite:''' C++/Qt/KDE development
'''Mentor:''' Martin Gräßlin

Revision as of 17:15, 16 February 2013

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

KDE Telepathy

Project: Add ConnectionManager bindings to TpQt

Brief explanation: KDE Telepathy, the IM client, uses the backend library TelepathyQt to power everything. We have library bindings for writing instant messaging clients in Qt, but not the backend connection manager to write protocols in TpQt. This has been started, but a lot of work is needed to make this finished. This will be a project in collaboration with the Telepathy project upstream at freedesktop.org.

Expected results: At the end of the summer we should have a completely working library for writing connection managers, with full unit tests.

Knowledge Prerequisite: Qt, C++ library design, unit testing, ideally usage of TelepathyQt already.

Mentor: [[email protected],[email protected],[email protected],[email protected]]

Project: Collaborative text editor powered by Telepathy Tubes

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

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

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

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

Mentor: [[email protected],[email protected],[email protected],[email protected]]

Project: Finish KTp-Active

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

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

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

Knowledge Prerequisite: Qt, C++, advanced QML

Mentor: [[email protected],[email protected],[email protected],[email protected]]

Marble

Project: Marble meets owncloud

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

Expected results:

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

And some possible extensions:

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

Knowledge Prerequisite: Qt, C++, Javascript

Mentor: earthwings at gentoo dot org


Krita

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

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

Project: Rewrite the OpenGL canvas mode

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

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

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

Project: Painting and Separation of 3D Textures

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

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

Project: Animation Support

Animations are a hot topic among Krita users. There is already a start of animation support, but the author did not finish his work. Either you continue his work, or (better) start from scratch. This entails working with animators in our community to design and implement

  • a new file format for storing animations based on Krita's native file format
  • a gui for creating and manipulating animations
  • a system to render animation frames

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.

KDE Workspaces

Project: Port kde-workspace applications away from XLib

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

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

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

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

Project: KWin Effect Viewer

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

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

Knowledge Prerequisite: C++/Qt/KDE development

Mentor: Martin Gräßlin