The Document Foundation Wiki
 

GSoc Ideas

From The Document Foundation Wiki

Jump to: navigation, search


Contents

Preamble

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.

When adding a new task, please use the following 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


General

New templates picking UI

Accessing document templates from LibreOffice UI is not an easy thing. This task consists in implementing a new dialog to pick up templates. These could be picked up either from local folders or remote document repositories. The access to the remote repositories would be implemented using CMIS protocol to enable connection to different sorts of servers. Implementing the CMIS client code shouldn't be needed as libcmis is already integrated in LibreOffice. As a side task, setting up cmis4plone on the LibreOffice templates website will be needed to get it integrated with the new dialog.

This task involves discussions with the UI designers team to discuss the dialog. A state of the design ideas can be found here

Required skills / knowledge C++, UI good sense, Reading other's code

Difficulty: medium

Potential mentors:


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:

Some UI ideas can be found here

Here are some code pointers to get started in the task:

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

Difficulty: medium

Potential mentors:

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:

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

Difficulty: medium

Potential mentors:


Use svg for LibreOffice icons

LibreOffice uses png for its icons sets currently; with the trend towards higher display resolution and scalable UI, using an expressive vector format would be useful. This task is about adding proper svg rendering capabilities to the lower layers of LibreOffice, and using that for standard LibreOffice icon sets.

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

Difficulty: medium

Potential mentors:


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.

http://nabble.documentfoundation.org/Has-the-time-come-to-get-rid-of-the-delivering-of-public-headers-tp3762906p3769420.html

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

Difficulty: medium

Potential mentors:


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:

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:

Template translation / shrink bloated install size

Our windows downloads are unreasonably big: 210Mb, when compared to the 120Mb en-US only download. The translations themselves are relatively small when compressed, however - we have a number of documents and templates that are quite large, each one is currently translated using LibreOffice to open and re-save the document as .zip files. Thus the huge commonality here is hidden, and this bloats (see analysis) our install. In addition, we duplicate the English template files for each language without a translation in the install set (though that probably compresses better).

A major source of this is the extra/ module which is rather badly structured, and the bloat can be seen. We have over 2000 mostly duplicated '*.ot*' files in extras. I suggest we convert all of these to flat ODF files (.fott) and dig out the differences between them (mostly translating strings) and some un-necessary style changes, add some annotations to extract those strings to some sensible XML format (the Java properties format?) that we can use to do substitutions at load-time in a simple C++ filter (the flat odf code is very simple and lives in filter/source/odfflatxml/)

Required skills / knowledge mainly C++, perhaps a little python / Java to poke at the wizards code

Difficulty: easy/medium

Potential mentors:


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

Feature branch with the started work: feature/cmclayout

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:

Improving Charts

There are lots that could be improved with charts and 3D Charts. To begin with, we could look at fixing https://bugzilla.novell.com/show_bug.cgi?id=735040 and related label positioning issues. 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. 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:


Sign PDF documents on export

Our internal PDF export is one of the flagship features of LibreOffice - yet, it currently misses signing generated pdfs, which is in increasingly high demand. All places that have full-digital document workflows, in government, industry, or law practice, would rely on that. LibreOffice uses the MS keystore on Windows, and the Mozilla/Firefox ones on Linux, so the infrastructure to obtain digital certificates is assumed to be there already.

What this task is about, is to implement, and thoroughly test, digital signatures to the internal PDF export according to the PDF spec - we'd at least want PDF/A conformance (which probably means implementing the PKCS#7 container). As a stretch target, PDF encryption would be nice as well.

Required skills / knowledge Some C++, some understanding of cryptography / typical libraries. You will need to read up on the PDF spec, and have a strong will to test what you write.

Difficulty: medium

Potential mentors:


Implement a "about:config" functionality

LibreOffice has way too many options, most of them irrelevant but for the most advanced users. Therefore, it would be great to distill it down to a reasonable set (outside scope for this task), and have all those other arcane options be accessible via the well-worn about:config-alike functionality (you know from firefox). This can be achieved in a variety of ways - including StarBasic, or Python.

See http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-March/000944.html for more thoughts.

Required skills / knowledge Some C++, reading other people's code, either Python, or Basic for implementation.

Difficulty: easy

Potential mentors:


Java GUI for LibreOffice-based Android app(s)

Android apps using LibreOffice code should probably have a UI specifically written for Android (thus in Java), and then call existing LibreOffice code do non-GUI tasks.

