User-centered development is implicitly steering the development from the top of the cathedral. That means to start with a vision, the context of use, and the primary users etc, granularized later into product requirements with storyboards and use cases, and finally iterating with product design and development. However, open source typically works bottom-up from the bazaar. It begins with small changes from someone who implements a feature she or he likes, eventually growing in complexity and completeness done by others.
The development takes this duality into account typically by introducing constants or default values. For example, LibreOffice has built-in sets of icon themes, predefined color palettes, or fonts. And as a designer you may need to deal with the code in order to change these defaults. In most cases it’s simply editing XML files but sometimes it also might be handy to have basic coding skills.
This post shows how to set up the build environment and to find the right places in the source code, all from the designer’s point of view. Other blog posts will follow going more into detail.
Setting up the build environment
On Linux it’s pretty easy to setup the build environment. You need git to get the source code and the c++ tool chain with some dependencies. Luckily everything is made very easy by the package management. So you just have to run the following commands on Ubuntu:
sudo apt install git
git clone git://anongit.freedesktop.org/libreoffice/core libreoffice
sudo vi /etc/apt/sources.list
// uncomment #deb-src http://archive.ubuntu.com/ubuntu/ xenial main restricted
sudo apt update
sudo apt build-dep libreoffice
Similar support is available for other distributions. And the wiki has many further information for you: Building LibreOffice on Linux and BSD systems.
On macOS it’s not much more difficult and works straightforward, and we also provide comprehensive information for Windows users. But if you fail for some reason, why not install a virtual machine (e.g. VirtualBox) with Linux?
The layout of most dialogs in LibreOffice as well as the Notebookbars are manipulated with Glade. Linux users can install Glade via the package manager and on macOS you can use homebrew (or other 3rd party package manager). The situation is different on Windows where Glade might install with the binary installer but will likely fail when it comes to the configuration. There is a short abstract on our wiki but you should rather consider a virtual environment.
After installation, Glade needs to be configured. Otherwise you will be warned that the LibreOffice catalog is missing. Just enter the path to <source>/instdir/share/glade at the preferences, which results in the additional section LibreOffice at the palette sidebar.
Figure 1: Glade’s configuration dialog with proper configuration.
The LibreOffice wiki shows how to create a new dialog with Glade – don’t be afraid of the source code. Changing the placement of controls is almost as easy as drag and drop.
LibreOffice is one of the largest open source projects with millions of lines in a source code of varying spaghettiness. Most newcomers fear this complexity and don’t know where to start coding. But it’s surprisingly easy for front end developers and designers. Just find a string in the dialog, menu, or control that is unique enough to search for and use either git grep or the web based tool OpenGrok.
For example, you may want to change the caption “Type and Title” at the table of contents dialog. Take this string, enter it with double quotes at opengrok (the search is case sensitive; and you can use jokers like Foo* for a broader search), use core when projects is empty, and you will find tocindexpage.ui under <source>/sw/uiconfig/swriter/ui/.
You think it would be better to collect all save options from the main menu in a subdirectory? Search for the most distinct term “Preview in Web Browser” and find all menu options stored in GenericCommands.xcu under <source>/officecfg/registry/data/org/openoffice/Office/UI/.
Sometimes it might be necessary to progress step-by-step. You start with a labeled control, look through the code for a unique command, and take this into another search.
Coding is only fun when shared. So what happens when you have modified the caption in the example above? Everyone can submit patches to our code review platform Gerrit. You have to create an account and configure SSH. The script logerrit shared with the LibreOffice source code simplifies this procedure. The wiki page Setting yourself up for Gerrit has all necessary information.
Once everything is configured correctly you run git add <files>, git commit, and ./logerrit submit master to upload your changes. If a reviewer agrees with your patch it will get merged and finally make millions of users happy.