GSoC Ideas

From The Document Foundation Wiki
Jump to: navigation, search


This page lists the project ideas for Google Summer of Code, see the general info about LibreOffice and GSoC. All applicants are required to complete at least one easy hack.

All tasks on this page already indicate mentors for the task. New tasks on this page should be added only by those with the experience and time to invest in mentoring new developers.

Note that the LibreOffice project selects GSOC projects that are well researched and show a good understanding of the scope of the problem. It is also possible to create a project proposal not based on the ideas given below, if the application of the student shows good understanding of the problem. In fact, if you apply with one of the prepared ideas below, we expect you to show you did research beyond the abstracts given below even more.

When doing that please use this template:


=== Title of the task ===

Some detailed description of the things to accomplish.
Don't hesitate to provide details if you have some like code pointers, links to specifications, etc.

;Required skills / knowledge: C++, Reading other's code, and any other useful skill required go here.

;Difficulty: Range among easy, medium, hard

;Potential mentors
:''Joe Devel'', IRC: jdevel, mail: joe@devel.org

Please move successfully completed projects to Development/GSoC/Successfully Implemented Ideas.

General

Move the gallery code to use ZIP files

The existing gallery code (as seen in the sidebar eg.) is extremely cumbersome. It uses some hideous custom made binary file formats - which are completely un-necessary.

The code all lives in svx/source/gallery2 - is reasonably self-contained and comprises under 6000 lines of code - making this reasonably easy to work with I hope.

New themes are built with 'gengal' - but old themes are still present in the source file as un-touchable binary files. These contain many useful pieces for LibreOffice - and we need to be able to edit and extend these easily. So - parts of this project would be:

  • read and write notes on the existing gallery code.
  • add comments to each class header describing the function of the class etc.
  • extend the 'gengal' tool to extract file streams out of our old file formats and store them as individual files with annotations.
  • research the package2/ zip code, and write a tool to dump ZIP file contents.
  • package up the above streams in a suitable form - and write new package code to read these.
  • For bonus points we should be able to ingest ODP presentations with a title + a shape per slide - and thumbnail and insert these into the gallery with a simple name + the content of that shape; but that's rather more fun.
Required skills / knowledge
C++, reading other's code
Difficulty
Medium
Potential mentors
Tomaž Vajngerl, IRC: quikee, mail: quikee @ gmail.com
Michael Meeks, IRC: mmeeks, mail: michael.meeks @ collabora.com

Improve the UI testing DSL and the log files for UI actions

The UI testing is one of our newest additions to our testing frameworks. The code is split between a C++ layer wrapping our GUI toolkit and a python test framework with the actual tests. Recently some work was done to start creating log files and convert them again to python code. This covers already a good bit of our actions [1][2]. During this task the existing work should be extended and simplified.

Most of the python part of the framework can be found in the uitest/ module.

Most of the commits related to the framework are prefixed with uitest: and can be found with this git search.

The file with most of the C++ wrappers can be found here.


Required skills / knowledge
Python, a bit of C++, reading other's code
Difficulty
Medium
Potential mentors
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Improve VCL OpenGL backend

There are various improvements needed to the VCL OpenGL backend to make it faster:

  • On Linux it needs glyph caching with FreeType so it can render text faster. Also try to make it work on Windows.
  • Increase minimal version to OpenGL 3.2 core context. Currently the minimal version is OpenGL 3.0, which forces us to use the compatibility context but there is little reason not to up that to core context (most drivers nowadays should have no problem with it). However, for that the shaders need to be changed to the new format and code needs to be adapted not to use any more deprecated features.
  • Batch even more graphic calls to increase rendering speed. The most common calls are already batched but not all of them (texture based calls).
  • Minimize the (geometry) data that is send to the GPU. This was not yet optimized so a lot of data is send using floats when (for example) only bytes would be needed (or even less).
  • Improvements to texture and glyph caching algorithms (use 3D textures).
  • Support EGL.

OpenGL backend code can be found in here.

