Projects/Summer of Code/2009/Ideas

From KDE TechBase
< Projects‎ | Summer of Code/2009
Revision as of 09:07, 17 February 2009 by Majewsky (talk | contribs) (ideas for Kolf 2 projects)

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

Amarok

A KDE music manager and player.

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

Project: DLNA/UPnP Support

Brief explanation: Using the UPnP protocol users can, for example, share music from their Vista computer to a PS3. Amarok lacks any sort of UPnP support. Being able to act as a client or possibly a UPnP media server would be useful. In addition to that controlling a UPnP Media Renderer from within Amarok is possible with framework support.

The Coherence server would likely be used since it is also intended to be used by a KIO slave.

Expected results:

  • Using the Amarok Collection framework, create a plugin which allows Amarok to browse, search and play music off of a UPnP share. Playing music may use the UPnP KIO-slave, but more advanced functionality requires Amarok to handle this directly.
  • Allow Amarok to share it's collection with other devices or control other devices via UPnP. This is secondary priority but it may be pretty easy with Coherence.
  • Control UPnP Media Renderers (DMR: Digital Media Renderer device class in DLNA) from within Amarok.

Material Prerequisite: Some UPnP devices or computers to test with. Good excuse to buy a PS3. If you live in Europe a Philips Streamium DMR can be borrowed.

Knowledge Prerequisite: C++ and Qt. Coherence uses Python and D-Bus but doesn't need to be hacked on in the scope of this project.

And of course, understanding of UPnP networking and devices wouldn't hurt!

Mentor: Stecchino (bart.cerneels at kde dot org)

Project: New meta-applets for the Context View

Brief Explanation: The Context View (CV) is currently used to display multiple applets that expose various information. However, due to the fact that each applet displays a certain type of information from one data source, there is significant amount of wasted space, and it is hard to show much more than 3 different pieces of data at once.

Meta-Applets are large applets that integrate date from multiple data sources in order to display more semantically related information coherently and efficiently. This could mean, for example, an applet that brings together lyrics, artist info, upcoming concerts, and related songs/artists.

More info is available here on the amarok wiki

Expected Results: Two or three (to be discussed with mentor in application writing process) applets that elegantly execute the ideas discussed above.

Knowledge prerequisite: Knowledge of C++ is required, and some familiarity with Qt is helpful (especially QGraphicsView) but not necessary.

Mentor: Leo Franchi (lfranchi AAAT kde DT org), or other Amarok developers. Contact at [email protected] or #amarok on freenode.

Project: Code regression test suite, implemented with QtScript

Brief explanation: Amarok currently has no automatic code regression testing ("unit testing") in place at all. We very much need such a system in place (for as many components as possible), as we sometimes accidentally break certain components of the program by extending the code.

Expected results: Code regression test suite for Amarok 2, implemented as one "Amarok-Script" (JavaScript), and internally split into multiple separate files and components, so that it would be possible to run arbitray tests (or the full suite) with very little effort, and no compiling, at any time. A requirement would also be testing of the collection scanning code (with test case collections), and testing of GUI correctness with the QTest library.

Also see: http://amarok.kde.org/wiki/Development/Scripting_HowTo_2.0

A plus would be the generation of suitable statistics (possibly with document export), and possibly a visual representation of the data.

Material Prerequisite: Amarok 2 trunk, KDE SVN account, git. Linux, OSX, or Windows.

Knowledge Prerequisite: C++, Qt, KDE-Libs, QtScript (JavaScript), SVN, git, code testing.

Mentor: Potentially one of several. Contact the amarok mailing list or ask in our IRC channel #amarok

Project: Multilevel playlist sorting and sorting GUI

Brief explanation: In Amarok 2.1, the layout of the playlist will be very configurable, being able to show as much or as little information about each track as each user might wish. Currently however, it is lacking an advanced system for sorting in the playlist, something that many users comming from Amarok 1 are missing. While simple sorting is relatively easy to do (and has already been partly implemented) we would like to aim a bit higher with Amarok 2.

