The Document Foundation (TDF) is the charitable entity behind the world’s leading free/libre open source (FLOSS) office suite LibreOffice.
We are looking for an individual or company to implement support for a dedicated, built-in UNO object inspection tool in LibreOffice, to start work as soon as possible.
In order to make working with UNO objects easier and to avoid the need to always install extensions before debugging, it is necessary to be able to inspect UNO objects in a running LibreOffice instance effectively.
This task involves reading the existing Basic IDE Watch code, evaluating how it can be improved based on ideas implemented in external tools like xray and MRI and extending the Watch code to be a first-class inspector that allows focusing the relevant part of the UNO API for opened documents and also based on your current selection (similar to what is possible in web browsers).
A good part of the features are implemented already. Work carried out under this tender will therefore mostly consist in making the features more accessible and more stable, adjusting the UI and refactoring things.
The work has to be developed on LibreOffice master, so it can get released in the next major version.
The following required features need to be implemented:
- Dockable toolbar that can appear at the bottom of a document frame, similar to find-bar.
- Left-hand side of the toolbar exposes a snapshot of a useful subset of the DOM as a tree view: Writer paragraphs, Calc sheets, Impress slides
- This tree widget should populate its content on-demand whenever possible in order to ensure performance.
- Right-hand side: show details in a table about the current selected item in the “DOM tree-view”, which is implemented as part of the watch window in the Basic IDE:
- object’s UNO properties
- object methods
- supported services and interfaces
- User documentation for the new dialog is mandatory.
- Brief developer documentation for the newly introduced classes is required.
- Whenever adding new functionality, it should be considered if it’s possible to test the functionality with automated tests with reasonable amount of effort.
The following are optional features:
- Configuration support: remember which tabpage was open last time (properties, methods, etc.)
- Remember sorting settings (prioritize paragraphs/sheets/slides and other relevant properties or sort alphabetically)
- Click on value for details: primitive types
- This is useful if the user selected lots of text for inspection, we can’t show all the content in a table cell, but can if a multi-line edit replaces the table widget.
- Click on value for details: re-launch DevTools on a sub-object on the right-hand side. This is already handled to a large degree in the existing watch variable code, which represents the object already as a tree.
- This allows recursion: double-click on a value with a complex type, which has its own properties, methods, etc -> inspect it.
- Show implementation name of object
- If a consistent name is provided by the object, this can allow jumping to the relevant C++ code from DevTools easily.
- Copy&paste support:
- Normally content of a table in a widget is not easily copy&paste-able. It can help debugging if add explicit support to copy the table content still, e.g. all property names and their primitive values.
- Improved presentation of the DOM for Writer/Calc/Impress:
- The inspector tool could be just a generic presenter for any UNO object, but in practice macro and extension authors are interested in a subset of the extremely rich and generic API we provide.
- The idea is to select a few key properties for each component, so it’s trivial for the user to see how to access the most important details of a document:
- Writer: style families, paragraph list, text portion list, etc.
- Calc: sheets, columns, cells, named ranges, etc.
- Impress: slides, shapes, etc.
Required skills
- Extensive knowledge of C++
- Experience working on the LibreOffice source code
Other skills
- English (conversationally fluent in order to coordinate and plan with members of TDF)
We use free, libre and open source (FLOSS) software for development wherever possible, and the resulting work must be licensed under the Mozilla Public License v2.0.
TDF welcomes applications from all suitably qualified persons regardless of their race, sex, disability, religion/belief, sexual orientation or age.
Bidders will get a preference for including a partner or independent developer who has not been involved in a successful tender before.
As always, TDF will give some preference to individuals who have previously shown a commitment to TDF, including but not limited to certified developers and/or members of TDF. Not being a member, or never having contributed before, does not exclude any applicants from consideration.
Further discussions on this tender took place on the public board discussion mailing list of The Document Foundation.
The task offered is a project-based one-off, with no immediate plans to a mid- or long-term contractual relationship. It is offered on a freelance, project basis. Individuals and companies applying can be located anywhere in the world.
When budgeting, we anticipated that this project (incl. optional tasks) to take in the region of 60 days of work. Bidders are free to bid on the required features only. Bidders who bid on both the required and optional features are asked to provide a breakdown in terms of costs for each.
TDF is looking forward to receiving your applications for one or more of the aforementioned tasks, your financial expectations and the earliest date of your availability, via e-mail to a committee at tender20200702@documentfoundation.org no later than September 1, 2020.
Applicants who have not received feedback by October 15, 2020 should consider that their application, after careful review, was not accepted.