Required skills / knowledge
C++, OpenGL, reading other's code
Difficulty
Medium to Hard
Potential mentors
Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com

Tests for the VCL graphic backends

We currently have some graphic tests located here, but they are incomplete and aren't being checked. The purpose of the tests is to identify if a graphic backend works correctly, which is especially important if the backend depends on the client hardware or drivers (like for example the OpenGL backend).

Each test draws to a small surface (VirtualDevice) and evaluates if what was drawn is correct or not by looking at the pixels. As backends don't draw equally (especially when using AA), it is needed to allow for a bit of discrepancy of the values (for example sometimes a backend won't draw one pixel). In this case the test is marked as "quirky" (acceptable result, but not what is expected).

First part of this task is to write additional tests that cover more graphic functions in VCL, then make this tests run when building a backend as well as when the user uses the backend for the first time (OpenGL for example). Also allow the user to run the tests and view the results for himself (add the UI for this).

Required skills / knowledge
C++, reading other's code
Difficulty
Medium
Potential mentors
Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com

Make SVM (StarView Metafile) format independent of the VCL Metafile + tests of the format

The SVM file is a 1 to 1 dump of the content of VCL Metafile. This makes the VCL Metafile hard to modify as the SVM shouldn't change (for example to change away from the old geometry primitives in "tools" module - PolyPolyon, Polygon, Point, Rectangle,...) so to make this possible we need to separate the two. This is also very important to allow further refactoring of VCL to make it more modern (for example native 32-bit bitmaps and surfaces and to use alpha transparency and blending of the backends and not do its own thing).

This task would include to first complete the (import/export) test of the SVM format which are located here. The second part is then separate file writing/reading of the VCL Metafile to its own classes, to make them independent.

Required skills / knowledge
C++, reading other's code
Difficulty
Medium
Potential mentors
Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com

Porting / platform / infrastructure specific topics

LibreOffice Online

LibreOffice online has developed significantly during the last year, but there is still a lot to do there. This task will include changes in the LibreOfficeKit, and in the web/JavaScript part too.

The main focus will be on making the features knows from the desktop version available in the Online version too; like the pivot tables, or other.

The online work takes place mostly in the online.git reporsitory: https://cgit.freedesktop.org/libreoffice/online/

Required skills / knowledge
C++, JavaScript optional.
Difficulty
Medium
Potential mentors
Jan Holesovsky, IRC: kendy mail: kendy @ collabora.com

LibreOffice Online Admin

LibreOffice Online has an admin-console which provides a view of how active the machine is, what documents are open, what memory is in-use, and so on.

There are a number of small features required here - in particular:

  • controlling debug logging settings remotely
  • a coloring debug log browser with simple filtering
  • showing the pkill -USR1 output in the web-UI
  • adding detailed version numbers
  • presenting data sent & received per document / session
  • Complete half-baked history view in admin-console (tdf116233)

There is also work to be done to simplify the admin-console - merging the Admin.cpp and the AdminModel.cpp code to simplify.

Required skills / knowledge
C++, JavaScript optional.
Difficulty
Easy
Potential mentors
Jan Holesovsky, IRC: kenddy mail: kendy @ collabora.com
Michael Meeks, IRC: mmeeks mail: michael.meeks @ collabora.com

User Experience

The design team collected a number of ideas in in the pad http://pad.documentfoundation.org/p/UX-GSoC_Ideas. Not for all ideas mentors have committed so far. If you are interested in a task that has no mentor you would need to find someone. If the topic needs further refinement feel free to contact the UX team in order to prioritize the usability engineering. Some examples for full-featured topics:

Additions - Tight integration of extensions like GHNS!

The idea of additions is to better integrate extensions. On various places it should be possible to get more content from external storage. It is an "addition" as it rather provides presets than extensions like macros or templates; but the procedure behind might be similar. https://design.blog.documentfoundation.org/2016/11/11/additions-to-libreoffice/

Required skills / knowledge

  • C++, Reading other's code

Difficulty

  • Varying

Potential mentors

  • Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com

