Development/GSoC/Ideas without a mentor

    From The Document Foundation Wiki

    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.

    Feature request:

    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:

    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.

    Feature request:

    Required skills / knowledge
    Difficulty:
    Potential mentors:
    

    Revamp the Navigator

    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:

    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:

    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.

    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:

    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:

    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

    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: dtardon@redhat.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: dtardon@redhat.com
    Fridrich Strba?, IRC: Fridrich, mail: fridrich.strba@bluewin.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:

    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.strba@bluewin.ch, Valek Filippov, IRC: frob, frob_tea, mail: frob@df.ru, David Tardon, IRC: dtardon, mail: dtardon@redhat.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: alonso@loria.fr, David Tardon, IRC: dtardon, mail: dtardon@redhat.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: dtardon@redhat.com, Caolán McNamara, IRC: caolan, mail: caolanm@redhat.com