Development/GSoC/Successfully Implemented Ideas

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 Weblate), 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: weblate as the platform where translation happens or opengrok where the source code is indexed)


 * Potential mentors
 * Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org

Tests for the VCL graphic backends
We currently have some graphic tests located here, but they are incomplete and aren't being checked. The purpose of the tests is to identify if a graphic backend works correctly, which is especially important if the backend depends on the client hardware or drivers (like for example the Skia/Vulkan backend).

Each test draws to a small surface (VirtualDevice) and evaluates if what was drawn is correct or not by looking at the pixels. As backends don't draw equally (especially when using AA), it is needed to allow for a bit of discrepancy of the values (for example sometimes a backend won't draw one pixel). In this case the test is marked as "quirky" (acceptable result, but not what is expected).

First part of this task is to write additional tests that cover more graphic functions in VCL, then make this tests run when building a backend as well as when the user uses the backend for the first time (Skia/Vulkan for example). Also allow the user to run the tests and view the results for himself (add the UI for this).


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


 * Difficulty: Medium


 * Potential mentors
 * Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com

Make SVM (StarView Metafile) format independent of the VCL Metafile + tests of the format
The SVM file is a 1 to 1 dump of the content of VCL Metafile. This makes the VCL Metafile hard to modify as the SVM shouldn't change (for example to change away from the old geometry primitives in "tools" module - PolyPolyon, Polygon, Point, Rectangle,...) so to make this possible we need to separate the two. This is also very important to allow further refactoring of VCL to make it more modern (for example native 32-bit bitmaps and surfaces and to use alpha transparency and blending of the backends and not do its own thing).

This task would include to first complete the (import/export) test of the SVM format which are located here. The second part is then separate file writing/reading of the VCL Metafile to its own classes, to make them independent.


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


 * Difficulty: Medium


 * Potential mentors
 * Tomaž Vajngerl, IRC: quikee, mail: quikee@gmail.com

Styles Highlighter
Styles are the essence of a text processor. And while experts love to unleash the power of LibreOffice Writer, it’s at the same time a major source of nuisance. In particular when you receive documents from other people, it can be quite difficult to understand the applied formatting and to fix issues around. This project aims to improve the situation by showing in the document what styles are applied. https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/


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


 * Difficulty: Varying


 * Potential mentors
 * Tomaž Vajngerl, Mike Kaganski

100 paper cuts
The student will solve a number of most-annoying issues and enhancement requests during the GSoC time. Issues are collected in https://nextcloud.documentfoundation.org/s/zraEHZxyCKBTNY7 with a rough estimation on effort.

If you want to apply for this, you should first solve one of the papercuts (pick an easy one) in advance.


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


 * Difficulty: Varying


 * Potential mentors
 * Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com

Implement interface for external data source import into Calc
With more and more data in different forms it becomes more and more challenging to visualize and evaluate them. Calc could be an amazing tool to allow inspecting existing data. To allow that we would need an interface to import and more importantly update data from external data sources. The interface should be modelled similar to how the orcus interface is currently implemented and the data should be stored inside of a ScDBData (a database range). The interface would then be used together with either an existing document where you mark a range for the external data or a template document that is automatically filled. The initial work on providing some structure has already been done in sc/source/ui/dataprovider/ and in sc/source/ui/miscdlg/dataproviderdlg.cxx

This task is about extending the existing data providers and data transformations, implementing an usable UI for the feature and start working on storing the information in a file.


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


 * Difficulty: Medium


 * Potential mentors
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Implement table styles DOCX support
Writer currently supports the use of table styles and saving them to ODF format. On the other hand table styles found in DOCX files are imported as direct table cell formatting. This is only a temporary solution and causes loss of formatting (dynamic banding) upon editing the table. Another downside of converting formatting defined in table styles is that it significantly reduces the file opening performance of Writer. Bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=101757

This task aims to build on the results of the earlier GSoC project that brought the functionality and ODF support.


 * Major steps of the project
 * Implement DOCX import
 * Remove existing style-based formatting conversion to direct formatting
 * Extend the existing table style feature as necessary. For example an important, not yet supported property is style inheritance.


 * Code pointers


 * Current table style import: https://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/StyleSheetTable.cxx
 * feature/table-style branch in git
 * Documentation of the OOXML specification for table styles: http://www.officeopenxml.com/WPstyleTableStylesCond.php
 * ODF specification for table styles: https://docs.oasis-open.org/office/OpenDocument/v1.3/csd03/part3-schema/OpenDocument-v1.3-csd03-part3-schema.html#element-table_table-template
 * There is a comprehensive example document attached to https://bugs.documentfoundation.org/show_bug.cgi?id=118812


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Hard
 * Potential mentors: Laszlo Nemeth mail: nemeth at numbertext dot org

Move the gallery code to use ZIP files
The existing gallery code (as seen in the sidebar eg.) is extremely cumbersome. It uses some hideous custom made binary file formats - which are completely un-necessary.

The code all lives in svx/source/gallery2 - is reasonably self-contained and comprises under 6000 lines of code - making this reasonably easy to work with I hope.

New themes are built with 'gengal' - but old themes are still present in the source file as un-touchable binary files. These contain many useful pieces for LibreOffice - and we need to be able to edit and extend these easily. So - parts of this project would be:


 * read and write notes on the existing gallery code.
 * add comments to each class header describing the function of the class etc.
 * extend the 'gengal' tool to extract file streams out of our old file formats and store them as individual files with annotations.
 * research the package2/ zip code, and write a tool to dump ZIP file contents.
 * package up the above streams in a suitable form - and write new package code to read these.


 * For bonus points we should be able to ingest ODP presentations with a title + a shape per slide - and thumbnail and insert these into the gallery with a simple name + the content of that shape; but that's rather more fun.


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


 * Difficulty: Medium


 * Potential mentors
 * Tomaž Vajngerl, IRC: quikee, mail: quikee @ gmail.com
 * Michael Meeks, IRC: mmeeks, mail: michael.meeks @ collabora.com

Styles Inspector
Styles are the essence of a text processor. And while experts love to unleash the power of LibreOffice Writer, it’s at the same time a major source of nuisance. In particular when you receive documents from other people, it can be quite difficult to understand the applied formatting and to fix issues around. This project intends to improve the situation with an Inspector that more clearly gives an overview of the attribute inheritance. https://design.blog.documentfoundation.org/2019/11/05/proposal-to-conveniently-highlight-and-inspect-styles-in-libreoffice-writer/

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

