GSoc Ideas
From The Document Foundation Wiki
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:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
- Jan Holesovsky, IRC: kendy, mail: kendy @ suse . cz
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
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
- Jan Holesovsky, IRC: kendy, mail: kendy @ suse . cz
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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
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:
- Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen @ canonical.com
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:
- Michael Meeks, IRC: mmeeks, mail: michael.meeks
suse.com
- Andras Timar, IRC: timar, mail: atimar
suse.com
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:
- Caolán McNamara, IRC: caolan, mail: caolanm
redhat.com
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:
- Muthu Subramanian , IRC: muthusuba, mail: sumuthu
suse.com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Tor Lillqvist, IRC: tml_, mail: tlillqvist @ suse . com
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:
- Eike Rathke, IRC: erAck, mail: erack @ redhat . com
- Michael Meeks, IRC: mmeeks, mail: michael.meeks
suse.com
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:
- Muthu Subramanian , IRC: muthusuba, mail: mail: sumuthu
suse.com
Basic
Bunch of Basic IDE improvements
- Dockable macro object explorer
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
- Dockable property sheet.
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
- Dialog and ( currently hidden ) Frame control should have support properties to enabled vertical and horizontal scroll bars, and of course the scroll bars should actually do something e.g. pan the window content and move the contained controls in the expected fashion.
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:
- Noel Power, IRC: noelp, mail: noel . power @ suse . com
- Andras Timar, IRC: timar, mail: atimar @ suse . com
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
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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:
- InsertBookmarkAsPage() is a good starting point.
Required skills / knowledge C++, Reading other's code.
Difficulty: easy
Potential mentors:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
Attach animations to styles
Currently, Impress styles control most of the visual shape appearance, but not the slideshow animation effect. Which is a pity, as the styles concept is pretty powerful inside LibreOffice, and provides a nice way to change animation settings and type for a great number of objects simultaneously. For a slightly different view onto the same problem, see this bug report.
Required skills / knowledge C++, Reading other's code.
Difficulty: hard
Potential mentors:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
- Caolan Mac Namara, IRC: caolan, mail: caolanm @ redhat . com
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:
- helper-thread: unzip to XML parse to namespace-handling to tokenisation - into swap-buffer
- main-thread 2: swapbuffer to XFastParser API and into the main app for populating any ODF document model.
Required skills / knowledge C++, a little XML, Reading other's code.
Difficulty: medium Potential mentors:
- Muthu Subramanian , IRC: muthusuba, mail: sumuthu
suse.com
- Michael Meeks, IRC: mmeeks, mail: mmeeks
suse.com
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):
- preview current or next slide on the mobile phone
- list presenter notes on the phone
Required skills / knowledge C++, Reading other's code, Android development
Difficulty: easy
Potential mentors:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
- Radek Doulik, IRC: rodo_, mail: rodo @ novell . com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . 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.
Required skills / knowledge C++, Reading other's code.
Difficulty: difficult
Potential mentors:
- Muthu Subramanian, IRC: muthusuba, mail: sumuthu @ suse . com
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Kohei Yoshida, IRC: kohei, mail: kohei.yoshida AT gmail DOT com
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):
- Compress XML content stream stored in memory, or off-load it to disk to avoid storing it in memory altogether. This alone may save 100's of MB of memory usage by Calc on large documents.
- Use cached formula calculation results from imported file, to avoid re-calculation on import.
- remove UNO calls from ods import, to significantly speed up the document import.
- reduce memory footprint in our undo documents, to keep run-time memory usage low.
Required skills / knowledge C++, Reading other's code, profiling with valgrind, basic knowledge with memory management.
Difficulty: medium to hard
Potential mentors:
- Kohei Yoshida, IRC: kohei, mail: kohei.yoshida AT gmail DOT com
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard AT googlemail DOT com
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):
- Core attributes IDs: http://opengrok.libreoffice.org/xref/core/sw/inc/hintids.hxx
- Character formatting dialog: http://opengrok.libreoffice.org/xref/core/sw/source/ui/chrdlg/chardlg.cxx
- Most of the layout painting code: http://opengrok.libreoffice.org/xref/core/sw/source/core/layout/paintfrm.cxx
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
"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:
- Add a Hide / Show actions for the styles to allow manually hiding styles in it. This feature will probably need to improve the ODF format.
- Hide automatically added styles by default, and show them when the styles are actually used. Such styles are the Index level styles and similar ones that aren't used unless an index is inserted in the document.
- Move the hard-coded styles definitions to a default template
- Create and integrate nice default styles
- Change it so that it fits the default layout of writer, and it is not necessary to have it as a separate dialog; or make the popping up of the dialog less annoying [needs input from the UX advise]
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:
- Popup menu handler of the tree list box in the dialog: http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2177
- Popup menu creation: http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2236
- Writer default styles hard-coded attributes: http://opengrok.libreoffice.org/xref/core/sw/source/core/doc/poolfmt.cxx#1079
Required skills / knowledge C++, Reading other's code
Difficulty: medium
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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:
- 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
Required skills / knowledge C++, Reading other's code
Difficulty: medium to hard
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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):
- The class linking the comment window to the writer layout is SwFrmSidebarWinContainer
- The class for the text control of the comment is SidebarTxtControl
- A good entry point for all the comments code is the SwPostItMgr class
Required skills / knowledge C++, Reading other's code
Difficulty: easy
Potential mentors:
- Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
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:
- conversion or direct usage of the tagging dictionaries (conversion to Python or Hunspell)
- conversion of XML rules (extending Lightproof, if needed)
- conversion of LanguageTool Java rules
Required skills / knowledge XML, Python, reading other's Java code
Difficulty: medium to hard
Potential mentors:
- László Németh, mail: nemeth at numbertext org
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:
- Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
- Valek Filippov, IRC: frob, frob_tea, mail: frob @ gnome . org
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:
- Existing CorelDraw import filter class: CDRImportFilter
Required skills / knowledge C++, Readiness to become famous, Code reading and taste for hexadecimal editor
Difficulty: medium
Potential mentors:
- Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
- Valek Filippov, IRC: frob, frob_tea, mail: frob @ gnome . org
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:
- Michael Meeks, IRC: mmeeks, mail: michael.meeks
suse.com.com
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:
- Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com
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:
- Fridrich Strba, IRC: Fridrich, mail: fridrich . strba @ bluewin . ch
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
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:
- The writerfilter::Stream class defines the interface between the tokenizers and dmapper and lives in writerfilter/inc/resourcemodel/WW8ResourceModel.hxx
- The dmapper is under the writerfilter/source/dmapper/, the current ooxml tokenizer is under writerfilter/source/ooxml/. Additional documentation here.
Required skills / knowledge C++, passive XSL, reading other's code
Difficulty: medium
Potential mentors:
- Miklos Vajna, IRC: vmiklos, mail: vmiklos @ suse . cz
- Lubos Lunak, IRC: llunak, mail: l.lunak @ suse . cz
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:
- Radek Doulik, IRC: rodo_, mail: rodo @ suse . com
- Jan Holesovsky, IRC: kendy, mail: kendy @ suse . cz
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:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
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:
- Using UNOIDL to Specify New Components (from the Developer's Guide)
- UNOIDL Syntax Specification (from the Developer's Guide)
Some code pointers are:
-
idlcfor the current UNOIDL compiler -
codemakerfor the tools translating type information into C++ header and Java class file representations
Required skills/knowledge: C++, Java, reading and integrating with existing code
Difficulty: medium
Potential mentors:
- Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
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
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:
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard AT googlemail DOT com
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:
- Norbert Thiebaud, IRC: shm_get, mail: nthiebaud AT gmail.com