Expected results: A proxy model allowing the tracks in the playlist to be sorted using an arbitrary number of "layered" sort criteria. for instance, a sort setup could be "artist-album-tracknumber" This would sort all tracks by artist, then sort the tracks from each artist by album, and finally the tracks from each album based on track number. Once this model is working, a GUI is needed for making this functionality easilly avaialble to the user. Ideally this gui should tie in well with the playlist layout and search/filter stuff. Also, all track navigators (the classes that determines the order of playback, such as normal, random, random album and so on) need to be updated to use and work correctly with the new proxy model.

Material Prerequisite: Amarok 2 trunk, KDE SVN account, Linux, OSX, or Windows.

Knowledge Prerequisite: C++, Qt, KDE-Libs, SVN/git.

Mentor: Nikolaj Hald Nielsen <[email protected]> or contact the amarok mailing list or ask in our IRC channel #amarok

Project: Playlist and Collection synchronization

Brief explanation: Mediadevices and services can add tracks and playlists to Amarok. Synchronization would automatically copy over tracks between the main Amarok Collection and devices or services or even between each other, either for a single playlist or the complete collection. An algorithm needs to be implemented that does this automatically in a fast and efficient way with minimal intervention needed by the user.

Expected results: Playlists set up on both the local collection and a portable mediaplayer will get synchronized the moment the player is connected.

Material Prerequisite: Amarok 2 trunk, KDE SVN account, Linux, OSX, or Windows.

Knowledge Prerequisite: C++, Qt, KDE-Libs, SVN/git.

Mentor: Bart Cerneels <bart.cerneels at kde dot org> or contact the amarok mailing list or ask in our IRC channel #amarok

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.

Project: Analyzer Support

Brief explanation: Applications such as Amarok and Dragon Player cannot have an analyzer or visualizations since they use Phonon which does not yet have the functionality to do it. The analyzer is the little bar graph thing which bounces around while music is playing. Users like it as its pretty and gives them a visual indication of their music playing.

Expected results: As this project is working on extending a library, it has three parts: the Phonon library itself, a Phonon backend, and an application. The Phonon library would need the new API calls. At least phonon-xine and preferably 1 or 2 other Phonon backends must then implement the new API. An application like Amarok or Dragon Player should be used to demonstrate the use of the new API.

Knowledge Prerequisite: C++ and Qt. Experience with Xine or GStreamer is probably useful.

Mentor: Ian Monroe (contact on the Amarok mailing list) or possibly another Amarok or Phonon developer.

Marble

A desktop globe and map application. Also provides a map Qt Widget.

Website - Mailing list

Project: Satellite navigation

Brief explanation: Satellite navigation devices have become widely used and the quality of openstreetmap data is becoming high, with some cities completely mapped already. Providing satellite navigation would be a useful desktop app for many as well as adding appeal for the use of KDE in embedded devices.

It also opens the possibility to bringing many of the free software ideals to interaction with the real world such as collaborative/social POIs.

Expected results: The project would aim at getting a basic satellite navigation application running. The most basic features required would be getting the current location from a GPS device and providing route calculation to a destination.