Difficulty
 * Varying

Potential mentors
 * Mike Kaganski, Tomaž Vajngerl

Additions - Tight integration of extensions!
The idea of additions is to better integrate extensions. On various places it should be possible to get more content from external storage. It is an "addition" as it rather provides presets than extensions like macros or templates; but the procedure behind might be similar. https://design.blog.documentfoundation.org/2016/11/11/additions-to-libreoffice/

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

Difficulty
 * Varying

Potential mentors
 * Muhammet Kara, IRC: mkara, mail: muhammet.kara AT collabora.com

Blurry shadows
In LibreOffice the shadows are just a copy of the object. Blurring with some options is missing, and well known in competitive open-source tools like Calligra. This feature is also needed for SVG import/export.

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

Difficulty
 * (Medium)?

Potential mentors
 * Tomaž Vajngerl, IRC: quikee mail:
 * UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

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: https://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: thb @ documentfoundation . org

Extending the UITest framework
The UI testing in LibreOffice is based on introspection code in C++ interacting with a testing framework in python through a simple UNO interface. To identify objects we use the ids that we introduced for loading dialogs from UI files. We still have unsupported items in LibreOffice UI testing Framework. We also have a domain specific language that we use to log events. We have a logger that supports the UI elements of Visual Class Library while some application-specific events can also logged. The main goals of the project is to extend the ability of the existing UI testing framework to support the currently unsupported items. The ability of the DSL should be increased in order for it to be able to log more complex events and the events of the newly added items that were unsupported before. We should be able to generate more meaningful test cases with the DSL and not just to replay the user actions from the logger. Finally, we should add new generic methods for writing test cases for new bugs.

Student: Ahmed ElShreif

Mentors: Xisco Faulí, Markus Mohrhard

Generating QR codes
The project idea was to integrate a QR code generating library in LibreOffice and to add options for using the generated QR codes in LibreOffice applications.

Student: Shubham Goyal

Mentors: Thorsten Behrens, Samuel Mehrbrodt

LibreOffice for Android (Online)
The project was about improving LibreOffice's Online implementation over Android by adding new features to the document viewer, fixing the most annoying bugs and enhancing the overall UI/UX on the basis of design and performance.

Student: Kaishu Sahu

Mentors: Tomaž Vajngerl, Jan Holešovský

LibreOffice appliances
LibreOffice runs on very cheap ARM hardware now, like the Rasperry Pi (25$), Ouya (99$), the ODROID-X (129$), the Pandaboard (~180$). All of these can display Impress presentations. Multiple products can be imagined with that:

shop slide display
 * A raspberry pi board that:
 * when connected to a LAN:
 * runs a minimal HTTP server to upload a presentation
 * displays the URL to upload the presentation on the screen
 * when disconnected, starts to loop the presentation

All in all, this could be a <50$, easy to use and low energy display solution for shopping windows of small shops etc.

conference/hotel room display server (on e.g. a Pandaboard) The same as above, except that it allows a few more things:
 * constantly running the server, which allows:
 * uploading multiple presentations
 * serving the uploaded presentations as odp and pdf
 * queuing the presentations in a playlist
 * moving through the 'current' presentation with the Android remote

So a conference could get rid of all the:
 * 'my notebook doesnt work with the screen'
 * 'can I just give you my slides on a USB stick so we dont have to switch machines'
 * 'hey, I somehow have to collect the slides from everyone, and they are already on their flights home'
 * 'we want to make lighting talks, we need all the stuff on one machine somehow'

madness, for some 150-200$ plus an old Android phone. And the Android Remote is really nifty for itself, and this conveniently circumvents the setup (which is the most tricky part with it).

Given the prices conference room hardware usually has, the second one might actually be commercially exploitable.

Required skills / knowledge: Building LibreOffice on ARM, some C++, Webserver could possibly be done in Pythons httplib without too much reinventing the wheel Difficulty: involved Potential mentors: Matúš Kukan, IRC: matus, mail matus DOT kukan AT gmail DOT com

Improvements to Notebookbar
Notebookbar reuses UI files definition known from Gtk+ (.ui files) as created by the Glade tool for upper part of the LibreOffice window, giving lots of freedom to the designers how to organize the UI. Current implementation has advanced during the last GSoC, but it is still incomplete: The content is cropped on resize, theming is not respected, and new functions such as style dropdown haven't been introduced yet. Beyond that, the customization via Glade is not suitable for normal users, and quick customization like toolbutton on/off is not possible.

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

Difficulty
 * Medium

Potential mentors
 * Jan Holesovsky, IRC: kendy mail: kendy @ collabora.co
 * Szymon Klos, IRC: eszka mail: szymon.klos @ collabora . com
 * UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Improve the UI testing DSL and the log files for UI actions
The UI testing is one of our newest additions to our testing frameworks. The code is split between a C++ layer wrapping our GUI toolkit and a python test framework with the actual tests. Recently some work was done to start creating log files and convert them again to python code. This covers already a good bit of our actions [1][2]. During this task the existing work should be extended and simplified.

Most of the python part of the framework can be found in the uitest/ module.

Most of the commits related to the framework are prefixed with uitest: and can be found with this git search.

The file with most of the C++ wrappers can be found here.


 * Required skills / knowledge: Python, a bit of C++, reading other's code


 * Difficulty: Medium


 * Potential mentors
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Implement chart styles
Chart styles allow to quickly apply the same formatting presets to different charts and would allow us to more easily change charts. Currently all chart formatting is directly applied and this task would be to add one additional layer of indirection into the chart formatting. Most of the framework for direct formatting in charts can be extended to support chart styles. A bit of analysis can be found at https://wiki.documentfoundation.org/Chart_styles


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


 * Difficulty: Medium
 * Potential mentors
 * Markus Mohrhard, IRC: moggi @ #libreoffice-calc, mail: markus.mohrhard@googlemail.com

Add Python extension support to LOEclipse
LOEclipse is an Eclipse plugin which supports developing & debugging Java extensions/components for LibreOffice. It is built in such a way that it can be extended to support other languages than Java. The task is to add support for Python extensions to LOEclipse.

Required skills / knowledge Java (LOEclipse is written in Java), Python (to understand Python extensions), Basic understanding of the Eclipse IDE and Platform

Difficulty: medium

