GSoC Ideas

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

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

Goal(s) - the expected outcome of the project.

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

;Size: 90, 175 or 350 hours

;Difficulty: Range among easy, medium, hard

;Potential mentors
:''Joe Devel'', IRC: jdevel, mail: {{nospam|joe|devel.org}}

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

Tooling

Tests

While there are some automated tests for LibreOffice, there are not nearly enough. Adding more and better tests helps developers who work on the code to be more productive by allowing them to find regressions as early as possible.

More and better tests, porting Java tests to C++/Python

There is some support in LibreOffice for automated tests, both at the level of unit tests, and at the level of system tests that drive a full LibreOffice instance. Currently tests can be written in C++, Java, or Python. Various new automated tests should be developed to improve the test coverage.

Tests written exclusively for Java (eg. the JUnit framework) should be ported to C++ so that they can execute much more rapidly. Similarly, tests that do remote control of an existing LibreOffice instance, should be re-factored to run inside that instance to make debugging much easier.

Goals

Port tests from Java to C++ (or Python, in some cases)

Required skills: C++, Java, or Python; for unit level tests reading other's code
Size: 350 hours

Difficulty: Medium

Potential mentors: Hossein Nourikhah, mail: hosseinlibreoffice.org; Xisco Fauli, mail: xiscofaulilibreoffice.org

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:

Variable units on numerical input

LibreOffice allows to change the unit from cm to inch or point, etc. but only globally. Some workflows make it necessary to deal with different units at the same time. For instance the page size in inch, positioning of objects in centimeter, and size in points. The proposal is to allow switching the unit on the control.

Mockup: https://bug-attachments.documentfoundation.org/attachment.cgi?id=130628

Enhancement request on Bugzilla (and the various See Also tickets)

Goals:

derive a new control from spin edit that allows switching the unit
ideally but optionally remember the unit per control
consider solutions to change the precision per adding decimal places
replace the existing numerical spin edit controls

Required skills / knowledge: (C++, Reading other's code)?

Size: 350 hours

Difficulty: (Medium)?

Potential mentors: Andreas Heinisch, mail: andreas.heinischyahoo.de; Heiko Tietze, IRC: htietze, Mail: heiko.tietzedocumentfoundation.org

Remember window size per document

LibreOffice remembers the window size per module and it's possible to have, for example, a Writer document in landscape next to a portrait sized Calc sheet. However, closing the modules brings you back to the start center which overwrites the module size. And the size/position is not stored per document, which is a major problem for many users.

Ticket on Bugzilla.

Goal:

Restore the window size per module from the document

Required skills / knowledge: (C++, Reading other's code)?

Size: 175 hours

Difficulty: (Easy)?

Potential mentors: Andreas Heinisch, mail: andreas.heinischyahoo.de; Heiko Tietze, IRC: htietze, Mail: heiko.tietzedocumentfoundation.org

Improve snapping and object selection

Snapping in LibreOffice is a bit awkward, and doesn't work as expected in some cases. There is also no advanced snapping supported (taking into account multiple object positions and distances), which would make object position and sizing much easier for the user. This idea involves investigating the existing implementation for snapping in the svx module and work on it.

Goal:

Make snapping and object selection pleasant to use.

Extended goal for this idea is to look into object selection and handles rendering, consistency and UX. In some cases the selection and selection handles aren't properly rotated with the object, sometimes an outline of the selection isn't rendered or rendering could be improved.

Required skills / knowledge: (C++, Reading other's code)?

Size: 350 hours

Difficulty: Hard

Potential mentors: Tomaž Vajngerl, IRC: quikee, mail: quikeegmail.com

Base

Basic

Draw

Impress

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

Goal:

Make styles animatable.

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

Size: 350 hours

Difficulty: Hard

Potential mentors: Thorsten Behrens, IRC: thorsten, mail: thbdocumentfoundation.org; Katarina Behrens, IRC: bubli, mail: bublibubli.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.

Goal:

Get rid of ugly hack for rendering Impress content in slideshows by porting code to use DrawingLayer primitives.

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

Size: 350 hours

Difficulty: Hard

Potential mentors: Thorsten Behrens, IRC: thorsten, mail: thbdocumentfoundation.org

Calc

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.

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.

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 and a lightweight scripting language like LUA and latest version of .NET, which is cross-platform.

Rust UNO Language Binding

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:

bridges/source/jni_uno as an example of an in-process UNO bridge (for Java, via JNI)
binaryurp as an example of a remote UNO bridge (in C++)

Goal:

Make it possible to use LibreOffice's UNO API with Rust.

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

Size: 350 hours

Difficulty: Medium to hard

Potential mentors: Stephan Bergmann, IRC: sberg, mail: stephan.bergmannallotropia.de; Michael Stahl, IRC: mst___, mail: mstlibreoffice.org; Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsenlibreoffice.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.