GSoC Ideas

    From The Document Foundation Wiki

    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. 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.

Goal(s) - the expected outcome of the project.

;Required skills / knowledge: C++, Reading other's code, and any other useful skill required go here.

;Size: 90, 175 or 350 hours

;Difficulty: Range among easy, medium, hard

;Potential mentors
:''Joe Devel'', IRC: jdevel, mail: {{nospam|joe|devel.org}}

    Please move successfully completed projects to Development/GSoC/Successfully Implemented Ideas.

    Tooling

    Tests

    While there are some automated tests for LibreOffice, there are not nearly enough. Adding more and better tests helps developers who work on the code to be more productive by allowing them to find regressions as early as possible.

    More and better tests, porting Java tests to C++/Python

    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.

    Goals
    • Port tests from Java to C++ (or Python, in some cases)
    Required skills
    C++, Java, or Python; for unit level tests reading other's code
    Size
    350 hours
    Difficulty
    Medium
    Potential mentors
    Hossein Nourikhah, mail: hossein@libreoffice.org
    Xisco Fauli, mail: xiscofauli@libreoffice.org

    More and better tests, writing missing unit tests

    It is expected that every bug fix is accompanied with a unit test. But, sometimes developers do not provided such tests. In those cases, it is possible that the exact same problem come back in the future. To avoid that, it is important to find those issues, and write unit tests for them.

    Bug fixes which lack unit tests are gathered with a script, and are added to the MissingUnitTests Wiki page. The goal here is to add unit tests for these issues.

    Each of these issues has a priority and assigned, and is around an application or specific subject. It would be best to work on specific areas to remain more focused.

    Goals
    Required skills
    C++, Java, or Python; for unit level tests reading other's code
    Size
    350 hours
    Difficulty
    Medium
    Potential mentors
    Hossein Nourikhah, mail: hossein@libreoffice.org
    Xisco Fauli, mail: xiscofauli@libreoffice.org

    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:

    LibreOffice Theme

    LibreOffice allows a lot of customization but follows strictly the system settings in case of the UI (eg. dialog or button background color). We provide some means under Tools > Options > Personalization to change the theme using Mozilla's persona. But this framework changes often and has limitations. Adding a way to theme the application serves not only users who want to customize the application but allows also to overwrite the hard contrast for the dark mode under Windows. See also tdf#125217 "Replace Mozilla themes with a proprietary tool reusing the existing".

    Goals:

    • Introduce a simple way (XML) to overwrite the system colors
    • Make it available via extension

    Stretch goals:

    • Customization beyond plain colors with gradients and wallpaper available on at least the Notebookbar
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    (Medium)?
    Potential mentors
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze@documentfoundation.org

    Comments in sidebar

    Comments are shown in the document margin which leads to issues with a large number of comments. Learn more at https://design.blog.documentfoundation.org/2024/01/12/comments-in-sidebar/.

    Goals:

    • create a new sidebar deck
    • show the comments in a treeview
    • provide interactions with the comments

    Code pointers:

    • current Writer comments implementation is mostly under sw/source/uibase/docvw, see AnnotationWin.cxx & AnnotationWin2.cxx
    Required skills / knowledge
    (C++, Reading other's code)?
    Size
    350 hours
    Difficulty
    Hard
    Potential mentors
    Heiko Tietze, IRC: htietze, Mail: heiko.tietze@documentfoundation.org
    Sarper Akdemir, IRC: quwex, Mail: sarper@libreoffice.org

    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.

    Mockup: https://bug-attachments.documentfoundation.org/attachment.cgi?id=130628

    Enhancement request on Bugzilla (and the various See Also tickets)

    Goals:

    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.

    Mockup: https://bug-attachments.documentfoundation.org/attachment.cgi?id=116906

    Enhancement request on Bugzilla.

    Goals:

    1. list all functions in collapsible sections (rather the current filtering per dropdown)
    2. add a help button to open the respective documentation page
    3. 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.

    Ticket on Bugzilla.

    Goal:

    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

    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.

    Goal:

    Make snapping and object selection pleasant to use.

    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

    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

    Goal:

    Make styles animatable.

    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.

    Goal:

    Get rid of ugly hack for rendering Impress content in slideshows by porting code to use DrawingLayer primitives.

    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)

    Goal:

    Replace hacky table formatting with real table styles in Calc.

    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.

    Relevant enhancement requests are tdf#81530 and tdf#82716, and it would make sense to tackle tdf#74665 at the same time.

    Goals:

    1. add histogram chart type
    2. time permitting, add more chart types introduced by MS Office 2016
    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.

    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 and a lightweight scripting language like LUA and latest version of .NET, which is cross-platform.

    Cross Platform .NET Binding

    .NET support for using LibreOffice API is currently limited to older versions of .NET <= 4.8, which was not cross-platform. .NET has changed a lot since that version, and the current version is .NET 8, and .NET 9 will be released in 2024.

    The implementation can use interoperability technologies to provide support for the newer versions of .NET on different platforms.

    Some documentation pointers are:

    Some code pointers are:

    Required skills/knowledge
    .NET, C#, interfacing to low-level C/C++, working against formal specifications
    Goals

    Make it possible to use LibreOffice UNO API with the cross platform .NET >= 6

    Size
    350 hours
    Difficulty
    Medium to hard
    Potential mentors
    Hossein Nourikhah, IRC: hossein, mail: hossein@libreoffice.org

    Rust UNO Language Binding

    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:

    Goal:

    Make it possible to use LibreOffice's UNO API with Rust.

    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: stephan.bergmann@allotropia.de
    Michael Stahl, IRC: mst___, mail: mst@libreoffice.org
    Bjoern Michaelsen, IRC: Sweetshark, mail: bjoern.michaelsen@libreoffice.org

    LUA UNO Language Binding

    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:

    Goal:

    Make it possible to use LibreOffice's UNO API with Lua.

    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@libreoffice.org
    Thorsten Behrens, IRC: thorsten, mail: thb@libreoffice.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.

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Development/GSoC/Ideas&oldid=748588"