Prerequisite To be accepted for this project, you don't need to do an Easy Hack in LibreOffice itself. Instead you should work on one of the LOEclipse issues and submit a pull request for it.

Mentors:
 * Samuel Mehrbrodt, IRC: samuel_m, mail:

Revamp print dialog
Current print dialog has an unclear workflow where for instance the page format does not match printer settings. Rework is needed to align the document/page settings with the printer settings. There is also a proper feedback required for the various settings and what will applied when printing. Last but not least the print dialog is cluttered and needs a clean-up. Mockups

Required skills / knowledge
 * C++, UI, reading other's code

Difficulty
 * Medium

Mentors
 * Katarina Behrens, IRC: bubli mail:bubli @ bubli . org
 * UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org


 * Student
 * Daniel Silva

Add a DSL to the UI testing and improve the generated log file
The UI testing is one of our newest additions to our testing frameworks. The code is split between a C++ layer wrapping our GUI toolkit and a python test framework with the actual tests. Recently some work was done to start logging UI actions when they happen and generate log files that are close to the python test files. The next step is to define a domain specific language (DSL) that we can use to represent the UI testing actions and instead of generating log files generate these files. Additionally with a replay mode in the python framework it should be possible to replay the UI actions automatically. Such a feature would allow to easily add new tests and make bug reporting much easier.

As part of this GSoC project the DSL, the logging to the DSL format and the replay should be implemented. If there is enough time or the need for it the C++ layer should be extended to support more UI elements.

Most of the python part of the framework can be found in the uitest/ module.

Most of the commits related to the framework are prefixed with uitest: and can be found with this git search.

The file with most of the C++ wrappers can be found here.


 * Required skills / knowledge: Python, a bit of C++, an idea how to design a DSL


 * Difficulty: Medium


 * Potential mentors
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

Improvements to Notebookbar
Notebookbar reuses UI files definition known from Gtk+ (.ui files) as created by the Glade tool for upper part of the LibreOffice window, giving lots of freedom to the designers how to organize the UI. Current implementation has advanced during the last GSoC, but it is still incomplete: The content is cropped on resize, theming is not respected, and new functions such as style dropdown haven't been introduced yet. Beyond that, the customization via Glade is not suitable for normal users, and quick customization like toolbutton on/off is not possible.

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

Difficulty
 * Medium

Potential mentors
 * Jan Holesovsky, IRC: kendy mail: kendy @ collabora.co
 * Szymon Klos, IRC: eszka mail: szymon.klos @ collabora . com
 * UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

Listbox separate read values from input values
A listbox acts as a mapping between values and display strings. The database (in general the value of the control) is one thing (drawn from the list content property), but the string shown to the user is another thing (drawn from the list entries property).

But these are actually used for *two* roles:
 * values read from the database
 * values input by the user

Sometimes, it is possible that the database contains values that the user should not be allowed to input. For example, historic / deprecated values, or more to the point the valid values depend on the value of other fields (or controls). One would then wish that the drop-down list feature only those values that are allowed in these particular circumstances.

The idea is to duplicate the "list entries" and "list contents" properties:
 * once for the role of mapping values read from the database(find what to display given a database value)
 * once for the role of mapping an entry chosen by the user to a database value (find what to write to the database when the user selects a list entry by its display string)

The idea is that the second set would in general be a subset of the first set, thereby giving the user a more limited selection for data entry, but still keeping the possibility of providing a user-friendly display string for other values read from the database.

How to handle listbox with Drop Down set to False is an open question.


 * Required skills / knowledge: C++, capacity to work autonomously.


 * Difficulty: medium


 * Potential mentors:Lionel Elie Mamane, IRC: schoinobates, mail: lionel AT mamane DOT lu

Implement interface for external data source import into Calc
With more and more data in different forms it becomes more and more challenging to visualize and evaluate them. Calc could be an amazing tool to allow inspecting existing data. To allow that we would need an interface to import and more importantly update data from external data sources. The interface should be modelled similar to how the orcus interface is currently implemented and the data should be stored inside of a ScDBData (a database range). The interface would then be used together with either an existing document where you mark a range for the external data or a template document that is automatically filled. The initial work on providing some structure has already been done in sc/source/ui/dataprovider/ and in sc/source/ui/miscdlg/dataproviderdlg.cxx

This task is about extending the existing data providers and data transformations, implementing an usable UI for the feature and start working on storing the information in a file.


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

Difficulty: Medium


 * Potential mentors
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com

LibreOffice for Android
LibreOffice works nicely on Android these days, but there are stil many things to improve and fix. This task will focus on the Android Most Annoying Bugs:

https://bugs.documentfoundation.org/showdependencytree.cgi?id=84726&hide_resolved=1

and also on new features, like printing.


 * Required skills / knowledge: C++, Java.


 * Difficulty: Medium


 * Potential mentors
 * Tomaž Vajngerl, IRC: quikee mail: tomaz.vajngerl @ collabora.co.uk
 * Miklos Vajna, IRC: vmiklos mail: vmiklos @ collabora.co.uk

Revamp the Customization dialog
The Tools > Customization dialog lacks today on supporting means. For instance, it is not possible to search for a particular function. It also has an interface with focus on technical facts rather than the workflow. With a redesign the functionality should remain as it is but updated so that average users are able to customize their program. Mock-up

Required skills / knowledge
 * C++, UI, reading other's code

Difficulty
 * Medium

Mentors
 * Katarina Behrens
 * UX team

Student
 * Muhammet Kara

Implement QuarkXPress import filter
QuarkXPress is a desktop publishing application that once dominated the DTP world, which means there are lots of existing documents. The goal of this task is to reverse-engineer the document format produced by QuarkXPress 4--which was, as I've been told, the last widely used version--and create an import filter for it. The filter will be a library based on librevenge.


 * Required skills / knowledge
 * C++, reading other's C++ code (to reuse code from existing libraries)
 * Python (for OLEToy)


 * Difficulty: Medium


 * Mentors
 * David Tardon


 * Student
 * Aleksas Pantechovskis

Replace EditEngine binary clipboard with ODF filter
EditEngine still uses a legacy StarOffice format with SfxItemPool binary serialization for copy/paste. This is a maintainability problem and the only user of SfxItemPool serialization outside of the table auto-formats. This should be replaced by using the ODF filter (xmloff) for copy/paste instead. The legacy format is used if you edit inside some text in Draw/Impress/Calc and copy a selection to the clipboard.