100 paper cuts

The student will solve a number of most-annoying issues and enhancement requests during the GSoC time. Issues are collected in https://nextcloud.documentfoundation.org/s/zraEHZxyCKBTNY7 with a rough estimation on effort.

If you want to apply for this, you should first solve one of the papercuts (pick an easy one) in advance.

Required skills / knowledge

  • C++, Reading other's code

Difficulty

  • Varying

Potential mentors

  • Samuel Mehrbrodt, IRC: samuel_m
  • Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com

Improvements to Notebookbar

Notebookbar reuses UI files definition known from Gtk+ (.ui files) as created by the Glade tool for upper part of the LibreOffice window, giving lots of freedom to the designers how to organize the UI. Current implementation has advanced during the last GSoC, but it is still incomplete: The content is cropped on resize, theming is not respected, and new functions such as style dropdown haven't been introduced yet. Beyond that, the customization via Glade is not suitable for normal users, and quick customization like toolbutton on/off is not possible.

Required skills / knowledge

  • C++, Reading other's code

Difficulty

  • Medium

Potential mentors

  • Jan Holesovsky, IRC: kendy mail: kendy @ collabora.co
  • Szymon Klos, IRC: eszka mail: szymon.klos @ collabora . com
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Block diagrams

Most expect feature in Draw is the better implementation of block diagrams. That includes the compatibility with Visio but also simplified workflows where entered data get formatted automatically. A couple of predefined styles/presets should allow to quickly switch from one diagram style to another.

