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. Feel free to pick any of the tasks listed in the Programming Tasks section of the Easy Hacks page, but in that case you need to ask for mentors on the development mailing list if none is defined. Also the page the Genial Ideas page holds interesting ideas for a GSoC project, but - alike the EasyHacks page - you need to find a mentor for your GSoC project by asking on the LibreOffice developer list.
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. When doing that please use this template:
=== Title of the task === Some detailled 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
Refactor god objects
LibreOffice has quite a few huge god objects, and it would be great to refactor them into smaller parts. sw/inc/doc.hxx is included by half of sw and includes a huge loads of other headers. Apart from undesirable tight coupling, it also causes a major and unneeded increase in incremental (re-)build times.
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen @ canonical.com
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
Analyse and optimize SfxItemSet, make it use a STL container internally
SfxItemSet is fundamental data structure heavily used while reading documents. It is also a very ancient, nonobvious container implementation. This task would be to analyse the use of SfxItemSet in default operations, for example:
- How many slots does an average ItemSet have?
- How much of an average ItemSet is usually filled?
- How many read/writes does an ItemSet perform over its lifetime?
- Could the SfxItemSet possibly gain from using Copy-On-Write?
- ...
And then, depending on the results of this analysis, make the implementation a wrapper around an suitable STL container.
Required skills / knowledge C++, callgrind, debugging
Difficulty: hard
Potential mentors:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
Improving Charts
There are lots that could be improved with charts and 3D Charts. To begin with, we could look at improving the label positioning and auto rotating. Ref: an earlier commit Two issues that be quickly identified:
- Auto rotation chooses 45 degrees
- Label overlapping algorithm isn't that great.
We could also support more chart types, like 3D bubble charts and donuts. On the display side it could be made more realistic and attractive. While attempting this, do scope the task according to your liking. Some more interesting chart types are here: http://www.think-cell.com/products/chart/overview.shtml (especially helpful are automatic breaks in line charts, or waterfall charts)
Required skills / knowledge C++, Reading other's code
Difficulty: medium-hard
Potential mentors:
- Muthu Subramanian , IRC: muthusuba, mail: sumuthu
collabora
- Markus Mohrhard , IRC: moggi, mail: markus.mohrhard
collabora
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: http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml, you might need to change also http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/dmapper
For XLSX and PPTX, it resides in http://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
- Miklos Vajna, IRC: vmiklos, mail: vmiklos @ collabora . com
LibreOffice 4.0 can now connect to CMIS servers to fetch and handle documents. Although this is a standard protocol to communicate with Document Management Systems, there are a few other protocols that are widely used like the ones from SharePoint. Microsoft SkyDrive may API may also turn widely used in the next few months. This project is about extending libcmis to implement one (or more) of these protocols. By adding a CMIS API for these protocols, LibreOffice would then be able to connect with them with no effort.
Here are some code pointers to get started in the task:
- libcmis AtomPub and WebService implementations: https://sourceforge.net/p/libcmis/code/ci/d605a7238df9fdb43457314c06cc84726d8dcadd/tree/src/libcmis/
- SharePoint protocol specifications: http://msdn.microsoft.com/en-us/library/cc339473%28v=office.12%29.aspx
- Microsoft SkyDrive REST API: http://msdn.microsoft.com/en-us/library/live/hh243648.aspx
Required skills / knowledge C++, Reading other's code, Networking (use of WireShark, knowledge of HTTP)
Difficulty: medium
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
- Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
Connecting to iCloud
It would be nice if LibreOffice on the Mac could load / save files in iCloud. Most likely implementing this would also as a side-effect make it easier to interface to the new NSDocument stuff in general, too, i.e. automatic versioning etc, and make LibreOffice's document model, as visible to the user, be more in line with current Mac conventions.
Relevant documentation is included with Xcode; look for NSDocument docs and the iCloud Design Guide for starters. (But eligible students should already know what to look for, more or less;)
Possibly a new UCP ("Universal Content Provider") in LibreOffice would be needed. For an example of a recently written, fresh, UCP, see ucb/source/ucp/cmis. Unfortunately how UCPs work and interact with the other layers of LibreOffice is somewhat weirdly engineered. But for iCloud, we definitely do not want to force the user to use the silly "own" file picker, that would be very foreign to users.
Full-time access to a reasomably modern Mac, running OS X 10.8 or 10.9 is required. Membership in the Mac Developer Program is not necessary. Hackintosh use is frowned upon.
Required skills / knowledge C++, Objective-C, OS X API, Reading other's code. Experience writing non-trivial document-based OS X applications required. Actually we are surprised if any student shows up with the required knowledge...
Difficulty: hard
Potential mentors:
- Tor Lillqvist, IRC: tml, mail: tml @ iki . fi
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
More and better tests
While there are some automated tests for LibreOffice, there are not nearly enough. The goal here is to make developers who work on the code more productive by allowing them to find regressions as early as possible.
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.
Required skills / knowledge either C++, Java, or Python; for unit level tests reading other's code
Difficulty: easy
Potential mentors:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard AT googlemail DOT com
Porting and platform specific topics
LibLibreOffice / GNOME-Documents integration
Today GNOME Documents spawns LibreOffice via a rather unreliable unoconv command-line that converts documents to PDF. Instead it would be awesome to re-use libreoffice via liblibreoffice to render textured tiles inside the viewer.
This project has several stages:
- extending liblibreoffice to do tiled rendering, and/or provide document tiles inside some operating-system handled primitive.
- This is purely an API creation / mapping problem for writer
- Need to do some work - pwrt. sheet tabs and tiled rendering etc. for Spreadsheet.
- Need work to split presentations from edit mode and tiled render for Impress
Required skills / knowledge C++, gtk+ optional.
Difficulty: Medium
Potential mentors:
- Michael Meeks, IRC: mmeeks mail: michael . meeks @ collabora.com
- Jan Holesovsky, IRC: kendy mail: kendy @ collabora.com
Fennec based front-end for Android
The Mozilla project has produced a great infrastructure for Mozilla in terms of layered rendering etc. that we can re-use to provide the GUI / Java front-end for LibreOffice on Android. We should cut this code down to a dummy app that does tiled / layered rendering and import it into LibreOffice git. We should then plug it into the LibreOffice's tiled-rendering backend, to provide a multi-document / multi-window viewing & simple editing experience. See here for fennec.
We should also do some minimal work to expose some simple chrome (ie. bold/italic/font style etc. widgets) from the applications in the UI.
Required skills / knowledge C++, Java
Difficulty: Medium
Potential mentors:
- Tor Lillqvist, IRC: tml, mail: tml @ iki . fi
- Michael Meeks, IRC: mmeeks mail: michael . meeks @ collabora.com
Porting LibreOffice to x64 Windows
It would be nice if LibreOffice could be built as 64-bit (x64) code for Windows. One reason why this is becoming more urgent is that current Java versions from Oracle by default install as 64-bit variants only on 64-bit Windows machines.
Some work on this was already done in 2011, see http://tml-blog.blogspot.fi/2011/03/porting-libreoffice-to-x64-windows.html . Not much has ben done since.
Required skills / knowledge C++, plus Windows Structured Exception Handling, table-based unwinding, and x64 calling conventions. Not necessary to fully know the details of the exception handling and calling conventions etc in advance, but student should demonstrate a good understanding of what it's about and capability of understanding the concepts when reading up on them.
Difficulty: Hard
Potential mentors:
- Tor Lillqvist, IRC: tml, mail: tml @ iki . fi
User Interface
Dialog Widget Conversion
Our dialogs are described in .src files which is a custom format. Positions and sizes of elements are fixed, e.g. the size of a cancel button is the width of the longest translation of Cancel in all supported languages. There is some work underway to retrofit a more modern layout approach to our existing code. See this overview and WidgetLayout, with an end goal of describing the dialogs in some xml file format, ideally the gtk2 builder format as used by glade3.
We have an immense amount of dialogs in .src format, the task would be to automate the process of mass converting the existing .src files to glade3 format to create an initial set of xml dialog descriptions. The intention would be that the conversion output itself would still consist of fixed position and size elements (e.g. see GtkFixed) but conversion to glade3 format would facilitate the use of glade to redesign individual dialogs.
Required skills / knowledge mainly scripting, perhaps a little python. Some C++ if you want to get involved with the code that will consume the output of the conversion.
Difficulty: easy/medium
Potential mentors:
- Caolán McNamara, IRC: caolan, mail: caolanm
redhat
Further improvements in the Template manager
The template manager was implemented in the previous Summer of Code, but there are ideas for further improvements:
- remove UI quirks and inconsistencies
- fix any instabilities
- improve performance (for example, when creating thumbnails of templates)
- make the template manager more useful for larger template collections
- allow creating (empty) templates from the manager
- make as much as possible of the dialogue reusable for general purpose file browsing (at least the icon view)
The code of the template manager resides here:
- Template manager dialog itself: http://cgit.freedesktop.org/libreoffice/core/tree/sfx2/source/doc/templatedlg.cxx
- Previews of the pages: http://cgit.freedesktop.org/libreoffice/core/tree/sfx2/source/control/thumbnailview.cxx
Required skills / knowledge C++, Reading other's code
Difficulty: Medium
Potential mentors:
- Jan Holesovsky, IRC: kendy, mail: kendy@collabora.com
Improve toolbars in LibreOffice
There are many ideas how to improve the toolbars in LibreOffice, in order to make them more usable. This is including easier modification and hiding of elements that are present at the toolbar, possibility to reshape it, etc. To be more concrete:
- Allow some toolbars use large icons, while other would use small ones.
For this, you want to check http://cgit.freedesktop.org/libreoffice/core/tree/framework/source/uielement/toolbarmanager.cxx, and search for "large" there - it is on more places. This should be extended so that it is a per-toolbar setting (with possible override for those who want large or small icons always), via http://cgit.freedesktop.org/libreoffice/core/tree/officecfg/registry/schema/org/openoffice/Office/UI/WindowState.xcs#n108 - property "Style" looks ideal. - Add possibility to hide items via a targeted button
- Introduce a concept for a toolbar that is right-aligned
- Improve framework for toolbars painted by an extension
This task will start first fixing some toolbar-related bugs, related to their appearance and the ability to use items in vertical toolbars and as well as items that are hidden, because the window is too small:
Later, we might attempt to use the Development/WidgetLayout to define new toolbars with much higher freedom of modifications.
The toolbar's code lives mostly here: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/window/dockingarea.cxx, but also in http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/window/toolbox.cxx and http://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/window/toolbox2.cxx .
The handling of toolbars is mostly in http://cgit.freedesktop.org/libreoffice/core/tree/framework/source/uielement/toolbarmanager.cxx .
Requierd skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Tomaž Vajngerl, IRC: quikee, mail: tomaz.vajngerl @ collabora . com
Finish the Gtk+3 port
LibreOffice has been largely ported to Gtk+3, but that work is still not finished - some of the widgets are not ported yet, some have redrawing problems, etc. This work is supposed to finish this work, and provide shiny usable Gtk+3 version.
Code pointers: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3 , mostly http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
Required skills / knowledge C++, Reading other's code
Difficulty: Medium.
Potential mentors:
- Caolan McNamara', IRC: caolanm, mail: caolanm @ redhat . com
Improved Color selection
In all LibreOffice applications, the colors can be picked from a color palette defined in the global options. This is particularly annoying when the user wants to use several palettes, reuse palettes from other applications like Gimp or Inkscape or simply choose a color that is not in one of the palettes. This task is about:
- changing the UI of the color selection to allow choosing a color among different palettes or an arbitrary color
- changing the UI and configurations to handle several palettes
- import palettes from other applications (Gimp ones at least)
Some UI ideas can be found here
Here are some code pointers to get started in the task:
- Color selection control for toolbars: http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/tbxctrls/colrctrl.cxx
- Palette configuration page: http://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpcolor.cxx
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Tomaž Vajngerl, IRC: quikee, mail: tomaz.vajngerl @ collabora . com
Revamp the gallery tool
The LibreOffice Gallery tool would need to be enhanced to support features like sorting using tags, search, connection to online galleries like OpenClipart. This project aims at changing the gallery tool in this way. A previous GSoC project ended up with code for fetching and displaying pictures from OpenClipart. This code would need to be used as a basis for this project. As a later target, this new Gallery would be the base for an objects libraries dialog (eg network, UML...). Even though this would probably not fit in the time frame of a GSoC, this target may influence UI and code design choices.
The display of the galleries should be done as a side-bar, re-using the widget from Impress that has headings 'Master Pages' / 'Layouts' / 'Slide Design' etc. - but with each of these being a separate category of clipart - and presenting a selectable sub-set of these. This would make much better use of screen real-estate that the current horizontal gallery.
Here are some code pointers to get started in the task:
- Previous GSoC patch: http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/online_gallery.diff?h=libreoffice-3-4
- Extension that integrates OpenClipart library in the task panel: http://extensions.libreoffice.org/extension-center/openclipart-org-integration in Writer
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Tomaž Vajngerl, IRC: quikee, mail: tomaz.vajngerl @ collabora . com
Improve usability of Personas
The UI to get Personas applied in LibreOffice is working, but needs the user to browse in Firefox, and then paste the URL to the LibreOffice Personalization dialog.
It would be much better to connect to the Themes repository API directly, and allow browsing directly in LibreOffice.
The API is described here: https://developer.mozilla.org/en-US/docs/addons.mozilla.org_%28AMO%29_API_Developers%27_Guide/The_generic_AMO_API
The Personalization dialog in LibreOffice that will need to be improved in order to browse the Personas directly in LO is here: http://cgit.freedesktop.org/libreoffice/core/tree/cui/source/options/personalization.cxx#n39
Required skills / knowledge C++, Reading other's code
Difficulty: easy
Potential mentors:
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Base
Basic
Draw
Improve Text Boxes in Draw
LibreOffice Draw is a powerful vector graphics application and more. However, it cannot unleash its full capacities because of limited features supported by its text frame implementation. This task would aim at implementing different text frame features that are missing: Text background colour, flow of content from one frame to another, hyphenation, as well as support of styles. The student will work on these tasks in team with his mentor.
Getting the draw text frames able to layout complex text inside would also help for future code sharing with Writer or would allow to enhance Writer comments text formatting.
Some code pointers:
- where it is all painted: http://docs.libreoffice.org/editeng/html/classImpEditEngine.html#aa20bd6c40eb7afc8a734128ce2b4bd6f
Required skills / knowledge C++, Reading other people's code
Difficulty: medium
Potential mentors:
- Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
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: http://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: tbehrens @ suse . com
Follow-me slide-show
Last year's spreadsheet collaborative editing prototype build a wrapper for the telepathy stack. This needs completing and abstracting properly - currently it drags platform dependencies (eg. glib) into calc. Then we should integrate this with impress - and also Empathy - such that it is possible to launch a slideshow backed by a Jabber chat-room, and broadcast "goto slide <N>", "next animation" type commands from a controlling process, and of course to receive them from a listening process. The existing Android remote shows the UNO entry points necessary to do this, so this should be reasonably easy to do. Much of it is re-factoring the existing code, and providing a credible desktop / UI integration point design.
Required skills / knowledge C++, Reading other's code.
Difficulty: hard
Potential mentors:
- Michael Meeks, IRC: mmeeks, mail: michael.meeks @ collabora . com
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 (http://wiki.services.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: tbehrens @ suse . com
SmartArt editing in Impress
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: fdo#37932. An external extension (not nicely integrated) trying to implement at least some SmartArt functionality: SmART
Required skills / knowledge C++, Reading other's code.
Difficulty: difficult
Potential mentors:
- Muthu Subramanian, IRC: muthusuba, mail: sumuthu @ collabora . com
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:
- this needs some ODF processing when being stand-alone or web-based, e.g. via https://github.com/lpod/lpod-python
- or you make it built-in, then the copying-slides-around functionality is here: http://opengrok.libreoffice.org/search?refs=InsertBookmarkAsPage
Required skills / knowledge ODF, UX, possibly c++, possibly Python, possibly web frameworks
Potential mentors:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- current animation engine: http://cgit.freedesktop.org/libreoffice/core/tree/slideshow/source/engine/animationnodes
Required skills / knowledge C++, basic game/animation skills useful, reading other people's code
Potential mentors:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
Calc
Chart sheets in Calc
Currently Calc only supports table sheets ut for interoperability we should at least support chart sheets. For this task one needs to abstract the sheet handling in calc and adapt all places that unconditionally assume that every sheet is a table sheet.
Here are a few code pointers to this task:
- The current implementation for a sheet is ScTable: http://opengrok.libreoffice.org/xref/core/sc/inc/table.hxx
- All ScTable instances are held by maTabs in ScDocument which represents a full calc document: http://opengrok.libreoffice.org/xref/core/sc/inc/document.hxx
- The corresponding shell is ScTabView: http://opengrok.libreoffice.org/xref/core/sc/source/ui/inc/tabview.hxx and ScTabViewShell: http://opengrok.libreoffice.org/xref/core/sc/source/ui/inc/tabvwsh.hxx
Required skills / knowledge C++, Reading other's code, debugging
Difficulty: medium-hard
Potential mentors:
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
Writer
Implement table styles
Formatting a table in Writer is painful, really painful. Users need to apply a table auto-format that is only a collection of properties to be applied on all cells... if by chance the user needs to add some lines / columns to the table, he needs to apply the auto-format again. The idea behind this task is to replace this monstrosity by proper table styles. This project may be a bit ambitious on purpose: this can be split into smaller pieces and was already started last year. Some design ideas can be found on this whiteboard and the corresponding long-standing bug report. Further information can be found in the related LibreOffice bug entry: fdo#34391.
Here are a few major steps for the project:
- Implement the table style support in the Writer model and layout
- Implement odf and/or docx import filter
- Implement a UI for creating and modifying a table style
- Integrate this UI in the "Styles and Formatting" dialog
- Implement odf and/or docx export filter
- File an ODF change proposal to OASIS if needed
Here are some code pointers to get started in the task:
- Auto-format dialog: http://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tautofmt.cxx
- Auto-format application code (start of the track): http://opengrok.libreoffice.org/xref/core/sw/source/core/frmedt/fetab.cxx#SetTableAutoFmt
- feature/table-style branch in git
Required skills / knowledge C++, Reading other's code
Difficulty: hard
Potential mentors:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
- Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
ODF Formulas in Writer
Did you know Writer documents could embed formulas in some fields? The obvious case is for tables computations but this is possible with variable fields as well. The weird thing there is that the formula syntax is specific to Writer and isn't standardized. Writer can compute formulas from doc/docx files which have a syntax very closed to ODF Formulas's one thanks to ixion library. The goal of this task is to push forward this started effort to allow users to type ODF Formulas instead of the old syntax. Of course the old syntax still needs to be parsed / written for backwards compatibility.
The project could be split into several parts:
- Clean up the formula fields computation code to delegate computation to ixion and use ODF Formulas as the internal syntax.
- Change the UI to input ODF formulas
- Change the ODF import and export filter to load and save both syntax. A compatibility option will probably be needed to determine which syntax to save back.
Here are some code pointers to get started in the task:
- SwTableFormula is the class handling the table formulas computation: http://opengrok.libreoffice.org/search?refs=SwTableFormula
- SwInputWindow is the class for the formulas input bar: http://opengrok.libreoffice.org/xref/core/sw/source/ui/inc/inputwin.hxx#58
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
- Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
Filters
Implement Quattro Pro Import filter
The (binary) Quattro Pro file format is reasonably well documented - which should make this task reasonably easy. There is also an existing filter for the .wb* file formats. We really want to provide support for the much more modern .qpw file format - to allow users to migrate away to ODF. For many years Dell (for example) have shipped Quattro Pro bundled on their PCs, and there are lots of files out there, it'd be great to help those guys out.
The existing legacy qpro filter code is here and is fairly simple. We should build on this, and share as much code as possible, with an initial focus on data rescue: getting the strings, numbers, and simple formulae across - before expanding to formatting: fonts, weights etc. It should be easy enough to get something visible, and a fun thing to hack on. Reasonable specifications for the binary format are available on request for interested students.
Required skills / knowledge C++
Difficulty: easy
Potential mentors:
- Fridrich Strba, IRC: Fridrich, mail: fridrich.strba
bluewin
Improve WMF/EMF/EMF+ import
LibreOffice already has a quite good coverage of windows metafile formats features. The task is to implement missed options and fix incorrectness. A list of some issues and test files could be taken from here fdo#55058
Required skills / knowledge C++, Reading other's code
Difficulty: medium to hard
Potential mentors:
- Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
- Valek Filippov, IRC: frob, frob_tea, mail: frob at gnomeorg
Improve VML import
The import of VML in our DOCX implementation is limited, and for example is unable to import rotation of ellipses, or shading of objects. Even though VML is not recommended by the OOXML specification as the format to use, MS Word 2007 uses that primarily, and as a consequence, there are many .docx files around using VML.
Here are some code pointers to get started in the task:
- oox/source/vml/vml* - the import code for VML; eg. ellipses are imported so that ShapeContextBase::createShapeContext() in oox/source/vml/vmlshapecontext.cxx gets the shape context, and creates an instance of EllipseShape
For sure there are missing rotations of shapes, or their shading. There will be a test document provided which is supposed to be imported perfectly after the end of the GSoC.
Required skills / knowledge C++, reading other's code
Difficulty: medium
Potential mentors:
- Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Implement legacy StarOffice binary formats import filter
StarOffice 1.x - 5.x had a variety of binary formats which used to be supported by the notorious binfilter, which was removed in LO 4.0 since it was unmaintainable.
It should be possible to implement a much simpler import filter for the legacy StarOffice binary formats based on the librevenge import filter API. In the absence of file format documentation the source code for the binfilter can be used as a reference, but likely some reverse engineering and experimentation will also be required.
Required skills / knowledge C++, Reading other's C++ code (to reuse libwpd importer code and extract file format details from binfilter),
Difficulty: medium
Potential mentors:
- Fridrich Strba, IRC: Fridrich, mail: fridrich.strba
bluewin
- David Tardon, IRC: dtardon, mail: dtardon
redhat
Implement Apple Pages import filter
The goal is to implement a filter for versions 3 and 4 of the Apple Pages format (iWorks '09 and '13). The version 3 format is XML based: the output is saved as single zip file, containing index.xml, which is XML specification of the document, and other data files (images used in the document, generated preview and thumbnail, etc.) There is no documentation for the format (known to me), but the XML is reasonably readable. The version 4 format is binary and is currently being reverse engineered.
The new filter will be added to libetonyek, which is an existing library for parsing Apple Keynote format, rather than being in a separate library, as there is a large overlap between the two format's capabilities, which makes it possible to reuse a lot of basic stuff. This also makes me confident that we can implement parsers for both file format versions.
Required skills / knowledge:
- C++
- Reading other's C++ code (to reuse libetonyek/libwpd/libwps/libmwaw/libebook importer code)
- Ability to read XML and some kind of schema
- Ability to understand hexadecimal dump of data
- Ability to read (better yet, write) Python (for OLEToy)
- Readiness to become famous
Difficulty: medium
Potential mentors:
- David Tardon, IRC: dtardon, mail: dtardon
redhat
Implement Apple Numbers import filter
The goal is to implement a filter for versions 2 and 3 of the Apple Numbers format (iWorks '09 and '13). The version 2 format is XML based: the output is saved as single zip file, containing index.xml, which is XML specification of the document, and other data files (images used in the document, generated preview and thumbnail, etc.) There is no documentation for the format (known to me), but the XML is reasonably readable. The version 3 format is binary and is currently being reverse engineered.
The new filter will be added to libetonyek, which is an existing library for parsing Apple Keynote format, rather than being in a separate library, as there is a large overlap between the two format's capabilities, which makes it possible to reuse a lot of basic stuff. This also makes me confident that we can implement parsers for both file format versions.
Required skills / knowledge:
- C++
- Reading other's C++ code (to reuse libetonyek importer code)
- Ability to read XML and some kind of schema
- Ability to understand hexadecimal dump of data
- Ability to read (better yet, write) Python (for OLEToy)
- Readiness to become famous
Difficulty: medium to hard
Potential mentors:
- David Tardon, IRC: dtardon, mail: dtardon
redhat
Implement Zoner Draw import filter
Zoner Callisto (known as Draw outside of the Czech Republic) is a very good vector graphics editor. After the development stopped, the last version (5) has been released free of charge (not open source, regrettably). This makes it a good choice for students etc. and increases the likelihood of appearance of files with .zmf extension. Therefore it would be great if LibreOffice could import it :-)
The goal is to implement a filter for (at least) version 5 of the format (there appear to be 2 variants of the format: one, based on OLE2, was used by versions 2 and 3; the other, which can be either zip or a single binary, by versions 4 and 5). No specification is available, so a part of the task will be reverse engineering of the interesting bits, with the help of OLEToy.
The filter will be based on librevenge library.
Required skills / knowledge:
- C++
- Reading other's C++ code (to reuse libwpg/libvisio/libcdr/libmspub importer code)
- Ability to understand hexadecimal dump of data
- Ability to read (better yet, write) Python (for OLEToy)
- Readiness to become famous
Difficulty: medium
Potential mentors:
- David Tardon, IRC: dtardon, mail: dtardon
redhat
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.
Haskell 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 Pyhton, it would be great to have such a bridge also for a great language like Haskell.
One aspect is to use Haskell FFI to interface with the binary UNO C API. Another is to design the Haskell 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 Haskell. A third aspect could be to create a pure Haskell implementation of the UNO remote bridge protocol.
Some documentation pointers are:
Some code pointers are:
bridges/source/jni_unoas an example of an in-process UNO bridge (for Java, via JNI)binaryurpas an example of a remote UNO bridge (in C++)
Required skills/knowldege: Haskell, interfacing to low-level C/C++, working against formal specifications
Difficulty: medium to hard
Potential mentors:
- Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
Tooling
Crash reporter service
There is a crash reporting tool in the LibreOffice code base, which is currently not used because there is no service it could report to. Such a service should be developed, receiving incoming crash reports and storing them in a database. The reports come with a call stack, and the tool should do some correlation to match new reports against those existing in the database, to find duplicates. Nice to have would be if the service could automatically resolve the addresses in the stack to exact source location by scripting debugging tools.
There already exist tools a lot of this for Linux distributions, such as Red Hat's ABRT, looking at how that is implemented would be useful. Currently there is not such a great need for a working crash reporter for Linux, because most Linux users use LibreOffice from their distribution, but for Windows and MacOS X it would be very useful.
Required skills / knowledge Server side development, Database, etc.
Difficulty: medium
Potential mentors:
- Jesús Corrius, IRC: jcorrius, mail: jcorrius AT gmail DOT com
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
Decentralized Continuous Integration Infrastructure with Tinderboxes, Gerrit, buildbot plugin and Jenkins
With introduction of Gerrit Code Review the patch set verifications, i. e. test build of pushed patches is one of the central concepts of pre merge tests. The situation with LibreOffice project is different from other CI environments, e. g. OpenStack and Wikimedia: it is decentralized. Buildbot Gerrit Plugin was created to maintan a queue of pending build jobs. IOW: it is a multi project and multi platform queue manager for patch verifications.
It coordinates the decentral located tinderboxes without having a continued network connection to them by maintaining project and platform specific working queue of tasks for each gerrit patch. A patch set considered to be verified if and only if all tinderbox tasks are reported success back. In this case `verified` status is reported back to gerrit. In addition log publication is provided by delegating the log to jenkins instance.
To see it in action, check a Gerrit change that was built on 3 platforms:
https://gerrit.libreoffice.org/#/c/8118
What needs to be done is to improve the existing implementation and add missing features for Gerrit Buildbot plugin, Tinderbox scripts, Gerrit and Jenkins:
- https://github.com/davido/gerrit-buildbot-plugin
- https://gerrit.libreoffice.org/plugins/buildbot/Documentation/architecture-overview.html
Persistence
If Gerrit is restarted then the current task queue is lost.
Idle timeout
If task is not picked up for building within defined time, the task for this platform is cancelled.
Engaged timeout
If task is not get reported within defined time, the task is moved again in init state, and can be picked up again for building. If the original tb reports the status after it, then it is discarded.
Missing Gerrit feature
Dedicated notification channel for patch set verifications. Currently comment table get spammed instead of reporting build results in its own HTML fragment/table on Gerrit change screen 2:
https://code.google.com/p/gerrit/issues/detail?id=2465
Passing parameter to Tinderboxes during scheduling of build jobs
It would be nice to be able to pass build options to the Tinderboxes, when they support it:
https://bugs.freedesktop.org/show_bug.cgi?id=71033
Extending Jenkins external-monitor-job-plugin
Build log are published to Jenkins per SSH with patched external-monitor-job-plugin:
This pull request was merged and plugin should be updated in our local Jenkins deployment. Moreover it would be nice to parse the log file and to highlight the build error(s) on the log page.
Integration of Gerrit serviceuser-plugin for managing Gerrit accounts for Tinderboxes
Edwin wrote wonderful UI based serviceuser-plugin that we want to start using to maintain dozens of SSH enabled Gerrit accounts for Tinderboxes (non-interactive users with public key managements, etc):
https://gerrit-review.googlesource.com/#/admin/projects/plugins/serviceuser
Required skills / knowledge JavaScript, Python, Shell, Java, Reading other's code, and understanding of CI concepts and integration of loosely coupled systems.
Difficulty: Medium to hard
Potential mentors:
- Norbert Thiebaud, IRC: shm_get, mail: nthiebaud at gmailcom
- Bjoern Michaelsen, IRC: sweetshark, mail: bjoern.michaelsen at canonicalcom
- Robert
- David Ostrovsky, IRC: _david_, mail: d.ostrovsky at gmxde