Required skills / knowledge C++, Reading existing C++ code

Difficulty Medium

Mentors:
 * Michael Stahl
 * Eike Rathke


 * Student
 * Varun Dhall

LibreOffice for Android
LibreOffice works nicely on Android these days, but there are stil many things to improve and fix. This task will focus on the Android Most Annoying Bugs:

https://bugs.documentfoundation.org/showdependencytree.cgi?id=84726

and also on new features, like printing.


 * Required skills / knowledge: C++, Java.


 * Difficulty: Medium


 * Potential mentors
 * Miklos Vajna, IRC: vmiklos mail: vmiklos @ collabora.co.uk
 * Tomaž Vajngerl, IRC: quikee mail: tomaz.vajngerl @ collabora.co.uk

LibreOffice for Android - migration to Clang toolchain

 * Student
 * Aditya Dewan

SmartArt editing in Impress
SmartArt is a nice feature that allows users to quickly add charts / diagrams to presentations. We have a partial implementation as an experimental feature; the task of this GSoC would be to finish it.

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. 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:. An external extension (not nicely integrated) trying to implement at least some SmartArt functionality: SmART (Extensions/SmART Gallery)


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


 * Difficulty: Difficult


 * Potential mentors
 * Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
 * Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com

Multi-threaded unzip / XML parsing
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 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.

This should give us a 10-15% speedup for certain kinds of simple files - and as we continue to improve the calc core elsewhere that proportion should grow. Checkout for a sample document and profile.

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

Difficulty: medium Potential mentors:
 * Muthu Subramanian , IRC: muthusuba, mail:
 * Michael Meeks, IRC: mmeeks, mail:

LibreOffice Online
LibreOffice online has developed significantly during the last year, but there is still a lot to do there. This task will include changes in the LibreOfficeKit, and in the web/JavaScript part too.

The main focus will be on making the features knows from the desktop version available in the Online version too; like the pivot tables, or other.

The online work takes place mostly in the online.git reporsitory: https://cgit.freedesktop.org/libreoffice/online/


 * Required skills / knowledge: C++, JavaScript optional.


 * Difficulty: Medium


 * Potential mentors
 * Jan Holesovsky, IRC: kendy mail: kendy @ collabora.com

Usability of Special Characters

 * Student
 * Akshay Deep

Redesigning the Template Manager
Issues:
 * User initially sees a collection of folders that they have to go into in order to get to any templates
 * All templates from a particular app/module aren't available in one location
 * User can navigate into template folders that have nothing in them
 * OK/Open and Cancel buttons are not found at bottom of dialog as HIG recommends
 * UI feels more like a file manager when it should be focused on being a template browser
 * Template manager’s bad design causes problems with its integrated into the start center


 * Code pointers:
 * Code: https://cgit.freedesktop.org/libreoffice/core/tree/sfx2/source/doc/templatedlg.cxx
 * UI: https://cgit.freedesktop.org/libreoffice/core/tree/sfx2/uiconfig/ui/templatedlg.ui


 * UI Concept:
 * https://docs.google.com/document/d/1JRPNdeHQpgqiqJv8LW-RHOjtHN8EMX0qK98QBnr10Yg/edit?pref=2&pli=1
 * https://docs.google.com/document/d/1Ri2jznhcQmCtk3cVygEhwN7pi8FkbIVV_OvRQce_n6Y/edit?pref=2&pli=1#heading=h.icneug3ebnpf
 * - Start Impress with template manager
 * - Improve Save as Template workflow


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


 * Difficulty: Medium


 * Mentors
 * Samuel Mehrbrodt, Yousuf Philips


 * Student
 * Akshay Deep

Infrastructure for defining toolbars via .ui (Glade) files
The goal of this task is to create a new toolbar implementation that allows dynamic layout of widgets, and potentially tabbed toolbars too. Using that, it will be possible to easily define rich toolbars using Glade as the user interface designing tool.

What needs to be done:
 * Load toolbar definition(s) from .ui files
 * Create new custom widgets and C++ implementation for them
 * Implement mechanism to show/hide them depending on the context (Current application and currently selected object)
 * Improve the look of various widgets for their presentation in the toolbar (where necessary - like smaller padding around the widget etc.)
 * Implement priorities for widgets to allow dynamic hiding according to screen size

As we want to reuse as much of the existing code as possible, this work will heavily base on the Widget layout work and also on the sidebar implementation.

More tasks after the grounds have been laid:
 * Find a way to let the user customize the panels (like it is possible to customize the current Toolbar).
 * Extension integration: Allow extensions to add their own buttons/widgets to a panel

To get started, read the Sidebar code (sfx2/source/sidebar), and fix some Sidebar related bugs.


 * Code pointers:
 * Sidebar implementation
 * Sidebar configuration
 * Sidebar panels shared across applications
 * First approach to the Notebookbar


 * Required skills / knowledge: C++, Glade


 * Difficulty: Medium


 * Mentors
 * Samuel Mehrbrodt, Jan Holesovsky


 * Student
 * Szymon Kłos

Table styles
Issues: UI concept:
 * No common dialog
 * Style should be independent from the content (alternating rows)
 * No access from sidebar (either at styles/formatting or a sidebar for all table settings)
 * Similar workflow intended (sometimes) in Impress and Calc intended (Autoformat)
 * : Table Cell Styles / Table Styles
 * : Table content panel or tab
 * https://docs.google.com/document/d/1FPkf9fn79dXJ5tHpc-meMYxaQpj3nV5sEN6u9HOo2GQ
 * https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/


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


 * Difficulty: Medium


 * Potential mentors
 * Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
 * UX team, IRC:, mail: design @ global.libreoffice . org
 * Heiko Tietze, IRC: htietze, mail: tietze.heiko @ gmail . com
 * Yousuf Philips, IRC: jphilipz, mail: ypharis @ gmail . com

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. Further information can be found in the related LibreOffice bug entry:.

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: https://opengrok.libreoffice.org/xref/core/sw/source/ui/table/tautofmt.cxx
 * Auto-format application code (start of the track): https://opengrok.libreoffice.org/xref/core/sw/source/core/frmedt/fetab.cxx#SetTableAutoFmt
 * feature/table-style branch in git

Documentation of the OOXML specification for table styles: http://www.officeopenxml.com/WPstyleTableStylesCond.php


 * 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

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, but the most important parts of the file format have already been reverse engineered. Additional efforts to reveal details will be required.

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:

