Development/GSoC/Ideas without a mentor
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
For the following ideas, you need to find a mentor. If you are interested, send a mail to our dev list. See also the list of proposed projects with a mentor.
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.
Move Beanshell and Rhino to extension
Currently 2 scripting language implementations that run on the JVM and depend on the Java Scripting Framework are bundled with LO: Beanshell and Rhino (JavaScript)
These have few users, so it would make sense to un-bundle them into an extension (or several?), which hopefully should require little maintenance once it exists.
This is in core.git in these directories: external/rhino, external/beanshell, scripting/java, scripting/Jar*.mk
There is also a "ScriptProviderForJava.jar".
An important part of un-bundling is that the LO build system is not available for building the extension so some new build system has to be added; currently patched Beanshell and Rhino are built with Ant.
For inspiration, see the XSLT 2 transformer extension that was created some 10 years ago: https://github.com/dtardon/xslt2-transformer
TODO: it's not clear whether to unbundle ScriptProvider.jar as there may be an "oorexx" extension using it.
Documentation pointers:
- Required skills/knowledge
- Java, Extensions
- Size
- 175 hours
- Difficulty
- Easy
- Potential mentors
User Experience
Implement macOS native full screen and tabbed windows
Currently on macOS, LibreOffice has disabled full screen and tabbed windows by setting the collection behavior for all NSWindows (see https://developer.apple.com/documentation/appkit/nswindowcollectionbehavior?language=objc) to NSWindowCollectionBehaviorFullScreenNone.
The project will consist of enabling full screen and tabbed windows depending on the type of NSWindow and then debugging and fixing the bugs that are likely to appear. LibreOffice originally implemented this feature on an older version of OS X, but many bugs were found during testing and the feature was disabled. So, you will likely spend a large portion of your time debugging and fixing old and new bugs.
Important note: you will need an Intel or Silicon Mac running macOS Big Sur or higher to work on this project.
- Required skills / knowledge
- (C++, Objective-C, Familiarity with macOS AppKit, Reading other's code)?
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- ?
Improve macOS native accessiblity performance
Currently on macOS, LibreOffice supports native macOS accessibility features such as VoiceOver by adding an NSView for each accessible element. Each LibreOffice document has hundreds and sometimes thousands of accessible elements and adding and removing a large number of NSViews can cause very poor performance. For example, a Calc document will add an NSView for each non-empty cell and scrolling through a large Calc document will add and remove a several thousand NSViews.
The project will initially consist of upgrading the LibreOffice code to use Apple's lightweight NSAccessibilityElement (see https://developer.apple.com/documentation/appkit/nsaccessibilityelement?language=objc) instead of a heavyweight NSView for each accessible element. The project will also consist of implementing performance data logging in LibreOffice's macOS accessiblity code to benchmark performance.
Important note: you will need an Intel or Silicon Mac running macOS Big Sur or higher to work on this project.
- Required skills / knowledge
- (C++, Objective-C, Familiarity with macOS AppKit, Reading other's code)?
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- ?
Chart wizard
For experienced people, the current wizard distracts from the workflow and steps are not naturally implemented, for instance the range is selected first and then the type of chart. Over the modules we have different ways to insert charts plus the wizard design is inconsistent with other dialogs which are tabbed. Mockups
- Required skills / knowledge
- C++, UI, UNO, reading other's code
- Size
- 350 hours
- Difficulty
- Hard
- Potential mentors
In-app rating / un-structured feedback
Some of our users want to provide feedback - but are too busy to create UI accounts. We should create something like Mozilla's input - https://wiki.mozilla.org/Firefox/Input/Feedback_Strategy that allows a user to provide a * rating, some un-strutured text input, and optional E-mail for a reply and the ability to attach a file if they want to. That way we can correlate *'s against versions and find problems more quickly - and depending on volume can triage that to see if anything jumps out: as well as auto-harvesting documents for our systematic crash-testing.
- Required skills / knowledge
- C++, Reading other's code
- Size
- Large
- Difficulty
- Varying
- Potential mentors
- (?)
Improve usability and visibility of AutoText feature
AutoText [1] [2] in LibreOffice Writer is a fantastic and powerful feature, which hasn't received much developer attention for many years. The usability of the features has tremendous problems and the feature is not sufficiently visible for the user. Also, the way how saved AutoText snippets are presented to the user, how they can be found and selected could be substantially improved. The GSOC project is about improving usability of the feature and bringing it up to par to the year 2024. There are also a number of outstanding bugs (meta-bug tdf#108663) concerning AutoText that need to be fixed along this project.
For more details on UX issues with AutoText, see bug tdf#52607 and tdf#50912.
- Required skills / knowledge
- C++, Reading other's code
- Size
- Medium
- Difficulty
- Medium
- Potential mentors
- (?)
General
Improving the updater
The Updater is crucial to getting Windows (and macOS) 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, macOS API, Reading other's code. Experience writing non-trivial NSDocument-based macOS applications required. Actually we are surprised if any student shows up with the required knowledge... Difficulty: Hard Potential mentors
Font handling - Substitution & Listing
A large number of user requests comes from issues with fonts. The substitution of fonts is unclear and cannot be easily configured and browsing through the list is tedious for a large number of installed fonts.
- Blog post: Dealing with Missing Fonts https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/
Feature request:
- [META] Font bugs and enhancements tdf#102985
- Font subsitution tdf#103342
- Bundled fonts tdf#113305
- Options (hide unused)
- Smart fonts; ODF 1.3 tdf#129219
Required skills / knowledge Difficulty: Potential mentors:
Keyboard customization
Customization of menus and toolbars was improved during GSoC'17. But beyond a search we still provide a strange way to customize the shortcut association. Plus, the internal representation of key codes need an update to not focus on American English.
Feature request:
- Allow other keys than from US keyboard as shortcut keys tdf#115052
Required skills / knowledge Difficulty: Potential mentors:
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 wasn’t a complete theme (e.g. theme background doesn’t appear in toggled buttons, theme didnt change the color of the statusbar or scrollbars, theme didn’t change the document color scheme, theme didnt change icon set, etc).
Feature request:
- https://wiki.documentfoundation.org/Development/GSoC/Ideas#Application_Themes
- https://docs.google.com/document/d/1J_aogLuQThqhvT0R2em27Vpew-SLAQgpH5TbNTgXPZM/edit
Required skills / knowledge Difficulty: Potential mentors:
Custom Shapes
Custom shapes are today mixed with clipart in the gallery and easy to confuse with grouped objects. There is no simple way to create custom shapes and existing shapes cannot be edited internally. Custom shapes also lack on multicolor capability. The features needed are: inbuilt editor, better/more predefined shapes (e.g. arrows, mockup controls etc.), and an updated gallery.
- New gallery https://wiki.documentfoundation.org/Development/GSoC/Ideas#Revamp_the_gallery_tool
- Blog post on Shapes sidebar: https://design.blog.documentfoundation.org/2015/04/02/libreoffice-design-session-shapes/
Feature request:
- Multi color: tdf#103298
- Shape creation: tdf#101862
- More shapes: tdf#87892
Required skills / knowledge Difficulty: Potential mentors:
The navigator lacks on interaction features, right click, double click etc. The visualization is limited and the content cluttered with various information (Writer lists chapters, tables, comments, bookmarks etc.). The proposal is to have a familiar UI as known in file browsers. This may require to implement a new Navigator from scratch (and to keep the current solution in parallel), possibly in more than one GSoC sessions.
Feature request:
- [META] Navigator sidebar deck and floating window tdf#103030
Required skills / knowledge Difficulty: Potential mentors:
Extend SfxStyleFamily by Shapes
In order to have the drawing styles at menus and toolbars we need access to it. There exists the UNO command StyleApply with the attributes Style <string> (set to "Filled Blue", for example) and FamilyName <string> which needs to be added. However, there exists no special style family for frames but frame and shape styles both belong to the family 'graphic'. The distinction between frame and shape is done by the fact, that the automatic style which is referenced by the object has a parent style in case of a frame and does not have a parent style in case of a shape. The parent style is a custom style and visible in the UI. Another problem is, that using custom styles is not implemented for shapes in Writer. Meaning, if you directly refer a custom style in the draw:style-name attribute of an object, it will make the object to a Writer-object if possible and will be ignored otherwise.
Feature request:
- Extend SfxStyleFamily by Shapes tdf#123789
Required skills / knowledge Difficulty: 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 Dialog Editor Module Window Layout Dialog Window Layout
Required skills / knowledge: C++, Reading other people's code Difficulty: medium Potential mentors:
Impress/Draw
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:
- 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
Brushes
Brushes are known in Inkscape as kind of modifications to lines/connectors making it appear like a brush stroke or a small pencil. Another use case is to allow scribbled lines for UI mockups. Ideally it will also cover the request for wavy lines as some kind of post-processing where the actual y value of x is modified by some formula. This flexibility would be newly introduced with LibO.
Feature request:
Required skills / knowledge Difficulty: Potential mentors:
Calc
Support charts in orcus
Orcus is an external library for importing spreadsheet formats that is already used for a few features in Calc. However for now we are limited to spreadsheet support and we should extend support to charts. Orcus works by providing an interface of virtual methods that must be implemented on the client side. We try to keep the interface format independent and try to always support at least OOXML and ODF.
If the time permits we should also work on some experimental integration of the chart import code into LibreOffice.
The spreadsheet interface is mostly in include/orcus/spreadsheet. The chart interface should be similar.
- Required skills / knowledge
- C++, Reading other's code, debugging, Reading specifications
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- Markus Mohrhard, IRC: moggi, mail: markus.mohrhard@googlemail.com
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.
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: https://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2177
- Popup menu creation: https://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/templdlg.cxx#2236
- Writer default styles hard-coded attributes: https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/poolfmt.cxx#1079
Required skills / knowledge: C++, Reading other's code Difficulty: medium Potential mentors:
ODF Formulas in Writer
Did you know Writer documents could embed formulas in some fields? The obvious case is for tables computations but this is possible with variable fields as well. The weird thing there is that the formula syntax is specific to Writer and isn't standardized. Writer can compute formulas from doc/docx files which have a syntax very closed to ODF Formulas's one thanks to ixion library. The goal of this task is to push forward this started effort to allow users to type ODF Formulas instead of the old syntax. Of course the old syntax still needs to be parsed / written for backwards compatibility.
The project could be split into several parts:
- 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: https://opengrok.libreoffice.org/search?refs=SwTableFormula
- SwInputWindow is the class for the formulas input bar: https://opengrok.libreoffice.org/xref/core/sw/source/ui/inc/inputwin.hxx#58
Required skills / knowledge: C++, Reading other's code Difficulty: medium Potential mentors:
Improvements for Table Manipulation in Writer / Table handling like at iWorks
Tables are an important feature as well in Writer. Big step ahead would be when the manipulation of tables is supported by UI means.
Some mockups: https://docs.google.com/document/d/1D212Ihf8BYVOa1VjSPifq4sO_Cq4CZPhC0vya68zk3c
Feature request
- UI for table manipulation: tdf#113603
- Permanent auto size: tdf#113604
- Better col width adjustment tdf#113960
Required skills / knowledge Difficulty: Potential mentors:
UI to modify/create Table Styles (also relevant for Calc)
Table styles have been introduced for 5.3 with a GSoC project from 2016, but there is no UI to manipulate the table styles.
Blog post about Table Styles: https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/
Feature request:
- GSoC table template: Crash on Modify custom table style or creating New (in context menu)tdf#101648
Required skills / knowledge Difficulty: Potential mentors:
Filters
Improve Zoner Draw import filter
libzmf, a library for import of Zoner Draw documents, was implemented as a GSoC 2016 project. Currently the library only supports documents created by versions 4-5. There are two goals in this task:
- handle some of the missing features (blending, warping of the bounding rectangle);
- add support for the file format produced by versions 2-3.
Both formats have been almost completely reverse-engineered.
- Required skills / knowledge
- C++, Reading other's C++ code (to understand the existing libzmf code). Python (for OLEToy) is welcome, but probably won't be needed
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- David Tardon, IRC: dtardon, mail: dtardonredhat.com
Improve Adobe Pagemaker import filter
libpagemaker, a library for import of Adobe Pagemaker documents, was implemented as a GSoC 2013 project. In the current state, the library only supports documents created by versions 6.5-7.0 on Windows. Documents of version 6.0 should be opened more-or-less correctly, but the support has never been specifically tested. Documents created on Mac are never opened correctly because of many oversights in the code.
The goals of this taks are to fix import of Mac 6.5-7.0 files, implement some missing features and add support for older versions, both Mac and Windows (starting at 6.0 and proceeding to older ones until we run out of time :-)
We will use OLEToy for any necessary reverse-engineering. We will also create documents for regression testing for all versions we add support for.
- Required skills / knowledge
- C++, Reading other's C++ code (to understand the existing libpagemaker code). Python (for OLEToy)
- Size
- 350 hours
- Difficulty
- Medium
- Potential mentors
- David Tardon, IRC: dtardon, mail: dtardonredhat.com
- Fridrich Strba?, IRC: Fridrich, mail: fridrich.strbabluewin.ch
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 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:
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 macOS.
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.strbabluewin.ch, Valek Filippov, IRC: frob, frob_tea, mail: frobdf.ru, David Tardon, IRC: dtardon, mail: dtardonredhat.com
Improve legacy StarOffice binary formats import filter
StarOffice 1.x - 5.x produced a variety of binary formats. These had been handled in LibreOffice by the notorious binfilter
, which was removed in 4.0 since it was completely unmaintainable. Some time later, a library named libstaroffice was created with the goal to implement import of these old formats from scratch. libstaroffice is already integrated in LibreOffice. Currently it supports text, spreadsheet and drawing documents of versions 3.1-5.x (some details regarding what's supported can be found on the project's homepage).
The goal is to either improve import of the supported format versions or to add support for older version(s).
Required skills / knowledge: C++, Reading other's C++ code (to understand the existing libstaroffice code and to extract file format details from binfilter), Difficulty: medium Potential mentors: Laurent Alonso, mail: alonsoloria.fr, David Tardon, IRC: dtardon, mail: dtardonredhat.com
Implement MathType 4+ import filter
LibreOffice contains an import filter for OLE objects created by MathType 1-3 (aka MS Equation). The goal of this task is to extend this filter to handle the newer format produced by MathType 4-6 (and possibly also to improve the existing filter). The format has been partially reverse-engineered, but a lot more work will be needed.
Required skills / knowledge: C++, Reading other's C++ code, Ability to understand hex dumps, Access to MS Office with MathType 4-6 installed Difficulty: medium Potential mentors: David Tardon, IRC: dtardon, mail: dtardonredhat.com, Caolán McNamara, IRC: caolan, mail: caolanmredhat.com