Development/GSoC/Ideas: Difference between revisions
(→Base: add new idea) |
|||
| Line 690: | Line 690: | ||
== Tooling == | == Tooling == | ||
=== Integrate .ui dialogs with translation tooling/string search webservice to help translators === | === Integrate .ui dialogs with translation tooling/string search webservice to help translators === | ||
Revision as of 15:58, 21 January 2016
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
This page lists the project ideas for Google Summer of Code, see the general info about LibreOffice and GSoC. Feel free to pick any of the tasks listed in the Programming Tasks section of the Easy Hacks page, but in that case you need to ask for mentors on the development mailing list if none is defined. Also the page the Genial Ideas page holds interesting ideas for a GSoC project, but – alike the EasyHacks page – you need to find a mentor for your GSoC project by asking on the LibreOffice developer list.
All tasks on this page already indicate mentors for the task. New tasks on this page should be added only by those with the experience and time to invest in mentoring new developers.
Note that the LibreOffice project selects GSOC projects that are well researched and show a good understanding of the scope of the problem. It is also possible to create a project proposal not based on the ideas given below, if the application of the student shows good understanding of the problem. In fact, if you apply with one of the prepared ideas below, we expect you to show you did research beyond the abstracts given below even more.
When doing that please use this template:
=== Title of the task === Some detailled description of the things to accomplish. Don't hesitate to provide details if you have some like code pointers, links to specifications, etc. ;Required skills / knowledge: C++, Reading other's code, and any other useful skill required go here. ;Difficulty: Range among easy, medium, hard ;Potential mentors :''Joe Devel'', IRC: jdevel, mail: joe@devel.org
Please move successfully completed projects to Development/GSoC/Successfully Implemented Ideas.
General
Enable running LibreOffice without user configuration
When LibreOffice starts it tries to read persistent user configuration settings, either from a default location, or from a location specified with the UserInstallation bootstrap parameter. LibreOffice also writes user configuration and cached information collected from the installation's shared configuration there, even if the user has not done any intentional user-visible modifications of settings.
For some use cases, it would be useful to be able to run LibreOffice (either when running it as a separate program, or when using LibreOffice code through LibreOfficeKit) without any user configuration. For instance, when LibreOffice (or LibreOfficeKit) is used to implement some service accessed over the net, without there being any actual "user" that the instance would be running for, and no need to keep any persistent settings. Currently in such situations a dummy empty UserInstallation directory needs to be created before starting LibreOffice, and correspondingly the populated directory removed afterwards.
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
Tor Lillqvist, IRC: tml_, mail: tml @ collabora.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 was one included by half of sw and includes a huge loads of other headers. It was successfully refactored by Valentin Kettner in GSOC 2014. Apart from undesirable tight coupling, it also caused a major and unneeded increase in incremental (re-)build times. A successful proposal would need to have identified another god object beyond SwDoc and describe how and why LibreOffice would benefit from refactoring it. Note the availability of mentors by area of code below.
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
writer: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
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
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
- Potential mentors
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
Reuse Mozilla's rolling update mechanism for LibreOffice tdf#68274
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 tdf#74934
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Porting and platform specific topics
LibreOffice Online
There is a prototype for LibreOffice online that has been around for some years. This task will include changes in the LibreOfficeKit, and in the web/JavaScript part too.
- Required skills / knowledge
- C++, JavaScript optional.
- Difficulty
- Medium
- Potential mentors
- Tor Lillqvist, IRC: tml_ mail: tml @ collabora.com
- Jan Holesovsky, IRC: kendy mail: kendy @ collabora.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
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
User Interface
Finish the Gtk+3 port
LibreOffice has been largely ported to Gtk+3, but that work is still not finished - some of the widgets are not ported yet, some have redrawing problems, etc. This work is supposed to finish this work, and provide shiny usable Gtk+3 version.
Code pointers: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3 , mostly http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Caolan McNamara', IRC: caolanm, mail: caolanm @ redhat . com
Add Gtk3 gesture support to impress slideshows
Gtk3 has a gesture api https://developer.gnome.org/gtk3/stable/Gestures.html, the project is to expose that gtk3 support via vcl and add swipe, scroll, pinch etc support to LibreOffice, especially focusing on slideshow mode of impress, e.g. these things https://support.apple.com/kb/PH3501?locale=en_US&viewlocale=en_US
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Caolan McNamara', IRC: caolanm, mail: caolanm @ redhat . com
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. tdf#86703 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. tdf#86699 Part of this might be also improving the local file access, like providing document preview in the system file dialogs etc. tdf#87748
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Cedric Bosdonnat, IRC: cbosdonnat, mail: cedric @ bosdonnat . fr
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
- Potential 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
Integration of the templates repository
More work around templates repository / online templates / integration into the start screen / ... tdf#85420 https://bug-attachments.documentfoundation.org/attachment.cgi?id=108377
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Rework of the Tools -> Customization... dialog
The current Customization... dialog could be much better organized, and could be have better. An extensive description is in http://user-prompt.com/how-to-make-libreoffice-customization-usable/, tdf#88896
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
Revamp the gallery tool
The LibreOffice Gallery tool would need to be enhanced to support features like sorting using tags, search, connection to online galleries like OpenClipart. This project aims at changing the gallery tool in this way. A previous GSoC project ended up with code for fetching and displaying pictures from OpenClipart. This code would need to be used as a basis for this project. As a later target, this new Gallery would be the base for an objects libraries dialog (eg network, UML...). Even though this would probably not fit in the time frame of a GSoC, this target may influence UI and code design choices.
The display of the galleries should be done as a side-bar, re-using the widget from Impress that has headings 'Master Pages' / 'Layouts' / 'Slide Design' etc. - but with each of these being a separate category of clipart - and presenting a selectable sub-set of these. This would make much better use of screen real-estate that the current horizontal gallery.
Here are some code pointers to get started in the task:
- Previous GSoC patch: http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/online_gallery.diff?h=libreoffice-3-4
- Extension that integrates OpenClipart library in the task panel: http://extensions.libreoffice.org/extension-center/openclipart-org-integration in Writer
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Tomaž Vajngerl, IRC: quikee, mail: tomaz.vajngerl @ collabora . com
Application Themes
LibreOffice currently uses the OS's theme to color its menubar, toolbars, sidebar, statusbar, etc. but it would be useful for the user to be able to change this default feature. The Firefox Themes integration done in LO 4.0 by Jan Holesovsky and improved in LO 4.4 by GSoC 2014's Rachit Gupta were a step in the right direction but it wasnt a complete theme (e.g. theme background doesnt appear in toggled buttons, theme didnt change the color of the statusbar or scrollbars, theme didnt change the document color scheme, theme didnt change icon set, etc).
- Proposal Info
- https://docs.google.com/document/d/1J_aogLuQThqhvT0R2em27Vpew-SLAQgpH5TbNTgXPZM/edit?usp=sharing
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
KDE4: use Qt4 widgets and abstraction layer for painting and event filtering
LibreOffices KDE4 VCL backend is just a shim layer around the X11 / Xlib VCL backend and next to TDE the only user. It provides a native file picker but otherwise just tryes to emulate the KDE look using low level paint methods. This results in multipe problems:
- No platform abstraction; directly uses Xlib for drawing and event processing
- No way to port to Qt5
- Qt5 internally uses XCB, but the main problem is
- QPixmap doesn't export the internal X11Pixmap anymore
- No real way to do native X11 drawing - you want to use QPainter
- You don't want to port an already dated X11 backend to XCB
- The Cairo based Svp / headless VCL won't integrate well with Qt5, better use native QPainter
- Cairo has a Qt / QImage based backend, but this can just use Qt4 or Qt5, as symbols clash and the backends are static and no loadable plugins
- Would introduce a 2nd render path on Linux; you could probably start an implementing alternative Svp using QPainter?
- No more native event filtering
- No Wayland support
- Qt5 internally uses XCB, but the main problem is
- No modal native dialogs
currently doesn't use QWidgets, so there is no way to implement the modal handling for the file picker. Gtk+ wraps the LO widgets in GtkWidgets, so modal native dialogs work. - No native widgets
The KDE4 VCL plugin just uses some painting methods to render stuff, but there is some stuff we can't handle correctyl this way, like Oxygen menus. The Gtk+ plugin actually uses GtkWidgets to draw themself, giving a more native look and feel. Also it implements the SalMenu. - Slow painting,
as all drawing operations are performed on a single image and copied using Xlib function. This image is always destroyed and there is basically no caching. Gtk+ keeps a caching widget per type around. This also isn't portable to Qt5 - Use KIO internally
Currently LO sets "X-KDE-Protocols=file,http,ftp,webdav". Even smb was included for some time. But actually this depends on the native load / save dialog settings, and even the VCL backend, because the KDE4 file picker / VCL backend doesn't support neither smb nor webdav without KIO.
- TODOs
- Replace all native X11 handling with Qt4 abstractions
- Replace X11 drawing with QPainter stuff: http://doc.qt.io/qt-4.8/qpainter.html
- Implement Svp based on the Qt4 backend
- Have a look how Svp + Gtk3 handles drawing
- Handle X11 / XCB event using the event loop abstraction: http://doc.qt.io/qt-4.8/eventsandfilters.html
- Use QWidgets for SalFrames to fix modal dialogs and improve paonting / integration
- Documentation
- see the next item KDE5: port KDE4 plugin to KF5
- Code pointers
- KDE4: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/kde4
- Gtk3: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/unx/gtk3
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- High
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow @ fbihome . de
KDE5: port KDE4 plugin to KF5
This work depends on the previous item KDE4: use Qt4 widgets and abstraction layer for painting and event filtering. After talking to KF5 developers, especially Martin Gräßlin, we concluded there wouldn't be much of a point to port KDE4 while it's based on X11 native Xlib calls.
Jmux comment: to get a better impression of the KF5 codebase and library layout I did an initial port, but this won't work, as it can't do any painting and the integration in the X11 event queue is also broken / commented out. If you really want to start this during a GSoC I would recommend you already know your way around KF5 + Qt5, or expect a steep learning curve.
- TODO
- Port Qt4 event filtering to Qt5:
- See the xcb filtering example in http://doc.qt.io/qt-5/qabstractnativeeventfilter.html
- KFilePicker to QFileDialog
- Initially use: http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/index.html
- Extend QFileDialog to have a free are for LO extended options
- Documentation
- http://blog.martin-graesslin.com/blog/2013/10/porting-a-kcontrol-module-to-kf5/
- https://quickgit.kde.org/?p=kdelibs.git&a=blob&h=bbc1c41b06b780301f0b890dcb79831b900dde86&f=KDE5PORTING.html&o=plain
- https://community.kde.org/Frameworks/Porting_Notes
- https://conf.kde.org/system/attachments/6/original/we_are_the_one_percent.pdf
- https://community.kde.org/KWin/Qt5
- Code pointers
- http://cgit.freedesktop.org/libreoffice/core/log/?h=private/jmux/kde5 (compiles but doesn't run)
- Required skills / knowledge
- C++, KF5 + Qt5, Reading other's code
- Difficulty
- Medium
- Potential mentors
- Jan-Marek Glogowski, IRC: jmux, mail: glogow @ fbihome . de
Base
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
- Potential mentors
- Lionel Elie Mamane, IRC: schoinobates, mail: lionel AT mamane DOT lu
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
Basic
Draw
Impress
Attach animations to styles
Currently, Impress styles control most of the visual shape appearance, but not the slideshow animation effect. Which is a pity, as the styles concept is pretty powerful inside LibreOffice, and provides a nice way to change animation settings and type for a great number of objects simultaneously. For a slightly different view onto the same problem, see this bug report, and this one from the LibreOffice side.
Original patch from GSoC 2010: http://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/sd_effects_styles.diff?h=master-backup
- Required skills / knowledge
- C++, Reading other's code
- Difficulty
- Hard
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
- Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
Rework Impress slideshow to use DrawingLayer primitives
The Impress slideshow, while being designed to only interact with Impress via interfaces, had to resort to an ugly hack to be able to render all Impress content. That was ok back in the day, but is becoming a liability these days. Nowadays, what one want to use is the DrawingLayer Primitives (https://wiki.openoffice.org/wiki/DrawingPrimitives), which means porting over slideshow/source/engine/shapes/* to use this kind of abstraction, instead of the StarView Metafile previously in use.
- Required skills / knowledge
- C++, Reading other's code.
- Difficulty
- Difficult
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
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 ▸ . 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: tdf#37932. 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
- Muthu Subramanian, IRC: muthusuba, mail: muthu . subramanian . karunanidhi @ ericsson . com
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
Mix and Merge Impress presentations
For the professional slide jockey, mixing a new presentation out of existing slide decks is a common task, that unfortunately Impress does not support very well. This task is about providing, possibly stand-alone, functionality to:
- display lots of presentation files conveniently, possibly with tagging/searching functionality
- out of existing slides, quickly create a new presentation
- provide functionality to conveniently exchange / homogenize slide layouts and/or master pages, such that new presentation has consistent look
- as a bonus task, be able to create virtual slide decks, by referencing other files, and have the resulting presentation automatically update, once the referenced slides are
- can be built-in to Impress, stand-alone (but then portable across all our platforms), or web-based.
Code pointers:
- this needs some ODF processing when being stand-alone or web-based, e.g. via https://github.com/lpod/lpod-python
- or you make it built-in, then the copying-slides-around functionality is here: http://opengrok.libreoffice.org/search?refs=InsertBookmarkAsPage
- Required skills / knowledge
- ODF, UX, possibly c++, possibly Python, possibly web frameworks
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . 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: http://cgit.freedesktop.org/libreoffice/core/tree/slideshow/source/engine/animationnodes
- Required skills / knowledge
- C++, basic game/animation skills useful, reading other people's code
- Potential mentors
- Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org
Calc
Chart sheets in Calc
Currently Calc only supports table sheets ut for interoperability we should at least support chart sheets. For this task one needs to abstract the sheet handling in calc and adapt all places that unconditionally assume that every sheet is a table sheet.
Here are a few code pointers to this task:
- The current implementation for a sheet is ScTable: http://opengrok.libreoffice.org/xref/core/sc/inc/table.hxx
- All ScTable instances are held by maTabs in ScDocument which represents a full calc document: http://opengrok.libreoffice.org/xref/core/sc/inc/document.hxx
- The corresponding shell is ScTabView: http://opengrok.libreoffice.org/xref/core/sc/source/ui/inc/tabview.hxx and ScTabViewShell: http://opengrok.libreoffice.org/xref/core/sc/source/ui/inc/tabvwsh.hxx
- Required skills / knowledge
- C++, Reading other's code, debugging
- Difficulty
- Medium to hard
- Potential mentors
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
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
- Potential mentors
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
- Katarina Behrens, IRC: bubli, mail: bubli @ bubli . org
Writer
Improve VML import
The import of VML in our DOCX implementation is limited, and for example is unable to import rotation of ellipses, or shading of objects. Even though VML is not recommended by the OOXML specification as the format to use, MS Word 2007 uses that primarily, and as a consequence, there are many .docx files around using VML.
Here are some code pointers to get started in the task:
- oox/source/vml/vml* - the import code for VML; eg. ellipses are imported so that ShapeContextBase::createShapeContext() in oox/source/vml/vmlshapecontext.cxx gets the shape context, and creates an instance of EllipseShape
For sure there are missing rotations of shapes, or their shading. There will be a test document provided which is supposed to be imported perfectly after the end of the GSoC.
Required skills / knowledge C++, reading other's code
Difficulty: medium
Potential mentors:
- Miklós Vajna, IRC: vmiklos, mail: vmiklos @ collabora . co . uk
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
Document Themes
Document themes are a simple way to allow users to quickly & consistently restyle the entire document. There is an implementation of this in MSO, and also Calligra plans to something in this regard, so this task actually consists of 2 parts:
- Implementing user interface for the feature
- Implement the ODF support for that
More ideas about the feature you can get by reading http://blogs.msdn.com/b/jensenh/archive/2006/02/22/537054.aspx and https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes .
The import code for DOCX is here: http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml, you might need to change also http://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/dmapper
For XLSX and PPTX, it resides in http://cgit.freedesktop.org/libreoffice/core/tree/oox/source
- Required skills / knowledge
- C++, Reading other's code, reading specifications :-)
- Difficulty
- Hard
- Potential mentors
- Jan Holesovsky, IRC: kendy, mail: kendy @ collabora . com
- Miklos Vajna, IRC: vmiklos, mail: vmiklos @ collabora . com
Filters
Create a standalone WMF/EMF/EMF+ import filter
WMF is a vector graphic format by Microsoft, which has been further extended as EMF (and later EMF+).
The task is to write an independent (from LibreOffice) import filter for these formats. Specifications of all three formats are available.
The library will be based on librevenge.
Required skills / knowledge C++, Reading other's code
Difficulty: medium to hard
Potential mentors:
- Fridrich Strba, IRC: fridrich, mail: fridrich.strba
bluewin.ch
- Valek Filippov, IRC: frob, frob_tea, mail: frob
gnome.org
- David Tardon, IRC: dtardon, mail: dtardon
redhat.com
Implement legacy StarOffice binary formats import filter
StarOffice 1.x - 5.x had a variety of binary formats which used to be supported by the notorious binfilter, which was removed in LO 4.0 since it was unmaintainable.
It should be possible to implement a much simpler import filter for the legacy StarOffice binary formats based on the librevenge import filter API. In the absence of file format documentation the source code for the binfilter can be used as a reference, but likely some reverse engineering and experimentation will also be required.
Required skills / knowledge C++, Reading other's C++ code (to reuse libwpd importer code and extract file format details from binfilter),
Difficulty: medium
Potential mentors:
- Fridrich Strba, IRC: Fridrich, mail: fridrich.strba
bluewin.ch
- David Tardon, IRC: dtardon, mail: dtardon
redhat.com
Implement Apple Numbers import filter
The goal is to implement a filter for versions 2 and 3 of the Apple Numbers format (iWorks '09 and '13). The version 2 format is XML based: the output is saved as single zip file, containing index.xml, which is XML specification of the document, and other data files (images used in the document, generated preview and thumbnail, etc.) There is no documentation for the format (known to me), but the XML is reasonably readable. The version 3 format is binary and is currently being reverse engineered.
The new filter will be added to libetonyek, which is an existing library for parsing Apple Keynote format, rather than being in a separate library, as there is a large overlap between the two format's capabilities, which makes it possible to reuse a lot of basic stuff. This also makes me confident that we can implement parsers for both file format versions.
Required skills / knowledge:
- C++
- Reading other's C++ code (to reuse libetonyek importer code)
- Ability to read XML and some kind of schema
- Ability to understand hexadecimal dump of data
- Ability to read (better yet, write) Python (for OLEToy)
- Readiness to become famous
Difficulty: hard
Potential mentors:
- David Tardon, IRC: dtardon, mail: dtardon
redhat.com
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: dtardon
redhat.com
Implement Xara X import filter
Xara X (later renamed to Xara Xtreme) was a vector drawing applicaton for MS Windows. There also was an open source version for Linux and Mac OS X.
The task is to implement an import filter for its native file format (.xar). A specification of the format is available, so this should be relatively easy task (no reverse-engineering 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 write code to a specification
- Readiness to become famous
Difficulty: easy to medium
Potential mentors:
- Fridrich Strba, IRC: fridrich, mail: fridrich.strba
bluewin.ch
- Valek Filippov, IRC: frob, frob_tea, mail: frob
gnome.org
- David Tardon, IRC: dtardon, mail: dtardon
redhat.com
Implement EPUB export filter
EPUB is a widely-used open format for e-books. There are several extensions for OpenOffice.org (which presumably still work in recent LibreOffice) that can export it, but they appear to be mostly orphaned, with no update for years. Also, the output quality varies widely.
The goal of this task is to write an export filter for EPUB using the libepubgen library. The main part of the task will be conversion of text document model from UNO to librevenge API, but improvements to libepubgen are likely to be needed as well. The UNO->librevenge conversion will be generic, so it will be possible to reuse it for other export formats (e.g., to AbiWord format using librvngabw).
Required skills / knowledge:
- C++
- at least basic knowledge of EPUB / HTML / CSS
- Readiness to become famous
Difficulty: medium
Potential mentors:
- David Tardon, IRC: dtardon, mail: dtardon
redhat.com
- Michael Stahl, IRC: mst_, mail: mstahl
redhat.com
UNO
UNO is the LibreOffice component model, cross-language and intra- as well as inter-process. It is somewhat similar to Corba and COM. It is used to extend LibreOffice via document-related scripts and more general extension packages, as well as to use LibreOffice functionality remotely from another process.
Haskell UNO Language Binding
UNO's cross-language abilities are implemented by bridging between various language-specific environments and a binary runtime representation (with a C API). Next to C++, Java, and 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:
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
Rust 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 Rust.
One aspect is to use Rust FFI to interface with the binary UNO C API. Another is to design the Rust representations of the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons), so that this language binding can not only be used to interact with existing LibreOffice services written in other languages, but also to create new services in Rust. A third aspect could be to create a pure Rust implementation of the UNO remote bridge protocol.
Some documentation pointers are:
Some code pointers are:
bridges/source/jni_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: Rust, interfacing to low-level C/C++, working against formal specifications
Difficulty: medium to hard
Potential mentors:
- Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
- Michael Stahl, IRC: mst[_]*, mail: mstahl AT redhat DOT com
Tooling
Integrate .ui dialogs with translation tooling/string search webservice to help translators
Translators often have a hard time determining the context of a string to translate. It would be great if translators would be able to search for a string and have it presented in the context of the UI, a picture of a dialog for example.
Required skills / knowledge python (when integrating into pootle), java (when integrating into opengrok) or php or other suitable framework for the user-facing part, reading c++ code to identify where strings come from (not all strings are in dialogs) and GTK/glade ui definitions as the basis for the rendered dialog, scripting/makefile stuff to automate updating of the data
Difficulty: easy (when only limiting yourself to the glade dialogs) to medium (depending on the level of integration with the current tools: pootle as the platform where translation happens or opengrok where the source code is indexed)
Potential mentors:
- Christian Lohmaier, IRC: cloph, mail: cloph@documentfoundation.org