Implementing legacy SAX parser Interface with FastParser
The idea is to implement XParser(legacy) and related APIs using XFastParser and push the tokenization incrementally through to ODF import filters in xmloff/ module. FastParser has free parsing in another thread, so performance boost is expected.

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

Difficulty: medium


 * Mentors:
 * Noel Grandin
 * Michael Meeks


 * Student:
 * Mohammed Abdul Azeem

Finish Firebird driver integration
Base's embedded database is currently an outdated copy/fork of HSQLDB 1.8, which holds us back because of data corruption issues (arising mainly from how the integration is done) and lack of features (because old copy that did not follow the progress of HSQLDB).

Rather than upgrade to a newer HSQLDB, it has been decided to switch to FireBird, mainly because of issues around depending on Java and performance issues with interfacing with Java in general.

The Firebird driver for LibreOffice was started, and is mostly functional, in a previous GSoC, but it needs finishing and polishing. The main remaining issue is that the firebird data format embedded in the .odb file is endianess-dependent. The idea is to switch to Firebird's "archive" format that is not.


 * Required skills / knowledge: C++, SQL, Reading other's code, capacity to work autonomously.


 * Difficulty: medium


 * Mentors:
 * Lionel Elie Mamane, IRC: schoinobates, mail: lionel AT mamane DOT lu


 * Student:
 * Tamás Bunth

Support ODF styles in orcus
Orcus is an external filter library for spreadsheet format that is used by LibreOffice. The library is mainly developed by one of the leading LibreOffice calc developers and already used for gnumeric import, the csv import in tests and optional odf and ooxml import. The support for styles is however still rudimentary but we would like to use it to support xml based pre-defined styles. The task would be to first add the odf styles support to orcus and then implement the corresponding interface on the LibreOffice side.


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

Difficulty: Easy to Medium


 * Mentors:
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
 * Eike Rathke


 * Student:
 * Jaskaran Veer Singh

Unify low level text layout on HarfBuzz
Currently we use at least three different text layout systems (and half a dozen implementations of the SalLayout class) in VCL; Uniscribe on Windows, Core Text on Mac OS X and HarfBuzz everywhere else.

This have the advantage of being consistent with other applications on each platform (theoretically at least, since our integration code is often subpar). However, it has several disadvantages; first we need to maintain 3+ different text layout code paths with little sharing between them, which increases the complexity of our text layout code and platform-specific bugs and inconsistencies. We also are limited on Windows and Mac OS X by what both platforms provide in terms of complex text layout support, so we have don’t have the same language support on, say, Windows XP compared to Windows 10.

HarfBuzz is a free software text layout engine, it is actively developed and supported, both Firefox and Chrome switched to using it on all platforms to avoid the situations outlined above. LibreOffice would do the same and the existing HarfBuzz integration code would be generalised to be used on all platforms, phasing out and eventually dropping platform-specific alternatives.


 * Required skills / knowledge: C++, Reading other's code, Base understanding of text layout


 * Difficulty: High


 * Mentors:
 * Khaled Hosny, IRC: KhaledHosny, mail: khaledhosny@eglug.org
 * Michael Meeks, IRC: mmeeks, mail: michael.meeks@collabora.com


 * Student:
 * Akash Jain

Review of the sidebar & its functionality
Many things in the sidebar are not finished yet, and also some of the modeless dialogs might provide much more value if they were sidebars; eg. the Insert -> Cross-reference... feels like a functionality that would fit to the sidebar; and for sure there are more.

Also there is prototype code for change tracking in the sidebar, finishing it would fit this task too.


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


 * Difficulty: Medium


 * Mentors:
 * Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
 * Yousuf Philips, IRC: jphilipz, mail: ypharis @ gmail . com


 * Student:
 * Susobhan Ghosh

Integrate gtktiledviewer into GNOME-Documents
Today GNOME Documents spawns LibreOffice via a rather unreliable unoconv command-line that converts documents to PDF. Instead it would be awesome to substantially improve and re-use libreoffice via our existing LibreOfficeKit based gtk tiled renderer.

This project has several stages:


 * Improving tiled rendering in gtktiledrender.
 * re-use the MPLv2 Mozilla tiled rendering code in C++ and integrate that into the LibreOffice core checkout Off Main Thread Compositing
 * adapt the front-end to render gtk+ tiles.


 * Required skills / knowledge: C++, gtk+ optional.


 * Difficulty: Medium


 * Mentors:
 * Michael Meeks, IRC: mmeeks mail: michael . meeks @ collabora.com
 * Miklos Vajna, IRC: vmiklos mail: vmiklos @ collabora.co.uk


 * Student:
 * Pranav Kant

Rework the Expert Configuration dialog
The "Expert Configuration" dialog is too slow to appear with accessibility enabled. This is because the amount of configuration entries is just too large for practical use in a single list. The list should be reworked to be a tree of options and progressively show/hide branches of the options tree to work with blocks of smaller segments of options.


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


 * Difficulty: Medium


 * Mentors:
 * Caolan McNamara, IRC: caolanm, mail: caolanm @ redhat . com


 * Student:
 * Mihály Palenik

Cleanup internal drawing units in Calc
Calc currently uses a mix of specifying the units that are used when drawing - mixing drawing in pixels, and drawing in 1/100's of mms. This task would be about converting all functions to use a common unit of measurement.


 * Student:
 * Krisztian Pinter

Dynamic Text Chaining and Hyphenation in Draw

 * Student:
 * Matteo Campanelli

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 Python, 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:
 * UNO Type System
 * UNO Object Life Cycle Model
 * Uno Remote Protocol
 * as an example of an in-process UNO bridge (for Java, via JNI)
 * as 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

Mentor:
 * Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com


 * Student:
 * Jorge Mendes

Improve user experience with CMIS / Gdocs / OneDrive / ... setup
The current UI to connection to a remote repository is not too straight-forward, so instead, an easy way should be implemented to integrate the access to these cloud services. This would entail the addition of an 'Open Online' button into the start center and toolbars which would provide a simple dialog to easily select a cloud service and type in their username and password and then a user would be sent to file select dialog to open the file they need. The simple dialog should remember the last cloud service selected. For users of LibreOffice's custom dialog, they will be provided will exist entries in its places section of these popular services. Part of this might be also improving the local file access, like providing document preview in the system file dialogs etc.


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


 * Difficulty: Medium


 * Mentors:
 * Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
 * Cedric Bosdonnat, IRC: cbosdonnat, mail: cedric @ bosdonnat . fr


 * Student:
 * Szymon Kłos