This new Java UI should (initially) target only writer, and treat the LibreOffice core as a supplier of bitmaps, which are sub-sections of a page (ie. tiles) - and not much more. Clever and efficient use of such bitmaps to ensure that at high zoom we are not wasting memory with giant textures is necessary. So LibreOffice would provide a list of pages, and their dimensions, and the UI would render them, allow page flipping, thumnails-of-pages for a pretty browse view, ideally nice page-turning animations, side-by-side reading, and all the normal document viewer options.

Initially, as a very-first-cut - it would be best to do this with a simple slideshow of bitmaps on the device, and in due course couple this up to the bitmap renderer. However, keep the tiled rendering concept in mind in that easy case.

Required skills / knowledge Java, Android API and concepts, access to a reasonably modern Android tablet device.

Difficulty: too early to say

Potential mentors:

Telepathy for collaboration

Create a framework for collaboration using Telepathy DBus tubes over XMPP. 1-1 contact collaboration and many-many MUC collaboration. A first rough sketch is in progress but not yet functional. It's available on the feature/tubes2 branch, module tubes, for details see tubes/README

Required skills / knowledge C++, profound knowledge of Telepathy and DBus

Difficulty: quite hard

Potential mentors:

Base

Support for Sqlite Database in Base

This task is to get Sqlite working with Base. More information is here

Required skills / knowledge C++, a little SQL, Reading other's code.

Difficulty: medium

Potential mentors:


Basic

Bunch of Basic IDE improvements

Provide a tree like dialog that can be optionally docked in a pane on the ide. This is already partially implemented see http://cgit.freedesktop.org/libreoffice/core/patch/?id=0e8eb19a53338c83dab7fe19e2f23bcaecd52077 However there is lots to be done, currently the partial implementation above uses the existing ObjectCatalog dialog but we probably would be better off using a new but simpler dialog consisting just of the tree widget from the above dialog. Additionally we need to add context menu support and there are many wrinkles regarding the behaviour of the new pane that need to be fixed