The AndNav project (http://andnav.org) has already achieved something similar for Android so it could be a point of reference for how to use OpenStreetMap data to achieve this.

Knowledge Prerequisite: C++ and Qt. Experience with GPS devices under linux would be beneficial. Knowing java may also be of benefit in order to study the AndNav implementation.

Mentor: I (Alan Jones, skyphyr using gmail) am willing to mentor, but not having any GPS or Marble experience there is most likely somebody far more suited to undertake this role.

Comment from a Marble Project guy: Alan, please get in touch with the Marble Project. Our mailing list is [email protected]. We'd like to support this project if a student is willing to do it.

Project: Add Time support to Marble

Brief explanation: Wouldn't it be great to be able to see the world at different times in Marble? Like having a slider which would give you the ability to browse through the time? Marble's internal datastructure is modelled after KML. But support for time-related tags is missing.


Expected results:

  • Having a GUI on the map and as a QWidget based dialog which allows people to "slide" through time.
  • Implementation of the KML <TimePrimitive> and <TimeSpan> tag: Creating the KML-handler and needed data classes for the GeoData parser.
  • Having a central "internal" clock which the current view would be based on.
  • Porting existing features (like the starry sky and the sun shading) over to the new class design.

Knowledge Prerequisite: C++ and Qt. Knowledge about KML is not necessary but would be appreciated.

Mentor: Torsten Rahn / Patrick Spendrin.

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: C++ Refactoring Support

Brief explanation: C++ support in KDevelop is already highly advanced, often equalling or surpassing what the user and compiler understand about the code. A few refactoring tools have been developed already, but they have been constructed in a crude fashion, generating code via string concatenation.

This project would aim to create a new system to implement refactoring tools, and to create, test and deploy several advanced refactoring tools for c++.

Expected results: A library would be created to enable refactoring based on the c++ AST (abstract syntax tree). A reverse parser (AST to code) already exists, but classes would be created to allow programatic manipulation of an AST. Optionally this library would also cover a generic framework based on the duchain which would be re-usable by other languages and make refactoring plugins easier to develop and partially shareable between languages.

See the Code Generation Design documents for the initial plan for this project.

Knowledge Prerequisite: C++ and Qt. Experience with parsers would be a bonus.

Mentor: Hamish Rodda (Definition-Use chain code creator) rodda at kde/dot/org, possibly also David Nolden (DUChain guru)(to be confirmed)

KStars

KStars is a Desktop Planetarium for KDE. It displays a map of the sky and provides a lot of tools to learn astronomy, or to calculate and predict astronomical phenomena. See [KStars Homepage] for more information.

Project: Community Integration for KStars

Project Information: KStars is a desktop planetarium program for KDE.

Brief explanation: Amateur Astronomy (which is one of the important use-cases of KStars) is typically done in communities. KStars permits users to save their own observing logs. It would be nicer if the user could share his observing logs with other users and see other observers' logs within KStars. It would also be nice if KStars had a map (using MarbleWidget) to display various Astronomy-related establishments (like amateur associations, observatories, research institutes). Another possible idea could be an observing report generator that would generate a report based on observing logs, and at the user's will, share it / post it on the internet.

Expected results: Implement some features that will make it easier for users to collaborate, as suggested above.

Knowledge Pre-Requisite: Required: C++. Prior knowledge of KIO_HTTP will help.

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: FITS Image Overlay on the sky map.

Project Information: KStars is a desktop planetarium program for KDE.

Brief explanation: It would be great if a FITS image could be overlayed on the sky map so that the field drawn by KStars could be compared with the field in the FITS image. This would be of great benefit to observational astronomers, astrophotographers and comet / asteroid observers. An extension would be to download a DSS image using KStars' already existing tool and map it onto the sky map. The support of shapes like ds9 region, annotations on the sky, etc. could also be added.

Expected results: Functionality to overlay a FITS image or a DSS image obtained through KStars on to the sky map.

Knowledge Pre-Requisite: Required: C++. Prior knowledge of the FITS format and cfitsio library will help.

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: Tools for Eclipses

Project Information: KStars is a desktop planetarium program for KDE. Currently, it can predict Solar Eclipses (using the Conjunctions tool), but cannot plot trajectory of shadows, or predict Lunar Eclipses.

Brief explanation: The project's primary goals are to include simulation and prediction (maybe using the existing Conjunction backend) of Lunar eclipses, and to create a tool to mark the trajectories of Solar and Lunar eclipse shadows on a map of the earth, including marking of totality, partial eclipse and annular eclipse. Something similar to this: [1]

Expected results: A complete set of tools to deal with eclipses.

Knowledge Pre-Requisite: C++

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: KStars: Prettyfication

Project Information: KStars is a desktop planetarium program for KDE. The display is interactive, but it could be made more beautiful.

Brief explanation: We often get good suggestions for making KStars look better. Choose any of the following ideas: realistic rendering of asteroids and comets (including tails!); texture-mapping of the sky (this would mostly allow a photorealistic Milky Way); texture-mapping of planets; realistic sky-lighting effects (i.e., sky is blue in the daytime, gets gradually darker and colorful at sunset). One could also think of using Qt-GL rendering optionally.

Expected results: Successful implementation of any of these ideas to make KStars more beautiful.

Knowledge Pre-Requisite: Required: C++.

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: Printable star charts

Project Information: KStars is a desktop planetarium program for KDE. It already has a print feature, but the printed chart could be much better.

Brief explanation: A printed star chart should at least include a legend explaining the symbols, and provide some information on the location of the user, the time and date, etc. The user would ideally be able to annotate the chart in various ways.

Expected results: Significant improvements to the printed star charts in KStars.

Knowledge Pre-Requisite: Basic programming skills, ability to quickly learn QPainter API.

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: Many Moons

Project Information: KStars is a desktop planetarium program for KDE. It currently includes Earth's moon and 4 of Jupiter's moons.

Brief explanation: Generalize the JupiterMoons class to encapsulate any planet's Moons. The project will require some research to identify a public source of orbital data for planetary moons, most likely from a NASA webpage.

Expected results: Implement moons for at least Mars, Jupiter, Saturn, and Pluto with the new system.

Knowledge Pre-Requisite: Required: C++. The project doesn't require much contact with Qt/KDE APIs, and the existing JupiterMoons class can be used as a template.

Mentor: Akarsh Simha <akarsh DOT simha AT kdemail DOT net>

Project: Support many catalogs

Project Information: KStars is a Desktop Planetarium for KDE. Currently KStars loads some star catalogs that are made available in a KStars native format.

Brief Explanation: KStars currently loads Tycho-2 and parts of USNO NOMAD catalog of stars. These catalogs are required to be in KStars' native format which uses the Hirearcheal Triangular Mesh to index regions in the sky. Popular star catalogs like USNO A organize stars and divide the sky into regions differently. Most users of astronomy software typically have one of these popular catalogs downloaded, and it would be great if KStars could support them somehow. While ability to read the non-native catalogs straight off is desirable, tools to convert these catalogs into KStars' native format would also help.

Expected Results: Implement support for at least the most popular catalogs like USNO-A2.0, Stellarium's Extra catalog, Cartes du Ciel's Tycho and Tycho-2 catalogs.

Knowledge Pre-Requisite: Required: C++. Ability to read documentation and quickly understand the existing code and ability to deal with binary files will help.


KOffice

Project: support for versionned OpenDocument files.

Explanation: The OpenDocument specification doesn't include support for multiple versions of the same document in a single file. But that feature is supported by OpenOffice.org. The objective for this Summer of Code is to add support for that versionning system in KOffice. Since KOffice shares the OpenDocument loading/saving code, it should be possible to add this support in every KOffice application in one Summer of Code. The lack of specification for this feature will have to be fixed with the OASIS OpenDocument TC.

Expected results: Being able to load a specific version of a file, and create/manage versions

Knowledge Pre-Requisite: C++

Mentor: Pierre Ducroquet <pinaraf AT pinaraf DOT info>

KWord

Project: Collaborative editing of documents over a network.

Explanation: Make it possible for two or more users to work at the same document in KWord at the same time over a network. Both users would open the same document, and changes made by each user are synchronized to the other user's editing session.

Project: Version control integration.

Explanation: Integrate version control system support with KWord to allow easy control over revisions of documents. It should be possible to connect with remote revision control systems, to allow collaborative work on projects, similarly to how software is developed. It should be easy for the user to browse through the history of document versions in the version control system, to see what has changed. CVS, Subversion and git should be supported.

KPresenter

Project: Powerpoint import.

Explanation: From some years ago another gSoc project implemented the basis for powerpoint import, but it was never finished. So there is a good basis to start from. From a quick look it seems like styles support is the thing missing most to complete the work, however a thorough analysis of what is there and what is not needs to be done. And then the actual work needs to be done too, obviously

Krita

Project: Sketch-pad interface for Krita

Project Information: Krita is a large and complex application built around a sophisticated painting engine. The goal of this project is to create a new interface around the Krita engine, specialized for quick sketching.

Expected results: This project should implement a new interface around Krita, presenting the user a single-layer plus tracing paper interface with a single freehand sketching tool. Easy to use and graphic color and paint operation (brush, pencil, eraser etc.) interface elements must be designed and implemented.

Knowledge Pre-Requisite: C++

Project: Shader filters and generators for Krita

Project Information: Some initial work has already been done to make it possible to write filters in the OpenGL shading language. This project should take that initial code as a basis and implement a fully functioning plugin for Krita that allows filters and shaders to be executed on images in any colorspace.

Expected results: The plugin should have a finished user interface and make it possible to experiment with shader filters in an interactive way. Example filters must be implemented.

Knowledge Pre-Requisite: C++, OpenGL.

Project: Animation support

Project Information: There is no support at all in Krita for animated images such as GIF or MNG or for working with images in an animation context, such as textures or backgrounds in applications like Blender. The applicant should first investigate user needs and use cases and then implement support in the user interface and in the import/export filters.

Expected results: A user-friendly way of working with animated images (i.e., not by making each frame a layer), but e.g. a docker that shows the the animation running in thumbnail format. Import/export filters for relevant file formats.

Knowledge Pre-Requisite: C++

Project: PSD and Gimp plugins

Project Information: Krita is powerful enough to handle nearly all that the Gimp and Photoshop are capable of saving. This project is about creating dedicated file import/export filters that can handle as much of these file formats as possible, possibly through the use of existing libraries.

Expected results: 4 plugins: psd import/export and xcf import/export. These plugins should be able to handle complex files in all supported colorspaces. Ideally the project would also deliver a library to convert PSD/XF to/from Open Raster files.

Knowledge Pre-Requisite: C++

Project: Workspaces

Project Information: A workspace is a loadable package of settings that finetune Krita for a particular purpose. A workspace could contain additional plugins (like an image browser plugin for batch operations) and a subset of resources. Example workspaces could be batch-editing of images, editing of animation sequences or painting or sketching.

Expected results: the user interface and framework to make packages of plugins and resources that users can switch between. Also extra plugins to extend krita in areas like batch processing that do not exist yet.

Knowledge Pre-Requisite: C++, artistic workflow

Project: Kipi and digikam plugins compatibility

Project Information: Kipi and digikam provide lots of interesting plugins for working with 8 and 16 bit RGBA images. It would be great to be able to re-use those plugins from within Krita.

Expected results: Two plugins that load kipi and digikam filters into two new menus in the filter menu. Code to convert Krita layers to the digikam image representation and back, taking care of icc profiles and other niceties.

Knowledge Pre-Requisite: C++, artistic workflow

KDE PIM

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

One of the current challenges is utilizing the new cross-desktop PIM infrastructure called Akonadi.

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: Akonadi Janitor Agent

Brief explanation: An Akonadi Agent is a service process for performing tasks on data provided through the Akonadi server.

The task of a Janitor agent would be to keep the user's PIM data neatly organized, for example deleting news feed items which are above a certain age and not flagged, moving last week's mail to an archive, etc.

Expected results:

  • An Akonadi Agent capable of managing actions on Akonadi collections triggered by various criteria
  • At least fully working implementation of actions based on "Expire" criterias for mail, e.g. delete mail above certain age, move/copy to different collection, etc
  • GUI for configuring actions and their trigger criteria.

Knowledge Prerequisite: C++ and Qt. Ideally would already have gone through the Akonadi Resource Tutorial since Resources are a specialized form of agents and thus share some of the API and characteristics.

Mentor: Kevin Krammer (kevin dot krammer at gmx dot at)

Project: Alternative Akonadi Client Library

Brief explanation: Akonadi has a server/client like architecture where clients such as applications (but also resource) connect to a service and communicate with it through a suitable protocol.

Currently this is implemented for KDE in library called libakonadi-kde, however it is desirable to have additional implementations to be suitable for other library stacks, e.g. GLib/GObject based ones.

Expected results:

  • A non-KDE based, preferably GLib/GObject based, Akonadi client library which
    • can connect to a running Akonadi server
    • fetch Akonadi collections
    • fetch Akonadi items
    • receive Akonadi change notifications (D-Bus based)
  • A set of demo programs using the library which can
    • recursively list (id and content MIME types) collections
    • list (id and MIME type)oif items in a collection
    • get the raw payload of an item

Knowledge Prerequisite: Depends on the chosen language and toolstack, e.g. C/Vala and GLib/GObject knowledge for a GLib/GObject based implementation.

Mentor:

Project: Akonadi Consistency Checker

Brief explanation: Akonadi provides a structure of collections and items, similar to folders and files of a filesystem. Similarly the internal structures have to follow certain constraints which must not be violated. Nevertheless, this can happen as result of bugs, hardware failures, power loss and a million other reasons.

Filesystem checks exist to detect and possibly fix such situations. Such functionality would also be desirable for Akonadi.

Expected results:

  • A consistency checker (built into the Akonadi server or stand-alone) that performs an extensible set of checks on the internal data structures of the Akonadi server, such as:
    • items belong to existing collections
    • collections are child collections of existing collections
    • the collection tree is non-cyclic
    • every collections is owned by an existing resource
    • collection sub-trees are owned by the same resource
    • every item payload part belongs to an existing item
    • content type constraints of collections are not violated
    • ...
  • each check should be accompanied with recovery code, such as moving orphaned items into a lost+found folder
  • integration into Akonadiconsole
  • integration into unit-tests

Knowledge Prerequisite: C++ and Qt mandatory, SQL/database knowledge would be useful.

Mentor: Volker Krause <[email protected]>

KDE on Windows

Solid API backend

Brief explanation: The porting efforts to make KDE available across platforms do need some backends for system dependent tasks. One of the KDE libraries that bundles this is Solid.

Expected results: You implement a backend for the Solid API using WINAPI. It has to work with both MinGW and MSVC compilers. Not every function is required, but the basic functionality (network access, removable drives/harddisks and power) should be implemented.

Knowledge Prerequisite: Windows API and C++/Qt. You should be able to set up the development environment yourself and be familiar with it.

Mentor: Carlo Segato (brandon dot ml at gmail dot com) or Patrick Spendrin (ps_ml at gmx dot de)

KDE Games

Kolf 2 landscape object

Brief explanation: Kolf 2 is the second incarnation of KDE's minigolf game. We are currently rewriting it from scratch to take advantage of the powerful technologies provided by Qt 4 and KDE 4.

Expected results: The task in this project is to create an object (or multiple objects) that provide(s) landscape textures, slopes, puddles and sand bunkers.

If you finish this task before the end of the summer, you can fill the remaining time by porting as much game objects from Kolf 1 to Kolf 2 as possible (e.g. windmills, floating blocks, signs or bumpers).

Knowledge Prerequisite: C++/Qt. Experiences in graphics programming with Qt will definitely help, as you are expected to implement 2D rendering for the landscape object.

Mentor: Stefan Majewsky (majewsky at gmx dot net) – Please contact me before applying for this task to let me help you to improve your application.

Kolf 2 editor interface

Brief explanation: The minigolf game Kolf provided an editor interface from the beginning, to allow the users to create custom courses. For Kolf 2, we are rewriting the game engine and can therefore not use the old editor code.

Expected results: Your task would be to create an editor interface (may be embedded in the game, or a standalone application). A few basic parts are available, and the Kolf 2 engine supports generic methods to provide data to editor interfaces, and display editor overlays on the game view.

If you finish the editor interface before the end of the summer, you can fill the remaining time by porting as much game objects from Kolf 1 to Kolf 2 as possible (e.g. windmills, floating blocks, signs or bumpers).

Knowledge Prerequisite: C++/Qt. Experiences in model/view programming with Qt will be of good use.

Mentor: Stefan Majewsky (majewsky at gmx dot net) – Please contact me before applying for this task to let me help you to improve your application.

Retrieved from "https://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2009/Ideas&oldid=38689"