Required skills / knowledge

  • (C++, Reading other's code)?

Difficulty

  • (Medium)?

Potential mentors

  • Thorsten Behrens, IRC: thorsten mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Blurry shadows

In LibreOffice the shadows are just a copy of the object. Blurring with some options is missing, and well known in competitive open-source tools like Calligra. This feature is also needed for SVG import/export.

Required skills / knowledge

  • (C++, Reading other's code)?

Difficulty

  • (Medium)?

Potential mentors

  • Tomaž Vajngerl, IRC: quikee mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Chart wizard

For experienced people, the current wizard distracts from the workflow and steps are not naturally implemented, for instance the range is selected first and then the type of chart. Over the modules we have different ways to insert charts plus the wizard design is inconsistent with other dialogs which are tabbed. Mockups

Required skills / knowledge

  • C++, UI, UNO, reading other's code

Difficulty

  • Hard

Potential mentors

  • Katarina Behrens, IRC: bubli mail: bubli @ bubli . org
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Multi-color gradient

While the area fill style dialog has been reworked nicely the ability to deal with more than two steps for gradients is missing. Furthermore, gallery items with gradients that consists of more than two colors or non-linear gradients are interpreted as a collection of lines when ungrouped making a modification impossible. First analysis showed that multi-stop gradients are loaded well but not visualized as it. The project would need to implement the draw routines as well as the UI control in the area dialog as suggested.

Required skills / knowledge

  • (C++, Reading other's code)?

Difficulty

  • (Medium)?

Potential mentors

  • Armin Le-Grand, IRC: mail:
  • UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Improve OpenPGP encryption experience

With LibreOffice 6.0, there's experimental PGP/GPG encryption support. A number of shortcomings are there still, that make using this cool feature unnecessarily hard, e.g. selecting recipients anew for every safe, or finding the right keys. Keyrings can get potentially infinitely large, so smart searching / traversing / filtering is needed. Additionally, some asynchronous querying would be great, as currently it takes several minutes to retrieve all keys for large keyrings.

Required skills / knowledge

  • C++, Reading other's code, some idea about public key crypto

Difficulty

  • Varying

Potential mentors

  • Thorsten Behrens, IRC: thorsten mail: thb@libreoffice.org
  • UX team, IRC: channel #libreoffice-design, mail: design@global.libreoffice.org

Base

Basic

Draw

Impress

SmartArt editing in Impress

SmartArt is a nice feature that allows users to quickly add charts / diagrams to presentations. We have a partial implementation as an experimental feature; the task of this GSoC would be to finish it.

At the moment, we are able to import SmartArt as a stream of shapes that is available in the pptx presentations generated by MSO 2010. We are also able to create the shapes when the stream is not available in case you enable the Experimental features Tools ▸ Options. Unfortunately:

  • The rendering of such shapes is much worse than if we use the pre-rendered stream
  • We are unable to edit the imported SmartArt

This task should first focus on improving the rendering of the shapes themselves, and then, when the student gets more familiar with the code, should add user interface for SmartArt editing.

The current experimental SmartArt import lives in oox/source/drawingml/diagram/*. The commit that introduced the functionality is Import SmartArt graphics to Impress.

Further information: The related bug in the LibreOffice bug tracker is: tdf#37932. An external extension (not nicely integrated) trying to implement at least some SmartArt functionality: SmART (Extensions/SmART Gallery)

Required skills / knowledge
C++, Reading other's code.
Difficulty
Difficult
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb@documentfoundation.org
Jan Holesovsky, IRC: kendy, mail: kendy@collabora.com

Attach animations to styles

Currently, Impress styles control most of the visual shape appearance, but not the slideshow animation effect. Which is a pity, as the styles concept is pretty powerful inside LibreOffice, and provides a nice way to change animation settings and type for a great number of objects simultaneously. For a slightly different view onto the same problem, see this bug report, and this one from the LibreOffice side.

Original patch from GSoC 2010: https://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/sd_effects_styles.diff?h=master-backup

Required skills / knowledge
C++, Reading other's code
Difficulty
Hard
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org

Rework Impress slideshow to use DrawingLayer primitives

The Impress slideshow, while being designed to only interact with Impress via interfaces, had to resort to an ugly hack to be able to render all Impress content. That was ok back in the day, but is becoming a liability these days. Nowadays, what one want to use is the DrawingLayer Primitives (https://wiki.openoffice.org/wiki/DrawingPrimitives), which means porting over slideshow/source/engine/shapes/* to use this kind of abstraction, instead of the StarView Metafile previously in use.

Required skills / knowledge
C++, Reading other's code.
Difficulty
Difficult
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

Mix and Merge Impress presentations

For the professional slide jockey, mixing a new presentation out of existing slide decks is a common task, that unfortunately Impress does not support very well. This task is about providing, possibly stand-alone, functionality to:

  • display lots of presentation files conveniently, possibly with tagging/searching functionality
  • out of existing slides, quickly create a new presentation
  • provide functionality to conveniently exchange / homogenize slide layouts and/or master pages, such that new presentation has consistent look
  • as a bonus task, be able to create virtual slide decks, by referencing other files, and have the resulting presentation automatically update, once the referenced slides are
  • can be built-in to Impress, stand-alone (but then portable across all our platforms), or web-based.

Code pointers:

Required skills / knowledge
ODF, UX, possibly c++, possibly Python, possibly web frameworks
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

Add Impress shape animations that use a real physics engine

Impress already sports a number of shape animation effects, though they start to look a bit dated in this day and age. With powerful 2D and 3D physics simulation engines available as open source, it would be cool to plug them for having slide contents interact with each other, bouncing around stuff on the screen. This task would involve:

  • integrating a suitably-licensed physics engine with LibreOffice (Box2D or Bullet come to mind)
  • interact with LibreOffice User Experience people on how to best present this in the UI
  • wire things up in the slideshow / canvas component of LibreOffice
  • be able to load and save the new effects, at least to odf files
  • in the end, have at least three effects ready to be used

Code pointers:

Required skills / knowledge
C++, basic game/animation skills useful, reading other people's code
Potential mentors
Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

Calc

Implement interface for external data source import into Calc

With more and more data in different forms it becomes more and more challenging to visualize and evaluate them. Calc could be an amazing tool to allow inspecting existing data. To allow that we would need an interface to import and more importantly update data from external data sources. The interface should be modelled similar to how the orcus interface is currently implemented and the data should be stored inside of a ScDBData (a database range). The interface would then be used together with either an existing document where you mark a range for the external data or a template document that is automatically filled. The initial work on providing some structure has already been done in sc/source/ui/dataprovider/ and in sc/source/ui/miscdlg/dataproviderdlg.cxx

This task is about extending the existing data providers and data transformations, implementing an usable UI for the feature and start working on storing the information in a file.

Required skills / knowledge
C++, Reading other's code, debugging

Difficulty: Medium

Potential mentors
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Support charts in orcus

Orcus is an external library for importing spreadsheet formats that is already used for a few features in Calc. However for now we are limited to spreadsheet support and we should extend support to charts. Orcus works by providing an interface of virtual methods that must be implemented on the client side. We try to keep the interface format independent and try to always support at least OOXML and ODF.

If the time permits we should also work on some experimental integration of the chart import code into LibreOffice.

The spreadsheet interface is mostly in include/orcus/spreadsheet. The chart interface should be similar.

Required skills / knowledge
C++, Reading other's code, debugging, Reading specifications

Difficulty: Medium

Potential mentors
Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Implement table styles

Calc so far lacks real table styles, which for example can be seen in Impress tables, with formatting of header row, header column, banded rows and columns, total row, rightmost column, ...

The existing old technology Format → AutoFormat Styles are visually similar, but very inefficient in that they apply individual attributes to individual cells, which a) is slow, and b) bloats the document size, and also can't cope with hidden rows or columns to keep a visually stable table style layout.

See also tdf#121307

Required skills / knowledge
C++, Reading other's code, Debugging, Understanding the concept of different layers of cell attribution, Having an idea of how a single attribute with one value could be used for this
Difficulty
Hard
Potential mentors
Eike Rathke, IRC: erAck, mail: erack@redhat.com

Implement chart styles

Chart styles allow to quickly apply the same formatting presets to different charts and would allow us to more easily change charts. Currently all chart formatting is directly applied and this task would be to add one additional layer of indirection into the chart formatting. Most of the framework for direct formatting in charts can be extended to support chart styles. A bit of analysis can be found at https://wiki.documentfoundation.org/Chart_styles

Required skills /knowledge
C++, Reading other's code, Debugging
Difficulty
Medium
Potential mentors
Markus Mohrhard, IRC: moggi @ #libreoffice-calc, mail: markus.mohrhard@googlemail.com

Writer

Document Themes

Document themes are a simple way to allow users to quickly & consistently restyle the entire document. There is an implementation of this in MSO, and also Calligra plans to something in this regard, so this task actually consists of 2 parts:

  • Implementing user interface for the feature
  • Implement the ODF support for that

More ideas about the feature you can get by reading http://blogs.msdn.com/b/jensenh/archive/2006/02/22/537054.aspx and https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes .

The import code for DOCX is here: https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml, you might need to change also https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/dmapper

For XLSX and PPTX, it resides in https://cgit.freedesktop.org/libreoffice/core/tree/oox/source

Required skills / knowledge
C++, Reading other's code, reading specifications :-)
Difficulty
Hard
Potential mentors
Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Tomaž Vajngerl, IRC: quikee mail: tomaz.vajngerl @ collabora.co.uk

Help system

Filters

Improve Zoner Draw import filter

libzmf, a library for import of Zoner Draw documents, was implemented as a GSoC 2016 project. Currently the library only supports documents created by versions 4-5. There are two goals in this task:

  • handle some of the missing features (blending, warping of the bounding rectangle);
  • add support for the file format produced by versions 2-3.

Both formats have been almost completely reverse-engineered.

Required skills / knowledge

  • C++, Reading other's C++ code (to understand the existing libzmf code)
  • Python (for OLEToy) is welcome, but probably won't be needed

Difficulty: medium

Potential mentors:

  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com

Improve Adobe Pagemaker import filter

libpagemaker, a library for import of Adobe Pagemaker documents, was implemented as a GSoC 2013 project. In the current state, the library only supports documents created by versions 6.5-7.0 on Windows. Documents of version 6.0 should be opened more-or-less correctly, but the support has never been specifically tested. Documents created on Mac are never opened correctly because of many oversights in the code.

The goals of this taks are to fix import of Mac 6.5-7.0 files, implement some missing features and add support for older versions, both Mac and Windows (starting at 6.0 and proceeding to older ones until we run out of time :-)

We will use OLEToy for any necessary reverse-engineering. We will also create documents for regression testing for all versions we add support for.

Required skills / knowledge

  • C++, Reading other's C++ code (to understand the existing libpagemaker code)
  • Python (for OLEToy)

Difficulty: medium

Potential mentors:

  • David Tardon, IRC: dtardon, mail: dtardon@redhat.com
  • Fridrich Strba?, IRC: Fridrich, mail: fridrich.strba@bluewin.ch

UNO

UNO is the LibreOffice component model, cross-language and intra- as well as inter-process. It is somewhat similar to Corba and COM. It is used to extend LibreOffice via document-related scripts and more general extension packages, as well as to use LibreOffice functionality remotely from another process.


Rust UNO Language Binding

UNO's cross-language abilities are implemented by bridging between various language-specific environments and a binary runtime representation (with a C API). Next to C++, Java, and Python, it would be great to have such a bridge also for a great language like Rust.

One aspect is to use Rust FFI to interface with the binary UNO C API. Another is to design the Rust representations of the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons), so that this language binding can not only be used to interact with existing LibreOffice services written in other languages, but also to create new services in Rust. A third aspect could be to create a pure Rust implementation of the UNO remote bridge protocol.

Some documentation pointers are:

Some code pointers are:

Required skills/knowldege: Rust, interfacing to low-level C/C++, working against formal specifications

Difficulty: medium to hard

Potential mentors:

  • Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
  • Michael Stahl, IRC: mst___, mail: mst AT libreoffice DOT org
  • Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen AT canonical DOT com

LUA UNO Language Binding

UNO's cross-language abilities are implemented by bridging between various language-specific environments and a binary runtime representation (with a C API). Next to C++, Java, and Python, it would be great to have such a bridge also for a small, lightweight scripting language like LUA.

LUA is small (few K lines of C), and written with the goal of embedding in mind:

Besides hooking LUA up with LibreOffice's UNO subsystem, a taker for this project would need to map the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons) to suitable LUA types, so that this language binding can not only be used to interact with existing LibreOffice services written in other languages, but also to create new services. LUA should be expressive enough to permit that (its dynamic typing helps a lot there), just for exceptions and error handling, some extra thoughts might be needed:

Some code pointers are:

Required skills/knowldege: LUA, interfacing to low-level C/C++, working against formal specifications

Difficulty: medium to hard

Potential mentors:

  • Michael Stahl, IRC: mst[_]*, mail: mst AT libreoffice DOT org
  • Thorsten Behrens, IRC: thorsten, mail: thb AT libreoffice DOT org
  • (Bjoern Michaelsen, IRC: Sweetshark)

Tooling

Integrate .ui dialogs with translation tooling/string search webservice to help translators

Translators often have a hard time determining the context of a string to translate. It would be great if translators would be able to search for a string and have it presented in the context of the UI, a picture of a dialog for example.

Required skills / knowledge python (when integrating into pootle), java (when integrating into opengrok) or php or other suitable framework for the user-facing part, reading c++ code to identify where strings come from (not all strings are in dialogs) and GTK/glade ui definitions as the basis for the rendered dialog, scripting/makefile stuff to automate updating of the data

Difficulty: easy (when only limiting yourself to the glade dialogs) to medium (depending on the level of integration with the current tools: pootle as the platform where translation happens or opengrok where the source code is indexed)

Potential mentors:

  • Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org

Ideas without a mentor

A number of ideas from previous years can be found at the Development/GSoC/Ideas without a mentor page. Please note that you need to find a mentor willing to mentor the task. There is no guarantee that anyone in the community is going to mentor one of these tasks this year.