GSoC Ideas

    From The Document Foundation Wiki


    This page lists the project ideas for Google Summer of Code, see the general info about LibreOffice and GSoC. All applicants are required to complete at least one easy hack.

    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 contributor 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 detailed 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.
    
    ;Size: 175 hours or 350 hours
    
    ;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.

    Tooling

    General

    User Experience

    The design team collected a number of ideas in in the pad http://pad.documentfoundation.org/p/UX-GSoC_Ideas. Not for all ideas mentors have committed so far. If you are interested in a task that has no mentor you would need to find someone. If the topic needs further refinement feel free to contact the UX team in order to prioritize the usability engineering. Some examples for full-featured topics:

    Variable units on numerical input

    LibreOffice allows to change the unit from cm to inch or point, etc. but only globally. Some workflows make it necessary to deal with different units at the same time. For instance the page size in inch, positioning of objects in centimeter, and size in points. The proposal is to allow switching the unit on the control.

    The requirements are:

    1. derive a new control from spin edit that allows switching the unit
    2. ideally but optionally remember the unit per control
    3. consider solutions to change the precision per adding decimal places
    4. replace the existing numerical spin edit controls
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    (Medium)?
    Potential mentors
    Andreas Heinisch, mail: andreas.heinisch@yahoo.de
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze @ documentfoundation.org

    Improvement to the functions deck

    LibreOffice Calc has a nice functions deck on the sidebar allowing to pick one of the many functions. This functions pane has some room for improvements.

    The requirements are:

    1. list all functions in collapsible sections (rather the current filtering per dropdown)
    2. provide a search field to find a function
    3. add a help button to open the respective documentation page
    4. consider direct editing capabilities
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    (Medium)?
    Potential mentors
    Andreas Heinisch, mail: andreas.heinisch@yahoo.de
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze @ documentfoundation.org

    Remember window size per document

    LibreOffice remembers the window size per module and it's possible to have, for example, a Writer document in landscape next to a portrait sized Calc sheet. However, closing the modules brings you back to the start center which overwrites the module size. And the size/position is not stored per document, which is a major problem for many users.

    The requirements are:

    1. restore the window size per module from the document
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    175 hours
    Difficulty
    (Easy)?
    Potential mentors
    Andreas Heinisch, mail: andreas.heinisch@yahoo.de
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze @ documentfoundation.org

    Quickly insert brackets

    Inserting brackets is a common task but somewhat tedious depending on the keyboard layout. It has been requested to provide a function that inserts brackets before/after a selection.

    The requirements are:

    1. add UNO command to add brackets
    2. add UI to access the UNO command
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    175 hours
    Difficulty
    (Easy)?
    Potential mentors
    Andreas Heinisch, mail: andreas.heinisch@yahoo.de
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze @ documentfoundation.org

    Sidebar deck for quick find

    Currently we show a classic quickfind toolbar on ctrl+F. This workflow can be improved by showing the results with a short annotation of words before and after to more easily spot what you are looking for.

    The requirements are:

    1. move the "find all" functionality from the quickfind bar into a new sidebar deck
    2. show some words before/after the reference
    3. jump to the place on click
    4. clearly identify the currently selected reference
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    (Medium)?
    Potential mentors
    Jim Raykowski
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze @ documentfoundation.org

    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
    Katarina Behrens, IRC: bubli mail: bubli @ bubli . org
    UX team, IRC: channel #libreoffice-design, mail: design @ global.libreoffice . org

    Improve snapping and object selection

    Snapping in LibreOffice is a bit awkward, and doesn't work as expected in some cases. There is also no advanced snapping supported (taking into account multiple object positions and distances), which would make object position and sizing much easier for the user. This idea involves investigating the existing implementation for snapping in the svx module and work on it.

    Extended goal for this idea is to look into object selection and handles rendering, consistency and UX. In some cases the selection and selection handles aren't properly rotated with the object, sometimes an outline of the selection isn't rendered or rendering could be improved.

    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    Hard
    Potential mentors
    Tomaž Vajngerl, IRC: quikee, mail: quikee @ gmail.com

    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
    Patrick Luby, IRC: plubius, mail: patrick.luby@collabora.com

    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
    Patrick Luby, IRC: plubius, mail: patrick.luby@collabora.com

    Base

    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: https://cgit.freedesktop.org/libreoffice/build/tree/patches/dev300/sd_effects_styles.diff?h=master-backup

    Required skills / knowledge
    C++, Reading other's code
    Size
    350 hours
    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.
    Size
    350 hours
    Difficulty
    Hard
    Potential mentors
    Thorsten Behrens, IRC: thorsten, mail: thb @ documentfoundation . org

    Calc

    Implement table styles

    Calc so far lacks real table styles, which for example can be seen in Impress tables, with formatting of header row, header column, banded rows and columns, total row, rightmost column, ...

    The existing old technology Format → AutoFormat Styles are visually similar, but very inefficient in that they apply individual attributes to individual cells, which a) is slow, and b) bloats the document size, and also can't cope with hidden rows or columns to keep a visually stable table style layout.

    See also tdf#132780

    (Actually, we don't have real table styles in Impress either; see bug tdf#151264. Perhaps the GSoC idea should be to actually implement these in one of either Calc or in Impress? -EyalRozenberg)

    Required skills / knowledge
    C++, Reading other's code, Debugging, Understanding the concept of different layers of cell attribution, Having an idea of how a single attribute with one value could be used for this
    Size
    350 hours
    Difficulty
    Hard
    Potential mentors
    Eike Rathke, IRC: erAck, mail: erack@redhat.com

    Histogram (and other missing) Chart Type

    There are multiple chart types added to Office 2016, which aren't supported in LibreOffice. The idea is to add the histogram chart (which is one of the newly added types) to LibreOffice and, if time permits, other types.

    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    Hard
    Potential mentors
    Tomaž Vajngerl, IRC: quikee, mail: quikee @ gmail.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.

    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:

    Required skills/knowledge
    Rust, interfacing to low-level C/C++, working against formal specifications
    Size
    350 hours
    Difficulty
    Medium to hard
    Potential mentors
    Stephan Bergmann, IRC: sberg, mail: sbergman @ redhat . com
    Michael Stahl, IRC: mst___, mail: mst AT libreoffice DOT org
    Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen AT canonical DOT com

    LUA 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 small, lightweight scripting language like LUA.

    LUA is small (few K lines of C), and written with the goal of embedding in mind:

    Besides hooking LUA up with LibreOffice's UNO subsystem, a taker for this project would need to map the various UNO constructs (its data types; objects with their multiple interfaces and methods; services and singletons) to suitable LUA types, 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. LUA should be expressive enough to permit that (its dynamic typing helps a lot there), just for exceptions and error handling, some extra thoughts might be needed:

    Some code pointers are:

    Required skills/knowledge
    LUA, interfacing to low-level C/C++, working against formal specifications
    Size
    350 hours
    Difficulty
    Medium to hard
    Potential mentors
    Michael Stahl, IRC: mst[_]*, mail: mst AT libreoffice DOT org
    Thorsten Behrens, IRC: thorsten, mail: thb AT libreoffice DOT org
    (Bjoern Michaelsen, IRC: Sweetshark)

    Ideas without a mentor

    A number of ideas from previous years can be found at the Development/GSoC/Ideas without a mentor page. Please note that you need to find a mentor willing to mentor the task. There is no guarantee that anyone in the community is going to mentor one of these tasks this year.