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.
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.heinisch
yahoo.de
- Heiko Tietze, IRC: htietze, Mail: heiko.tietze
documentfoundation.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.
Goal:
Restore the window size per module from the document
- Required skills / knowledge
- (C++, Reading other's code)?
- Size
- 175 hours
- Difficulty
- (Medium)?
- Potential mentors
- Andreas Heinisch, mail: andreas.heinisch
yahoo.de
- Heiko Tietze, IRC: htietze, Mail: heiko.tietze
documentfoundation.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: quikee
gmail.com
Re-design Notebookbar using Native Toolkit Widgets
The task here is to redesign the Notebookbar to use vcl weld mechanism instead of custom widgets. The issue is filed as tdf#163988 in Bugzilla.
Currently, although Notebookbar uses Glade UI files, it uses custom widgets, and most of the logic is done in C++ code.
Although the result looks nice with GTK3 and some other UI plugins, it has some drawbacks as described in tdf#163988. Specially in GTK4, the result is not interesting. Also, changing the Notebookbar in the Glade interface designer is not easy/possible with this approach.
The task here is to re-design the Notebookbar, using native toolkit widgets and make sure that is usable with VCL weld mechanism. Doing modifications in the C++ code to make it usable in LibreOffice UI is not part of this task, so that people who only know how to design, but are not familiar with C++ can also do the task. To make the result usable with LibreOffice, additional coding/refactoring is needed which does not fit into this project.
One can start by creating a dialog box with GtkNotebook
, and then add appropriate icons and other GTK widgets to reach to a reasonable UI, comparable to what is available with the custom widgets.
Please note that not each and every GTK widget is supported by VCL weld, so you have to go step by step to make sure that the result works well with VCL weld mechanism.
A preview can be generated by both glade-previewer -f notebook.ui
and also by using the ui file with minweld example. One may test the result, after putting the UI file in instdir/share/config/soffice.cfg/
and changing the minweld
example to reflect the name of the UI and the ID of the dialog.
./bin/run minweld
Goal:
Re-design Notebookbar using native widgets.
- Required skills / knowledge
- UI Design, Glade UI designer, Reading other's code
- Size
- 175 hours
- Difficulty
- Medium
- Potential mentors
- Hossein Nourikhah, IRC: hossein, mail: hossein
libreoffice.org
New dialog to edit Table Styles
LibreOffice Writer and Calc have a set of built-in table styles. For instance, in Writer, when the user inserts a new table, they can go to Table - AutoFormat Styles to select which style to apply to the table.
To create a new style, the user can first insert a table to the document, format it manually and then go to
▸ and click . This will extract the table formatting properties and create the new style.However, LibreOffice does not offer a dialog to Edit existing table styles.
The objective of this project is to create a new dialog to edit all the properties of existing table styles.
The UX team has already devised a proposal for the new Edit Table Styles dialog.
As a stretch goal, it would be nice to have this dialog be used in Impress as well. See the Table Design entry in Impress's Properties sidebar when a table is selected.
- Required skills / knowledge
- C++, Reading other's code, Debugging
- Size
- 175 hours
- Difficulty
- Medium
- Potential mentors
- Rafael Lima, mail: rafael.palma.lima
gmail.com
Base
Implement report builder in C++
Designing and generating reports in LibreOffice is an important feature of LibreOffice BASE. The current report builder implementation uses Java and Pentaho Reporting Flow Engine of Pentaho BI for creating the output, which is an ODT file. Dependence on Java and Pentaho creates issues for packaging LibreOffice in different distributions, and also makes development harder.
The file format used for storing the reports is in itself and XML file, and the resulting ODT file is also an XML document conforming to ODF standard. In order to implement report builder in C++, one should look into the import/export filters in LibreOffice, like the FODF which use XSLT. The resulting code should be able to do the export to ODT without the help of Pentaho library and/or Java.
LibreOffice uses libxslt
as an external library that provides the required tool to XSL tranfromations in C++ code. One can find some of the existing XSL transformation files used in import/export filters with:
$ git ls-files "filter/*.xsl"
Defining appropriate XSL transformation file alongside writing C++ code is needed to implement the reportgenerator.
The other parts of the reporting workflow are already in C++. The reportdesign is in C++, and also other parts of the LibreOffice BASE that the report designer relies on are written in C++. This project can also improve report generating performance of LibreOffice.
- Goal
Implementing report builder in C++, and removing the Java / Pentaho dependency
- Required skills / knowledge
- C++, XML, XSLT, Reading other's code
- Size
- 350 hours
- Difficulty
- Hard
- Potential mentors
- Hossein Nourikhah, IRC: hossein, mail: hossein
libreoffice.org
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: thorsten.behrens
allotropia.de
- 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.
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: thorsten.behrens
allotropia.de
Calc
Common
Accessibility checker for Impress and Calc
We have an accessibility checker sidebar in Writer, but not in Impress and Calc. The accessibility checker triggers a check of the document for accessibility issues and displays those in the sidebar, with helpful hints how to resolve those issues. Accessibility issues include checks of the document metadata (name, description), document structure, objects in the document, as well as check of contrast (font color vs. background color). A lot of issues apply for Impress and Calc too, but some are Writer specific and there as some that are unique to Impress and Calc.
Goal:
Add accessibility sidebar to impress (move code from writer to common code into svx or sfx2), implement a trigger to re-run a check when an object changes, go through the accessibility checks for writer and investigate which check also applies to Impress, add the accessibility check to common code and adapt if necessary (for example to work in editeng and not writer model). If there is still time, repeat the same for Calc.
- Required skills / knowledge
- C++, Reading other's code, Debugging,
- Size
- 350 hours
- Difficulty
- Medium to Hard
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee
gmail.com
Extend support for document theme colors
Support for theme colors is already implemented for Writer, Impress/Draw and Calc, however some colors weren't extended to support theme colors properly. Also when we define gradients we don't support theme colors there so support for theme color gradients would need to be added.
Goal:
Search for properties or parts of properties where we use colors, but we don't support to set a ComplexColor (used for theme colors). Implement a property that works with a ComplexColor for that property, add support to change the color in ThemeColorChanger, write a round-trip test and adapt the import/export filters (for ODF and OOXML) to support saving the theme color for the property. Repeat.
- Required skills / knowledge
- C++, Reading other's code, Debugging
- Size
- 350 hours
- Difficulty
- Hard
- Potential mentors
- Tomaž Vajngerl, IRC: quikee, mail: quikee
gmail.com
Filters
Import Markdown files into LibreOffice Writer
This project is meant to deliver a first working version of Markdown import into LibreOffice Writer, optionally using a document template (OTT) to provide decorative content, and custom styles. Participants are encouraged to research available import libraries, as well as means to get content inserted programmatically into a Writer document (e.g. via UNO, or via DLP's librevenge).
Related report: tdf#162153.
Goal:
Make it possible to import Markdown files compliant to the CommonMark specification into Writer.
As a stretch goal, adding experimental support for Paste-special-as-Markdown can be implemented for Writer.
- Required skills / knowledge
- C++, working with libraries
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thorsten.behrens
allotropia.de
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.bergmann
allotropia.de
- Michael Stahl, IRC: mst___, mail: mst
libreoffice.org
- Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen
libreoffice.org
Python code auto-completion
While it has been years since LibreOffice (and before that, OpenOffice) support Python binding, there were difficulties for the Python script developers to use it efficiently. One of the obstacles is the lack of Python auto-completion. The reason why this was not possible was that the Python objects are created at runtime, and therefore an IDE can not know about the structure of the classes when a developer writes the code.
The solution for that is to generate Python stubs from IDL specifications. This is done in many other languages in the module codemaker
. The task here is to create a similar tool for Python, which can be named pythonmaker
.
To get an idea of the needed code, you may look into codemaker/source/
, and there you will see:
cppumaker
: stub generator for C++javamaker
: stub generator for Javanetmaker
: stub generator for Python
Goal:
Make it possible to do Python code auto-completion by generating Python stubs from IDL specifications.
- Required skills/knowledge
- C++, Python, reading other people's code
- Size
- 350 hours
- Difficulty
- Medium to hard
- Potential mentors
- Hossein Nourikhah, IRC: hossein, mail: hossein
libreoffice.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.