Improve automated error checking
Handling of large spreadsheets is complex and it is nearly impossible to discover errors that have been introduced into the document. This task is about adding some tools and checks to find and prevent errors in spreadsheet documents. This task can be split into several tasks and the list below with possible ideas is just a collection for further brain storming. Managing the risk of dealing with huge spreadsheets is an open research topic and provides many ways to incorporate your own ideas.

A few ideas that might be used as a starting point:
 * Improve the current validation feature (This feature allows to provide requirements for cells but is currently very limited)
 * Detect broken formula groups -- A formula group is a continuous range in a column that contains the same token sequence. Detecting when a single cell breaks such a group and splits it into two might indicate an error.
 * There is currently a project to add units to cells (meter, seconds, ...) and detect when calculations don't match, like adding meters to seconds. This feature could be improved and integrated with the validation feature.
 * Better handling for currency formats. One of the most error prone tasks in accounting is the handling of different currencies and making sure that you only add the same currency together.


 * Required skills / knowledge: C++, Reading other's code, debugging, having crazy ideas


 * Difficulty: Medium


 * Mentors:
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
 * Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org


 * Student:
 * Benjamin Ni

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: Medium


 * Mentors:
 * Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com


 * Student:
 * Varun Dhall

Reuse Mozilla's rolling update mechanism for LibreOffice
Mozilla is able to download the new installation on the background, patch itself, and restart. LibreOffice has its own mechanism for updates that does not allow this, unfortunately. This task is to re-use the code from Mozilla to provide the rolling update mechanism for LibreOffice too.

Alternative could be Sparkle / WinSparkle - according to the comments, Sparkle works better than the Firefox's update on OS X.

See also


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


 * Difficulty: Medium


 * Mentors:
 * Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com


 * Student:
 * Nathan Yee

Review of the sidebar & its functionality
Many things in the sidebar are not finished yet, and also some of the modeless dialogs might provide much more value if they were sidebars; eg. the Insert -> Cross-reference... feels like a functionality that would fit to the sidebar; and for sure there are more.


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


 * Difficulty: Medium


 * Mentors:
 * Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
 * Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
 * Yousuf Philips, IRC: jphilipz, mail: ypharis @ gmail . com


 * Student:
 * Rishabh Kumar

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 a large effort underway to retrofit a more modern layout approach to our existing code. See this overview and WidgetLayout, where we are migrating to the gtk builder file format as used by gtk3 and glade3.

The task is to help complete the remaining 20% of dialogs that need converting to the new format. Here's a tutorial


 * Required skills / knowledge: Some C++
 * Difficulty: Easy to medium
 * Mentor: Caolán McNamara
 * Students: Palenik Mihály, Szymon Kłos

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: https://cgit.freedesktop.org/libreoffice/core/tree/cui/source/options/personalization.cxx#n39


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Easy
 * Mentors: Jan Holesovsky, Tomaž Vajngerl
 * Student: Rachit Gupta

Connection to SharePoint and/or Microsoft OneDrive
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 OneDrive 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 OneDrive 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
 * Mentors: Cédric Bosdonnat, Miklós Vajna
 * Student: Mihai Varga

Calc / Impress tiled rendering support
For Android / LibreOffice on-line we need great tiled rendering support. So far we have API support for that for Writer, but nothing for calc / impress. We should implement, and test the same API for Calc (with an extension for switching tabs - but a single large 'page' (I guess)) - and the same for Impress - with some extension for 'notes' =)

We should update the tiledrendering test app to render these document types too. Extra brownie points provided for performance optimisation for CPU / basebmp rendering of the same.


 * Required skills / knowledge: C++
 * Difficulty: Hard
 * Mentors: Michael Meeks, Adam Fyne
 * Student: Andrzej Hunt

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: https://docs.libreoffice.org/editeng/html/classImpEditEngine.html#aa20bd6c40eb7afc8a734128ce2b4bd6f


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


 * Difficulty: Medium
 * Mentors: Fridrich Strba, Thorsten Behrens
 * Student: Matteo Campanelli

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: https://cgit.freedesktop.org/libreoffice/core/tree/svx/source/tbxctrls/colrctrl.cxx
 * Palette configuration page: https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/tpcolor.cxx


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Medium
 * Mentors: Jan Holesovsky, Tomaž Vajngerl
 * Student: Krisztián Pintér

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: https://cgit.freedesktop.org/libreoffice/core/tree/sfx2/source/doc/templatedlg.cxx
 * Previews of the pages: https://cgit.freedesktop.org/libreoffice/core/tree/sfx2/source/control/thumbnailview.cxx


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Medium
 * Mentors: Jan Holesovsky, Tomaž Vajngerl
 * Student: Efe Gürkan YALAMAN

Implement Adobe Pagemaker import filter
Pagemaker is still available but not actively marketed desktop publishing application. The task is to implement Adobe Pagemaker import filter for version 6 to 7 of the application. Basics of the format were already reverse engineered, additional efforts to reveal details will be required.

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:
 * Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
 * Valek Filippov, IRC: frob, frob_tea, mail: frob at gnomeorg

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
 * Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen @ canonical.com
 * Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com


 * Student:
 * Valentin Kettner

VLC integration
Currently we use the native platform's video libraries and codecs, these are frequently extremely lacking in support - whether it is lack of support for webm / ogv on Windows, or various other codecs elsewhere. This leads to a poor user experience, and user complaints: "why can't LibreOffice play my video". As such - it would be great to detect if libVLC (now LGPL, with all it's code goodness) is around on the system, and if so - integrate and play using it. We should do that by dynamically loading and hooking version / symbol information out of it, and provide a new cross-platform, pluggable avmedia/ implementation for the latest APIs.


 * Required skills / knowledge: Windows, C, C++, Reading other's code
 * Difficulty: Medium
 * Mentor: Michael Meeks
 * Student: Minh Ngo

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. 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: https://opengrok.libreoffice.org/xref/core/sw/inc/hintids.hxx
 * Character formatting dialog: https://opengrok.libreoffice.org/xref/core/sw/source/ui/chrdlg/chardlg.cxx
 * Most of the layout painting code: https://opengrok.libreoffice.org/xref/core/sw/source/core/layout/paintfrm.cxx


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Medium
 * Mentors: Cédric Bosdonnat, Miklos Vajna
 * Student: Tamás Zolnai

