Created page with "For the following ideas, you need to find a mentor. If you are interested, send a mail to our dev list. === General === === Analyse and optimize SfxItemSet, make it use a STL..."
New page
For the following ideas, you need to find a mentor. If you are interested, send a mail to our dev list.
=== General ===
=== Analyse and optimize SfxItemSet, make it use a STL container internally ===
[https://docs.libreoffice.org/svl/html/classSfxItemSet.html SfxItemSet] is fundamental data structure heavily used while reading documents. It is also a very ancient, nonobvious container implementation. This task would be to analyse the use of SfxItemSet in default operations, for example:
* How many slots does an average ItemSet have?
* How much of an average ItemSet is usually filled?
* How many read/writes does an ItemSet perform over its lifetime?
* Could the SfxItemSet possibly gain from using Copy-On-Write?
* ...
And then, depending on the results of this analysis, make the implementation a wrapper around an suitable STL container.
;Required skills / knowledge: C++, callgrind, debugging
;Difficulty: Hard
;Potential mentors
<!-- :''Bjoern Michaelsen'', IRC: Sweetshark, mail: bjoern.michaelsen @ canonical.com -->
=== 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
==== Packaging and Window Management fixes for LibreOffice on Android ====
We currently have a LibreOffice desktop app for Android (see [https://cgit.freedesktop.org/libreoffice/core/tree/README.cross#n309 build instructions]), however it has a couple of major problems. First it is not going to fit inside the 50Mb app-store limit, and retain it's wealth of functionality. So we need to package and distribute it more cleverly - this is a matter of splitting the .apk into two downloads, one smaller wrapper, and one containing the bulk of the native code see [http://android-developers.blogspot.co.uk/2012/03/android-apps-break-50mb-barrier.html details]. Secondly - we need to implement a 'window manager' to handle the problems of popup windows, multiple documents and more. This latter task involves exposing the multiple (non-popup) windows that LibreOffice creates through a different interface, and building a sidebar to switch between these bitmaps similar to that seen [https://blog.mozilla.org/blog/2012/08/28/firefox-for-android-gets-speedy-and-powerful-upgrade-for-tablets/ here] for fennec.
Some code pointers for the latter task are from: [https://cgit.freedesktop.org/libreoffice/core/tree/android/experimental/desktop/src/org/libreoffice/experimental/desktop/Desktop.java#n47 this module], currently renderVCL renders a whole set of windows to a single Java Bitmap (very lamely), which we display. Instead we need to expose a list of windows which can be rendered to bitmaps. The callbackDamaged needs to notify which window was damaged, and the work needs doing in the BitmapView::onDraw or there abouts. The relevant C++ is in [https://cgit.freedesktop.org/libreoffice/core/tree/vcl/android/androidinst.cxx vcl's androidinst.cxx] and should be reasonably easy to follow - see Java_org_libreoffice_experimental_desktop_Desktop_renderVCL eg.
'''Required skills / knowledge'''
C++, Java
'''Difficulty:''' Medium
'''Potential mentors:'''
''Michael Meeks'', IRC: mmeeks mail: michael . meeks @ 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 3 parts:
* Interoperability with MS Office
* 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: https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/ooxml, you might need to change also https://cgit.freedesktop.org/libreoffice/core/tree/writerfilter/source/dmapper
For XLSX and PPTX, it resides in https://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
==== 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:'''
<!-- fallback at most: * ''Bjoern Michaelsen'', IRC: Sweetshark (very timeconstrained unfortunately), mail: bjoern.michaelsen @ canonical.com -->
* ''Matúš Kukan'', IRC: matus, mail matus DOT kukan AT gmail DOT com
==== Improving the updater ====
The [[Updater]] is crucial to getting Windows (and OS X) users onto current LibreOffice versions. Unfortunately, it is rather clumsy to use currently, the worst thing being that trying to download an update opens the default browser where the user has to click another download button. There are other failings, too, e.g., that users are not presented with a short list of what to expect after the update to motivate them. Finally, each update requires going through the entire installer again.
The proposal would be to alert users whenever an update is ready, and if they then click the alert, inform them about the three to five most substantial changes between versions. If the user clicks the Update button, download the update inside the LibreOffice window. When that is done, remind the user to save their work, so LibreOffice can be closed and updated, then update it in the most silent manner possible. Finally, LibreOffice should be restarted.
Bonus points for letting only administrative users download updates, and telling restricted users that they need to have administrative access to update.
'''Required skills / knowledge'''
Building LibreOffice on Windows, C++, Microsoft Installer
'''Difficulty:'''
hard
'''Potential mentors:'''
==== Connecting to iCloud ====
It would be nice if LibreOffice on the Mac could load / save files in iCloud. Most likely implementing this would also as a side-effect make it easier to interface to the new NSDocument stuff in general, too, i.e. automatic versioning etc, and make LibreOffice's document model, as visible to the user, be more in line with current Mac conventions.
Relevant documentation is included with Xcode; look for NSDocument docs and the iCloud Design Guide for starters. (But eligible students should already know what to look for, more or less;)
Possibly a new UCP ("Universal Content Provider") in LibreOffice would be needed. For an example of a recently written, fresh, UCP, see ucb/source/ucp/cmis. Unfortunately how UCPs work and interact with the other layers of LibreOffice is somewhat weirdly engineered. But for iCloud, we definitely do not want to force the user to use the silly "own" file picker, that would be very foreign to users.
Full-time access to a reasomably modern Mac, running a current OS is required. Hackintosh use is frowned upon. Membership in the Mac Developer Program is probably necessary in order to be able to actually test iCloud-using code.
And actually this task is perhaps not so useful any longer as it was some years ago, as the normal file dialogs now also show iCloud.
;Required skills / knowledge: C++, Objective-C, OS X API, Reading other's code. Experience writing non-trivial NSDocument-based OS X applications required. Actually we are surprised if any student shows up with the required knowledge...
;Difficulty: Hard
;Potential mentors
=== Basic ===
==== Dockable Basic navigator & Dockable Dialog property editor ====
* Dockable basic navigator needs some context menu support, e.g. to be able to add/delete modules/dialogs at least
===== General Docking behaviour =====
* Allow dockable entries to be docked anywhere ( currently what can be docked where is fixed )
* Allow not only an item to move to any docking area but allow arbitrary numbers of windows to be docked in an area,
* Even when say a single instance of the basic navigator window is shared between the dialog and module view we should handle
that they could be docked in different positions etc when switching between dialog and module tabs.
==== Dialog Editor improvements - Make dialog editor less weird ====
* Move dialog in design mode and the containees should move too.
* Better interaction with controls in the editor ( e.g. allow a label field to be edited directly in design mode )
* We have some hidden container controls from VBA interoperability work ( Frame, MultiPage ) Enable container controls
availability in Dialog object Toolbox ( even just the a box to place the container control would be better than nothing
* Provide scrolling in newly enabled Frame control
code pointers
[http://opengrok.libreoffice.org/xref/core/basctl/source/dlged/ Dialog Editor]
[http://opengrok.libreoffice.org/s?refs=ModulWindowLayout&project=core Module Window Layout]
[http://opengrok.libreoffice.org/search?q=&project=core&defs=DialogWindowLayout&refs=&path=&hist= Dialog Window Layout]
'''Required skills / knowledge'''
C++, Reading other people's code
'''Difficulty:'''
medium
'''Potential mentors:'''
* Mentors needed
=== Impress ===
==== Add Impress remote capabilities for simple ad-hoc fingerpainting ad-hoc sketches ====
Likely better suited to GSOC -- adding it here as we collect budget extensions. The idea is basically to allow to do simple ad-hoc sketches on a tablet with the impress remote, e.g. to answer an audience question on the spot. Allowing the tablet to use the projector as a modern chalkboard.
==== Make master pages copyable ====
Currently, when in master page edit mode, the slide sorter has cut/copy/paste disabled. The task would be to add this missing functionality, and correctly handle masterpage-attached styles.
Code pointers:
* [http://opengrok.libreoffice.org/search?refs=InsertBookmarkAsPage InsertBookmarkAsPage()] is a good starting point.
'''Required skills / knowledge'''
C++, Reading other's code.
'''Difficulty:'''
easy
'''Potential mentors:'''
* ''Maxime de Roucy'', IRC: mderoucy, mail: mderoucy @ linagora . 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 [https://cgit.freedesktop.org/libreoffice/core/tree/offapi/com/sun/star/xml/sax] 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 {{tdf|62774|this bug}} 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: {{nospam|sumuthu|collabora|com}}
* ''Michael Meeks'', IRC: mmeeks, mail: {{nospam|mmeeks|collabora|com}}
=== Calc ===
==== Make Calc/Base/Chart handle small set of geographic data ====
Allow Calc/Base/Chart to handle regional subsets of geographic data, e.g. import/edit/draw a small region of OpenStreetMap data.
see also: https://blog.documentfoundation.org/blog/2016/09/19/prototypefund-an-opportunity-for-german-freelance-developers/
=== Writer ===
==== "Styles and Formatting" cleanup ====
The "Style and Formatting" toolbox is a bit overcrowded by default and comes with styles that will most likely never used. This task consists in cleaning up this dialog in several steps:
* Hide automatically added styles by default, and show them when the styles are actually used. Such styles are the Index level styles and similar ones that aren't used unless an index is inserted in the document.
* Move the hard-coded styles definitions to a default template
* Create and integrate nice default styles
* Change it so that it fits the default layout of writer, and it is not necessary to have it as a separate dialog; or make the popping up of the dialog less annoying [needs input from the UX advise]
That task description is pretty big on purpose, but I may work on it too: so that would lower the student's work.
Some code pointers:
* Popup menu handler of the tree list box in the dialog: http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2177
* Popup menu creation: http://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2236
* Writer default styles hard-coded attributes: http://opengrok.libreoffice.org/xref/core/sw/source/core/doc/poolfmt.cxx#1079
'''Required skills / knowledge'''
C++, Reading other's code
'''Difficulty:'''
medium
'''Potential mentors:'''
* Mentor needed
==== ODF Formulas in Writer ====
Did you know Writer documents could embed formulas in some fields? The obvious case is for tables computations but this is possible with variable fields as well. The weird thing there is that the formula syntax is specific to Writer and isn't standardized. Writer can compute formulas from doc/docx files which have a syntax very closed to ODF Formulas's one thanks to [https://gitorious.org/ixion ixion] library. The goal of this task is to push forward this started effort to allow users to type ODF Formulas instead of the old syntax. Of course the old syntax still needs to be parsed / written for backwards compatibility.
The project could be split into several parts:
* Clean up the formula fields computation code to delegate computation to ixion and use ODF Formulas as the internal syntax.
* Change the UI to input ODF formulas
* Change the ODF import and export filter to load and save both syntax. A compatibility option will probably be needed to determine which syntax to save back.
Here are some code pointers to get started in the task:
* SwTableFormula is the class handling the table formulas computation: http://opengrok.libreoffice.org/search?refs=SwTableFormula
* SwInputWindow is the class for the formulas input bar: http://opengrok.libreoffice.org/xref/core/sw/source/ui/inc/inputwin.hxx#58
'''Required skills / knowledge'''
C++, Reading other's code
'''Difficulty:'''
medium
'''Potential mentors:'''
* Please ask on the LibreOffice developers mailing list.
=== Filters ===
==== Use PDF import's layout recognition for other vector formats (e.g. postscript, wmf/emf) ====
LibreOffice PDF import employs some amount of layout recognition techniques, to generate a layout-compatible document. Leveraging this framework for other vector formats will make LibreOffice an editor not only for PDF, but also for Post``Script, EMF, XPS - whatever the successful applicant for this task chooses to import.
Code pointers:
* current pdf import layout handling: https://cgit.freedesktop.org/libreoffice/core/tree/sdext/source/pdfimport/tree/drawtreevisiting.cxx
'''Required skills / knowledge'''
C++, Reading other's code
'''Difficulty:'''
medium
'''Potential mentors:'''
==== Implement Quattro Pro Import filter ====
The (binary) Quattro Pro file format is reasonably well documented - which should make this task reasonably easy. There is also an existing filter for the .wb* file formats. We really want to provide support for the much more modern .qpw file format - to allow users to migrate away to ODF. For many years Dell (for example) have shipped Quattro Pro bundled on their PCs, and there are lots of files out there, it'd be great to help those guys out.
The existing legacy qpro filter code is [https://cgit.freedesktop.org/libreoffice/core/tree/sc/source/filter/qpro here] and is fairly simple. We should build on this, and share as much code as possible, with an initial focus on data rescue: getting the strings, numbers, and simple formulae across - before expanding to formatting: fonts, weights etc. It should be easy enough to get something visible, and a fun thing to hack on. Reasonable specifications for the binary format are available on request for interested students.
'''Required skills / knowledge'''
C++
'''Difficulty:'''
easy
'''Potential mentors:'''
==== 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: {{nospam|fridrich.strba|bluewin.ch}}
* ''Valek Filippov'', IRC: frob, frob_tea, mail: {{nospam|frob|gnome.org}}
* ''David Tardon'', IRC: dtardon, mail: {{nospam|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: {{nospam|fridrich.strba|bluewin.ch}}
* ''Valek Filippov'', IRC: frob, frob_tea, mail: {{nospam|frob|gnome.org}}
* ''David Tardon'', IRC: dtardon, mail: {{nospam|dtardon|redhat.com}}