LibreOffice for Haiku, a not-so-short story
As many of you are already aware, LibreOffice is now available on Haiku. This has been a long journey that has started for me around 2014, when I was looking for things I could do for the project. LibreOffice port was one of those things. It seemed to need so much effort, most people didn’t even want to start. That’s understandable given people were busy developing the OS. However, it’s not the first time someone tried to do it.
Earlier effort
WebArchive has a copy of a wiki page detailing how to build OOo4Kids on Haiku. It’s so far in the past, that it says it can’t be built on Alpha 2 because of some bugs. The person working on that was oco. But wait, what is OOo4Kids and why port that instead of full Open/LibreOffice?1
It is a lightweight version of Open Office (it was before LibreOffice fork). At that time, it was better to start with that as some dependencies not available under Haiku were already removed, like Java
oco didn’t get very far in terms of usability: he had everything compiling, with VCL (LibreOffice’s GUI toolkit) being just an empty shell. However, looking at these instructions and considering this was before Haiku had a package manager, I’m guessing a lot of work and figuring things out were needed to get to that point. That being said, I ended up starting from scratch.
Package management
You can see haikuporter being mentioned on that wiki page, so it couldn’t be that bad, right? Well, yes and no. Haikuporter back then was a one way street: you could automatically build and install things, but it didn’t create packages, it just copied stuff to (not always) appropriate places. It also used different recipe format (BEP files, some of them hang around to this day). I don’t have too much experience with that incarnation of this system.
I do remember problems with libraries being put in the wrong place, though. These problems were a result of hybrid system architecture: GCC2 and GCC4 executables being put along side each other. Sometimes a GCC4 library was put where GCC2 version should have been or wrong path was set, and you would get mysterious linker errors that wouldn’t even mention which file was a culprit. Since LibreOffice could not be built with GCC2 I decided to work on GCC4 hybrid system, with GCC4 as a primary architecture, where this problem would not happen. Figuring out how build system of such a big project works was hard enough, I didn’t need additional obstacles.
Fortunately, my fears were not realized: package management was already merged; it was (and still is) so much cleaner and a pleasure to work with. I have started creating recipes for missing libraries LO’s configure was complaining about. Not long after I got commit access to HaikuPorts.
Some recipes were easy; thanks to Haiku’s POSIX compatibility and autotools portability2, most of them worked out of the box. Document Liberation Project’s libraries fall into that category and they were ~50% of the dependencies. Some not so much: I got stuck on NSPR and NSS and asked for help on haikuports' ML.
That wasn’t a blocker though: I could bypass the requirements by building each module by hand. It was tedious but I worked like that for some time. I managed to go as far as oco did; I could experiment with building VCL and writing Haiku backend for it.
That has stopped when I reinstalled Ubuntu only to find out, that it wiped out all my partitions due to a bug in the installer. Most of my patches were backed up, but I lost some work as a result of this. 2015 has started.
An editor! An editor! My kingdom for an editor!
Discouraged, I decided to tackle another issue that came up: lack of a code editor. Sure, there is Pe, but it has one dealbreaker when it comes to working on LibreOffice: it can’t use spaces as indentation. LO uses 4 spaces and has a git hook which prevents commits that break this guideline from going in. It quickly got annoying. I have tried to add this feature to Pe, but after a few experiments gave up.
I wasn’t comfortable with using vim back then; I remembered I saw an early Scintilla port somewhere. I took this code, polished it to the point of being usable and started working on an editor based on it. After two years, on January 1st, 2017 I released Koder 0.1 and I am using it for my Haiku coding needs ever since (actually even earlier).
Two years is a lot of time, but that’s the reality of working on side projects in free time. Could it be spent better? No! Koder and Scintilla were a great exercise in using BeAPI, knowledge that is obviously needed when writing a GUI backend.
Back on track
Editor woes out of my way, I could go back to LibreOffice. In the meantime, more libraries got ported, NSS among them, I learned a lot as well — it made things easier going forward. Thanks to these new ports I no longer had to build modules and manage dependencies between them by hand. Many libraries were also available in the depot, so time to set up the development environment got cut too.
Learning from past mistakes, I have rebased the patches against 5.3 branch instead of master, to have a stable target. On January 3rd, 2017 I have pushed them out to my fork, and 10 days later I managed to have a first VCL window on my screen. Commits were flowing for about a month, with some more in April. At this point if ran soffice.bin you would see this:
It’s not entirely accurate, because one day after this screenshot was taken, I managed to get bitmaps working, which replaced all those nasty rectangles with nice Breeze icons. :)
Sprint to the finish…
Fast forward to November 2017. PulkoMandy has organised a Haiku coding sprint in Toulouse, France. I didn’t intend to work on LO there, but after taking care of PowerStatus look and fixing some minor bugs, I didn’t want to start a new thing I could not finish there. I have resumed work on the port and a lot of progress was made, thanks to no-interruptions atmosphere. Three days later I got this:
PulkoMandy gave me some tips how to alleviate constant crashing, which was caused by race conditions. Drawing from his experience with WebKit port, I rewrote the backend to use offscreen bitmaps. That made it crash much less.
mmu_man suggested that I should give a presentation about the port in Open Document Editors track at FOSDEM in February. I didn’t plan to go to Brussels, but I submitted a proposal and to my surprise, it got accepted.
Final stretch
After the presentation I talked with Michael Meeks about the port. He was very glad to see someone work on a new port and diving into VCL. He encouraged me to upstream my patches as soon as I can and suggested using Cairo for rendering 3, which would save significant amount of work. I wanted to push LO out to users as soon as possible so I started pursuing that. I have cleaned up and upstreamed the basics that enabled LO to compile on Haiku. GUI port was very hacky so I omitted that part of the code.
Somewhere around that time Qt port started taking shape and diver asked if that could be used. I didn’t like the idea at first 4 but intrigued I tried to build it. With my knowledge of the build system it was pretty easy and I didn’t even have to write any new code. With that in place, diver and 3dEyes took it from there.
If there is something I wish I did differently, it’s that I should’ve started working on using Cairo backend earlier. Maybe I would be done with the port by the end of the coding sprint, and make it available earlier. Hindsight is 20/20, as they say.
What’s next?
Although the code I wrote is not used in the end, it is a base that could be used by someone bothered by the fact, that our LibreOffice port is using Qt. There are two branches in my repository:
- haiku — native BeAPI backend lives here, based on 5.3 branch
- haiku-6.0 — my attempts to use Cairo, based on master branch
I will do some work on the native backend from time to time. First thing to do is merging these two branches, so Cairo and BeAPI backend can be compiled from one codebase. However, since it’s not important to make it available quickly, I’d like to contribute to other things like WebKit. I also have my own projects to maintain now: Scintilla port, Koder (mentioned earlier) and Polyglot (which I wrote to simplify management of localization files for apps).
During my efforts to get LO working I got commit access to Haiku itself, too. While I’m trying to not get sucked into the main project (Haiku needs app developers!), there are some interesting areas I’d like to work on. LibreOffice has uncovered some bugs in the OS and we’re close to beta now, so all hands on deck.
Special thanks to…
- bonefish and olta for an excellent package management implementation
- AnEvilYak for being very responsive when I had issues with Debugger
- korli for help with some library ports
- PulkoMandy for the coding sprint and tips
- diver and 3dEyes for their work on Qt and KDE ports for Haiku
- HaikuPorts team for making package management actually useful :)
-
Relevant reading about dependencies. ↩︎
-
As much as writing and setting up autotools scripts is a pain, it truly is portable. Just supply proper paths, add some cases in switches and you’re set. ↩︎
-
Turns out waddlesplash asked me about it as well in April 2017. ↩︎
-
LO->VCL->Qt->BeAPI — that’s a lot of abstractions… ↩︎