Support for Firebird Database in Base
Our current Base database backend is HSQLDB - but this causes severe performance problems primarily around the frequency of Java to C++ transitions. Anyone creating a Firebird backend would be a hero of the Base community and allow us to start writing fast, reliable regression tests for base, and to expand it's functionality with confidence.

There are lots of other database backends to re-use in doing this work, so it -should- be reasonably easy and extremely rewarding. Most databases have reasonably similar APIs, and this is mostly just a job of reducing minor impedance mis-matches between the two.

More information is and we need to use Firebird for this.


 * Required skills / knowledge: C++, a little SQL, Reading other's code.
 * Difficulty: Easy/Medium
 * Mentors: Muthu Subramanian, Lionel Elie Mamane, Michael Meeks
 * Student: Andrzej Hunt

Improved Android / Impress Remote Control
The Android Remote Control has a number of places it can be significantly improved. This project would focus on a number of these issues and potentials for extending and polishing the current capability:
 * accelerometer driven pointer support - this requires work on the C++ Impress code.
 * make protocol extensible - requires both C++ and Java work.
 * keep-alive ping - to detect and sever broken connections from the client
 * file/storage: this will all need UX input and advice I think.
 * it should be possible to store the currently open presentation on your device
 * it should also be possible to stream a slide-deck from the remote to the device if no slideshow is running.
 * add a larger thumbnail pane - to allow scrolling much larger thumbnails of slides with click to select - perhaps just a zoom in/out functionality in the existing thumbnail grid would do it.
 * The Tools,Options,Impress,General,"Enable remote" option should take effect immediately, without a re-start
 * The Slideshow, Impress Remote dialog should be enabled for all users and give live status on: is bluetooth enabled, are we connected to a remote, and separate bluetooth and WiFi remote displays, and add help. It should also detect and warn of the case where another LibreOffice instance or system process is bound to the bluetooth socket, thus making it impossible to connect.


 * Required skills / knowledge: C++ (you need to fix the impress core), Java, Android programming
 * Mentors: Michael Meeks
 * Student: Artur Dryomov

Impress Remote Control for iOS
We already have a great remote control app for Android to drive your slideshow over Bluetooth. It would be great to have a version for the iPhone, iPod Touch and iPad as well. The Android code is in the android/sdremote directory, and we would want to re-use the existing UI design you can see there and in Development/Impress/Remote. There is little possibility for code re-use as such. The Android remote control (of course) is written in Java and uses Android APIs, while the iOS remote control will be written in Objective-C and use the CocoaTouch API. Also, note that on iOS using Bluetooth will not be possible due to iOS not having suitable API for Bluetooth, so it will have to be Wi-Fi based. Thus the ideas of how the remote control works over TCP/IP will need to be reworked if necessary, and changes done also on the server side.

Full-time access to a reasomably modern Mac, running macOS 10.7 or 10.8 is required. Possibly one can manage compiling for the iOS simulator and using that for testing, but full-time access to an actual iOS device is preferred. Note that downloading code to an iOS device requires membership in the iOS Developer Program. Hackintosh or rooted device use is not permitted and will lead to failing the student.


 * Required skills / knowledge: Objective-C, iOS programming
 * Difficulty: Easy
 * Mentor: Tor Lillqvist
 * Student: Siqi Liu

Use Widget Layout for the Start Center
Currently, the Start Center (the start screen you get when you start LibreOffice) is only a static bitmap, with few buttons and links. It would be useful to present few recently used documents there (as thumbnails), and do more fancy stuff.

See this overview and WidgetLayout to get more information about the Widget Layout (this part is actually very similar to the above mentioned task). Additionally, code for rendering the thumbnails will have to be introduced, and maybe some code sharing with the new Template Manager will be needed too.

The code of the current Start Centre lives here: https://cgit.freedesktop.org/libreoffice/core/tree/framework/source/services/backingwindow.cxx

Ideal starter for this task is this Easy Hack:


 * Required skills / knowledge: C++, Reading other's code
 * Difficulty: Medium
 * Mentor: Jan Holesovsky
 * Student: Krisztian Pinter

Extend support for Document Management Systems
Since version 4.0 LibreOffice can now connect to CMIS (Content Management Systems) service to fetch online document storage. However we can add a lot more support to this feature. This project aims to connect LibreOffice to Google Drive protocol through libCMIS. Google recently transformed its Document API to Google Drive which now act as a cloud storage and document synchronization service. By adding wrapper of this protocol from CMIS API, users will be able to handle directly his Google Drive documents in LibreOffice. This ability includes choosing exported rendition types from Google Document types which are not downloadable. The second part of project aims to extend properties dialog and version dialog in order to enable users to interact with his documents entirely using the office suite.

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
 * Google Drive API: https://developers.google.com/drive/v2/reference, see also Calligra Implementation
 * 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


 * Mentors:
 * Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
 * Miklós Vajna, IRC: vmiklos, mail: vmiklos @ suse . cz


 * Student:
 * Cuong Cao Ngo

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, but preferrably via our new glade-based ui.

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

Note: on the UX list there is a discussion on splitting of the options in default and advanced. See this page http://lists.freedesktop.org/archives/libreoffice-ux-advise/2012-November/thread.html#1490 and there the mails with subject 'Need Developer Input about Options'

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

Difficulty: easy


 * Mentors:
 * Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com


 * Student:
 * Efe Gürkan Yalaman

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. Further information can be found in the related LibreOffice bug entry: bug 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

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

Difficulty: medium to hard


 * Mentors:
 * Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
 * Maxime de Roucy, IRC: mderoucy, mail: mderoucy @ linagora . com


 * Student:
 * Ivan Nicolae-Alexandru

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:


 * https://bugs.freedesktop.org/show_bug.cgi?id=60414
 * https://bugs.freedesktop.org/show_bug.cgi?id=61005
 * https://bugs.freedesktop.org/show_bug.cgi?id=61080
 * https://bugs.freedesktop.org/show_bug.cgi?id=62079
 * https://bugs.freedesktop.org/show_bug.cgi?id=62080
 * https://bugs.freedesktop.org/show_bug.cgi?id=62082
 * https://bugs.freedesktop.org/show_bug.cgi?id=60412

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


 * Mentors:
 * Jan Holesovsky, IRC: kendy, mail: kendy @ suse . cz


 * Student:
 * Prashant Pandey

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


 * Mentors:
 * Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com


 * Student:
 * Vishv Brahmbhatt