Similar to the above the Dialog Editor in the basic IDE could benefit from having a property sheet editor that could be docked/undocked. Currently the property sheet is only available by selecting an existing control in the dialog and using the context menu to launch the "Properties" dialog ( see http://opengrok.libreoffice.org/xref/core/extensions/source/propctrlr/propertyeditor.hxx#51 ). We need a new DockingWindow based control provide the property edit functionality

This might be simple ( just setting some flags ) or maybe you actually have to handle scroll directly in the controls themselves. see http://opengrok.libreoffice.org/xref/core/toolkit/source/controls/dialogcontrol.cxx#1015 and http://opengrok.libreoffice.org/xref/core/toolkit/source/controls/dialogcontrol.cxx#266

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

Difficulty: medium Potential mentors:


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:

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

Difficulty: medium

Potential mentors:


Impress

Make master pages copyable

Currently, when in master page edit mode, the slide sorter has cut/copy/paste disabled. The task would be to add this missing functionality, and correctly handle masterpage-attached styles.

Code pointers:

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

Difficulty: easy

Potential mentors:

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.

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

Difficulty: hard

Potential mentors:


Slide layout extendibility

Make Impress layout templates easily extendible. Currently, the slide layouts in Impress (e.g. "Title page", "Outline page") are a hard-coded set; it would be really cool to have them extendible or even user-editable. This task has been almost completed in the 2009 GSoC term, see 2009 wrapup for the details - there's though still enough work left to make this more useful, e.g. having user-editable layouts.

Original patch from GSoC 2009: http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/impress-autolayout.diff?h=master-backup

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

Difficulty: medium

Potential mentors:

Multi-threaded imports

LibreOffice imports documents in single threads - thus talking quite some time for large documents. This task is to make that as multithreaded. The fast-parser interface is used for both ODF and MSOX importing so, by splitting the import code and parser into two threads we can speed this up for multi-threaded machines. This requires some experimentation and profiling.

The basic idea is to partition the task at the fast-parser interface level, the fast-parser interface essentially provides a tokenised representation of the ODF XML; You can read the XFastParser interface here [1] and it's associated interfaces. We would want a reasonably large swap buffer to store tokenised, parsed ODF which could then be pushed into the XFastParser interface in the main-thread so we would have:

Required skills / knowledge C++, a little XML, Reading other's code.

Difficulty: medium Potential mentors:

Use your SmartPhone to remote-control slideshow

Previously, folks had to carry one of those usb-wireless remote controls around to direct their slideshow. With smartphones being ubiquituous, it would be cool to have an Android app that remote-controls an Impress slideshow instance via BlueTooth and/or WLAN. One of two additional features is required for successfully finishing this task (extra points for both):

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

Difficulty: easy

Potential mentors:


Implement Impress 3D slide transitions for Windows

Extend the Impress 3D slide transition framework to also work on Windows. This needs some plumbing to make WGL work, and some fuzzing of the existing OpenGL code to be portably working across all three platforms.

Code pointer:

Required skills / knowledge C++, OpenGL (and on Windows), Reading other's code

Difficulty: easy

Potential mentors:

Implement animatable Chart objects for Impress

While basic object animation is available for every shape in Impress, particular Chart animations are not. It would be cool to have barcharts appear one bar at a time, smoothly animated, or pie charts building up in 3D.

Required skills / knowledge C++, Reading other's code, possibly OpenGL, some gaming / animation background helpful

Difficulty: medium / difficult

Potential mentors:


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:

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:

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.

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

Difficulty: difficult

Potential mentors:

Calc

Graphical Data Presentation in Conditional Formatting

Extend our current conditional formatting functionality to allow ways to present numerical cell values graphically as cell backgrounds. The values will be in relative scale within specified cell range.

The task will also include loading and saving of this feature in the ods and xlsx file formats.

Initial proof-of-concept patch is available here, which should serve as the starting point for completing this task.

Required skills / knowledge C++, Reading other's code, basic knowledge with graphics, optionally, legal access to Excel 2007/2010 is highly desired.

Difficulty: medium to hard

Potential mentors:


Performance Improvements

Currently we have a lot of places in Calc that are horribly slow and can be improved. This task would consist of several smaller tasks in different areas in Calc. The goal of this project is to reduce run-time memory footprint and to improve performance both during run-time and import/export.

Tasks may include (but not limited to):

Required skills / knowledge C++, Reading other's code, profiling with valgrind, basic knowledge with memory management.

Difficulty: medium to hard

Potential mentors:


Writer

Borders around characters

In Writer, the user can add borders to several objects like paragraphs, pages, frames, tables and their cells... but not around runs of characters. This feature has been asked multiple times since 2003 and could be implemented as a Summer of Code project. Quite a lot of informations and code pointers are available in the bug fdo#35155. This project will require you to add a new feature to the Writer core, change the document layout to display the border and change the import/export filters to save it.

Here are some code pointers to get started in the task (taken from the bug report):

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

Difficulty: medium

Potential mentors:


"Styles and Formatting" cleanup

The "Style and Formatting" toolbox is a bit overcrowded by default and comes with styles that will most likely never used. This task consists in cleaning up this dialog in several steps:

That task description is pretty big on purpose, but I may work on it too: so that would lower the student's work.

Some code pointers:

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

Difficulty: medium

Potential mentors:


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: as a mentor I may work on that topic at the same time as it's something I would like to hack on for quite a long time. Some design ideas can be found on this whiteboard and the corresponding long-standing bug report.

Here are a few major steps for the project:

Here are some code pointers to get started in the task:

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

Difficulty: medium to hard

Potential mentors:


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:

Here are some code pointers to get started in the task:

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

Difficulty: medium

Potential mentors:


Comments improvements

Comments in Writer are nice, but they suffer some lacks. The major one is that they can only be attached to a text position, not to a text range (see fdo#38244). Implementing this isn't necessarily complex as most of the important changes to the core have been made a while ago, but these all need to be gathered. The other important thing missing is to have basic formatting of the text inside the comment. This task is about implementing those changes to be praised by the waiting users.

Another important point that can be handled in this task is the printing of these comments, see bug fdo#36815 for ideas and details on this.

Here are some code pointers to get started in the task (taken from the bug report):

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

Difficulty: easy

Potential mentors:

Grammar checking: supporting more languages

LanguageTool has got great grammar checker rule sets for several languages. The task is to develop conversion tools for Lightproof (see Lightproof rule editor), the native grammar checker of LibreOffice to use the result of the LanguageTool development.

The project could be split into several parts:

Required skills / knowledge XML, Python, reading other's Java code

Difficulty: medium to hard

Potential mentors:

Filters

Implement Microsoft Publisher Import filter for LibreOffice

The MS Publisher file format has recently been reverse engineered, this task will involve turning that documentation into a functioning import filter. The filter will consist from a standalone library and a glue code inside LibreOffice. Although the file-format was reverse-engineered in its main structure and information, some amount of reverse-engineering would be necessary to get the missing information needed for the implementation. The student will be working in team with his mentors, who are experienced in reverse-engineering file-formats and writing import filters.

Required skills / knowledge C++, Readiness to become famous, Code reading and taste for hexadecimal editor

Difficulty: medium

Potential mentors:


Improve and extend the CorelDraw Import filter for LibreOffice

LibreOffice has currently the best FOSS import filter for CorelDraw files. This filter supports versions 7 to 15 of the file-format, which was reverse-engineered five years ago. This project would aim at the extension of features supported by the import filter, at supporting older versions of the file-format, as well as at extend this filter to support the Corel Presentation Exchange format (CMX). Although this file-format has an existing documentation, a little amount of reverse-engineering would be necessary to get the details right. The student will be working in team with his mentors, who are experienced in reverse-engineering file-formats and writing import filters.

Code pointers:

Required skills / knowledge C++, Readiness to become famous, Code reading and taste for hexadecimal editor

Difficulty: medium

Potential mentors:


Implement Quattro Pro Import filter for LibreOffice

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.

Required skills / knowledge C++

Difficulty: easy

Potential mentors:


Use PDF import's layout recognition for other vector formats (e.g. postscript, wmf/emf)

LibreOffice PDF import employs some amount of layout recognition techniques, to generate a layout-compatible document. Leveraging this framework for other vector formats will make LibreOffice an editor not only for PDF, but also for Post``Script, EMF, XPS - whatever the successful applicant for this task chooses to import.

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

Difficulty: medium

Potential mentors:


Enhanced flash export filter

LibreOffice's flash export does not deal with the new slide animation framework, it would be nice to create movies containing all/most slideshow animations.

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

Difficulty: medium

Potential mentors:


Improve DOCX tokenizer (import filter)

LibreOffice's DOCX importer has two major parts: first a tokenizer generates an intermediate parse tree from the input document, then a "domain mapper" (dmapper) maps the concepts of Microsoft formats to the Writer concepts. The dmapper is common for the RTF and DOCX formats already. The current DOCX (ooxml) tokenizer is generated code from XML configuration data using XSL transformations, making it a nightmare to maintain and/or debug. The task is to rewrite the ooxml tokenizer as plain C++ code, as done for the RTF tokenizer already, using the existing dmapper.

Here are some code pointers to get started in the task:

Required skills / knowledge C++, passive XSL, reading other's code

Difficulty: medium

Potential mentors:


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:

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:


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.


Add UNO IDL support to doxygen

Currently the documentation for the LibreOffice SDK and http://api.libreoffice.org is generated by a custom tool called autodoc. This is a big mainenance burden, and LibreOffice should not be in the business of maintaining its own home-grown (or rather, inherited from OpenOffice.org) buggy documentation tool. For LibreOffice 3.5 the C++ part of the SDK documentation is already generated by doxygen, but unfortunately doxygen does not support UNO IDL very well. Also it may be necessary to add some features to doxygen that autodoc currently supports and that are used by the SDK documentation.

(If time permits then adding some support for GNU make to doxygen would perhaps also be nice...)

Required skills / knowledge C++, Reading other's code, knowledge about lexing/parsing would be useful

Difficulty: medium

Potential mentors:


Redesigned UNO Type Representations

Information about UNO entities (interfaces, structs, services, etc.) is currently represented in various formats. Textual IDL files use an unnecessarily verbose syntax and demand a C-style preprocessor. The runtime representation for binary UNO is a legacy filesystem-in-a-file format, not very space efficient and impossible to access via anything than the original C API. On the other hand, Java uses class files to encode the same information in yet another format.

What is sought is an overall simplification, keeping eyes on performance, usability, and compatibility. Ideas are for example to use a single simple textual representation both for IDL files as well as for the runtime representation, and to generate Java class files on demand from that representation, using a custom class loader. This could either target the current LibreOffice, in which case an important requirement is to not break backwards compatibility with existing extensions etc., or be a case study towards a future LibreOffice 4, which is planned to be incompatible with existing code.

Some documentation pointers are:

Some code pointers are:

Required skills/knowledge: C++, Java, reading and integrating with existing code

Difficulty: medium

Potential mentors:


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:

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

Difficulty: medium to hard

Potential mentors:


Tooling

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++ or Java, though adding system level tests in Python should be easy to do as well. 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:


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


Gcc like wrapper for MSC on cygwin and autotools compatibility

LibreOffice has quite a few external libraries dependencies that need to be build. These most still use the old dmake build process One of the obstacle to the conversion to gbuild (gnu-make based) is that the standard configure/make/make install does usually not work on Windows

The idea is the expand on Kendy's work on a ccache for windows, to present to the auto* tools a pseudo gcc that really use MSC in the back-end The work would also possibly involved other hacking needed to essentially make ./configure + make + make install work with minimum configuration on cygwin for most external libraries (at least the one that use a standard auto* build), and as a side bonus support ccache on windows

Required skills / knowledge C, Bash, autoconfi/automake/autotools

Difficulty: medium to hard

Potential mentors:

Personal tools
Namespaces
Variants
Actions
Wiki
Navigation
Toolbox
donate