Calc 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


 * Mentors:
 * Kohei Yoshida, IRC: kohei, mail: kohei.yoshida AT gmail DOT com
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard AT googlemail DOT com


 * Student:
 * Daniel Bankston

Enhanced Impress svg export filter
The aim of this project is to improve the Impress svg export filter I started working on the last GSoC. The main goals for the GSoC time-frame are to add support for slide transitions and transformation effects and to carry out a new implementation of the text export feature such that we can provide support for text search engine and text animations. In such a way the user get a complete feature rich presentation in a single svg document that can be displayed in any enough modern browser.


 * Student:
 * Marco Cecchetti

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


 * Mentors:
 * Fridrich Strba, IRC: fridrich, mail: fridrich . strba @ bluewin . ch
 * Valek Filippov, IRC: frob, frob_tea, mail: frob @ gnome . org


 * Student:
 * Brennan Vincent

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


 * Mentors:
 * Tor Lillqvist, IRC: tml_, mail: tlillqvist @ suse . com


 * Student:
 * Iain Billett

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


 * Mentors:
 * Cédric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr


 * Student:
 * Rafael Dominguez

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


 * Mentors:
 * Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com


 * Student:
 * Gökcen Eraslan

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


 * Mentors:
 * Thorsten Behrens, IRC: thorsten, mail: tbehrens @ suse . com


 * Student:
 * Andrzej Hunt

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


 * Mentors:
 * Eike Rathke, IRC: erAck, mail: erack @ redhat . com
 * Michael Meeks, IRC: mmeeks, mail:


 * Student:
 * Matúš Kukan

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


 * Mentors:
 * Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
 * Markus Mohrhard, IRC: moggi, mail: markus.mohrhard AT googlemail DOT com


 * Student:
 * Artur Dorda

Convert the LibreOffice web help (wikihelp) to platform specific help files
Currently, the source of the help are so called .xhp files that are stored in the libreoffice git repository. The offline help (the one you can see in the application when you have installed the help packs), as well as the online help (wikihelp - http://help.libreoffice.org) is then generated from them.

To ease the life of both the programmers and document writers too, we would like to get rid of the .xhp files, and of the own LibreOffice help system. We want to make the online help (that uses the mediawiki syntax) the source of the help, and generate the offline help from that. Ideally, we should generate platform native help files, which means that we need 3 backends - for Windows, for Linux and for MacOSX. Also, all these possibilities have to be checked if they provide all the features currently available in the own LibreOffice help system, and find possibilities for those missing.

Required skills / knowledge: Python or Perl

Difficulty: easy


 * Mentors:
 * Jan Holesovsky, IRC: kendy, mail: kendy @ suse . cz


 * Student:
 * Timo

Enhanced svg export filter
LibreOffice's svg export is rather limited, it would be nice to create svgs containing multiple slides, can be navigated etc.; also, having at least minimal animation support for Impress documents would be desirable, comparable to what the Flash export filter provided for the 1.x versions. Interesting project to re-use is JessyInk:http://code.google.com/p/jessyink/downloads/detail?name=JessyInk_1_5_5_showcase.svg

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

Difficulty: medium


 * Mentors:
 * Fridrich Strba, IRC: Fridrich, mail: fridrich . strba @ bluewin . ch


 * Student:
 * Marco Cecchetti

Multi-line edit bar in Calc
Currently it's very hard to edit cell content in Calc when the content is so large that it won't fit within the visible area. One way to resolve this is to make the formula input bar (the elongated input box at the top where you can edit cell content) resizable and scrollable. Let's look at how Excel 2007 handles this. We need to do something similar (or better).

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

Difficulty: medium


 * Mentors:
 * Kohei Yoshida, IRC: kohei, mail: kyoshida @ novell . com


 * Student:
 * Anurag Jain

Improve RTF Import (RTF Tokenizer)
For the ooxml Word import filter, a new filter framework is developed that has better import quality as the old separate filters, and also shares quite some code. Having the RTF import use that framework would be hugely useful; both binary doc and rtf are very similar in structure, and could have tokenizers plugged into the filter framework (and thus being handled by the same high-level filter code). The doc tokenizer is already worked on, so a RTF tokenizer would be a an awesome feature.

Code pointers:
 * http://cgit.freedesktop.org/libreoffice/filters/tree/writerfilter/source/rtftok for the started RTF tokenizer
 * http://cgit.freedesktop.org/libreoffice/filters/tree/writerfilter/source/ooxml for an example of over-complicated OOXML tokenizer

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

Difficulty: medium


 * Mentors:
 * Cedric Bosdonnat, IRC: cbosdonnat, mail: cedric . bosdonnat . ooo @ free . fr
 * Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern . michaelsen @ canonical . com


 * Student:
 * Miklos Vajna

Create a Visio import filter for Draw
LibreOffice currently lacks support for a Visio import filter. This proposal is about writing one, using the ODF format as the transport format to be loaded by the LibreOffice application. Although a full blown filter seems to be unrealistic to be written within the short timeframe, large parts of Visio documents should be able to be filtered correctly.

Required skills / knowledge C++, Reading other's code, familiarity with Visio and a fearless attitude towards poking into binary files.

Difficulty: medium

Potential mentors:
 * Fridrich Strba, IRC: Fridrich, mail: fridrich . strba @ bluewin . ch


 * Student:
 * Eilidh McAdam

Performance Improvement
There are several known performance bottlenecks inside LibreOffice, and clearly more can be found with improved profiling. The exciting part of this task is clearly, finding and understanding sillies in the code - mis-uses of otherwise sensible APIs, problematic code structures and so on; and then with the minimum of code tweaking make them fly. As part of this, a small improvement to KCachegrind's visualisation will also be required (basic C++). We will also look at reducing memory use as an extensions. Not really a single task, but a collection of incremental wins over some weeks.

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

Difficulty: medium


 * Mentors:
 * Michael Meeks, IRC: mmeeks, mail: mmeeks @ novell . com


 * Student:
 * Matúš Kukan

Wizards: Java to Python conversion
This project aims to convert the Java wizard menus into Python. The reason is, basically, because the current wizards cause some nasty problems on machines with mis-configured, or not present, Java and of course it presents a serious performance challenge


 * Student:
 * Xisco Faulí