In many countries in the world, Christmas is celebrated as time of peace. In olden days, in the Northern hemisphere, it was the mid-winter celebration – looking towards the new light to come. Nowadays, sharing presents is a popular activity at Christmas time.
So, let’s look at what presents LibreOffice has left under the tree… Ah, this is clearly the outline of a new major version: 3.5 🙂
I’ll try to unwrap this present a little, looking beneath the shiny paper.
What do I see: hundreds and hundreds of code commits, which talk about ‘clean up’, ‘rework’, ‘remove’, ‘easy hack’. Sounds like tech-talk to me. So how is this a great present to users?
I decided to talk to some developers, in an attempt to get an explanation about what all this work means – to mere mortal office-users like (probably) you and me 😉 Simply: what improvements, in which areas, can we see now or in the long run, as result of all this hard work?
Below you find the result of my search. Some parts are technical, some parts really talk about features for users.
I have stress that I was only able to cover a small part of all people and all the work … Nevertheless I hope you like the (greater) present.
Fast building
An important part of the software development process is ‘building’: converting the source code written by developers into something that we can download and install. But building is also important for developers, to prove that their work is OK, that it works as expected, or fixes the bug, and does not break something.
So developers need to build. Frequently. Quickly. So this is where Norbert Thiebaud has a story to tell:
“Yes, my efforts are aimed at making the build process fast and reliable, to give good reliable ‘tinderboxes’ with fast turn-around and useful feedback, so that in turn other developers can have feedback on their work for platforms they do not have access too, and QA can have builds more regularly and more frequently so they can test early…”
The latest buzz word for that is ‘continuous integration’. Code is reviewed and committed quickly: ideally as soon as possible. So then you also need quick feedback. The ‘tinderboxes’ Norbert tells about are machines that produce builds automatically, on all kind of platforms. Then there is a ‘tinderbox-server’, that reports about the status and builds, on a daily basis.
Norbert again: “This means that I do punctual fixing to try to keep my tinderboxes green :-), i.e. they work properly, so that the server shows a green “OK” sign. We are making great progress with tinderboxes. In this month of December, we are at a rate of 100+ builds a day. Back in April, that was only about 30!”
Lionel Elie Mamane, who will talk later about Base, also contributed in the field of building: “In my early days of getting started building LibreOffice, I stumbled upon a few things that annoyed me in the config/build system, so I fixed them.
“One annoyance was that there was a mysql-connector file that would be downloaded after configure finished, but yet configure failed when the file was not there. A catch-22 🙂 and now that I fixed that, there is a smoother ‘first build’ experience for newcomers.
“Other small things involved stopping the unnecessary creation of many symlinks (so giving a speed improvement here), and enabling colours in the build output for 256 colours, instead of the the old standard 16. This makes development easier, as compilation errors stand out in colour on the screen.”
Proper release building
Builds that are to be released must of course must be good ones. Petr Mladek tell us how this works: “Most of my work is related to producing all official builds, so code wise that means that I fixed build problems. And of course a lot more build related stuff. Since there was one build almost every week, I spent a lot of time with it. Beside that I helped to merge useful scripts from the old build repository. They help package maintainers to provide LO for different Linux distributions. There were many more people helping with this.”
Since builds are also used by QA volunteers for testing, special work was done for that too. “One of the items was fixing Linux packages, so that the different 3.x releases can be installed in parallel. It is useful especially for testers but also for normal users. I also added more precise version information, e.g. beta2, to the the ‘about’ dialog. It should help testers and users to better describe the installed application and provide better bug reports.”
Easy-hacks as a good starter
Now, some words from Olivier Hallot, one of the founding members of The Document Foundation: “LibreOffice code was a challenge for me since the OOo days. I succeeded in compiling it, and the next step was naturally to try one of the easy-hacks suggested by the developers. I found these easy-hacks the best way to get knowledgeable in C++ coding, and I started to fix some UI issues I found in my language. From a simple hobby to a more serious job, now I am involved into the enhancement of LibreOffice. Plenty of fun times!”
Cleaning up: for improving and easy developing
Easy developing .. well, as easy as possible! Tor Lillqvist is one of the developers who worked on that: “I cleaned out many obsolete bits and pieces. This makes it easier to start developing, there is less obsolete or irrelevant stuff to waste time looking at.”
Part of the work Tor does is related to enabling cross-compilation:
“Cross-compilation makes it possible to develop on a fast machine for slower machines, or for machines not running a desktop operating system at all. So now on Linux you can produce an executable for Windows, but not an installer yet. The Lanedo people are working on this.”
Though not directly related to this clean/improvement interview, Tor also wants to add something different: “Yes, for iOS and Android the compilation part is finished too, just a few days ago. But be careful: in no way does that mean there is a version already running on those devices. Just that people interested in working on the UI side now have a solid base to work upon.”
Lionel Elie Mamane also did some general code cleanups:
“I removed unnecessary const casts, unused variables, … This makes the code more maintainable, easier to understand, etc. Const casts are ‘holes’ drilled through a safety feature of C++! So removing them when they serve no purpose helps to catch future programming errors.”
A special cleanup case was the old OpenOffice <-> PostgreSQL driver. “That was ‘bitrotten’ as we say. It only worked up to version 3.2 .. So I reworked it: integrated the native LibreOffice <-> PostgreSQL driver into LibreOffice proper, enhanced it, ported it to the latest LibreOffice version. Lots of advantages for PostgreSQL access obviously.”
Code readability
If you want to make it easy for part-time developers, students, beginners and so forth to work on the code, then good readability of the code is very helpful. There are many examples. Olivier tells about a easy hack that aims to replace the test for strings inside the code: “Previously, to test when a string is empty, you had to get the length of the string. If it is zero, the string was empty. Recently, a new method isEmpty() was written for the same purpose. The job is then to replace getLength() by isEmpty() in all the code: a very laborious task. But the end result of this re-factoring is much better code readability.”
What can users see ?
Working with RTF documents gets better
While others work on general code clean up, the work of Miklos Vanja with regard to cleaning/replacing is strongly focussed in one area. Miklos:
“During the last two summers I have been working on the Writer RTF filters. Both the export and the import filters were old code, with known design issues. So it was time to redo and create new ones. Export was new in 3.3, import will be new in 3.5. Now that makes it possible too to add features in our RTF which have been missing for a long time, such as nested table support, which was introduced by Word 2000 in RTF.”
Miklos always welcomes example documents which are not yet fully handled by the new filters, so that the import can be further improved.
Calc
Improved testing, especially in Calc, is also worth a note. Markus Mohrard is working there: “One of the areas that I have been active in is automated testing work. This really makes the work of developers easier, and reduces the risk of introducing bugs in new and changed functions. Our Calc filters-tests are a particularly nice way to discover bugs quite early. They showed around 15 really nasty Calc bugs, and at least two older bugs in LibreOffice core. From the bug number we see that these are mostly newer bugs that might not yet have been addressed in OOo, and some are our own bugs.”
Markus points out these are new tests, that are fast and reliable, and are run during most developers’ compilation flow – so we can be sure: if it compiled, it will not have these regressions. He stresses that it is not only important, but also really easy, to extend the tests!
“What I did was to download all ods, xls and xlsx files from several bugzilla instances and used this filters-test concept to check if any of these files crash Calc during import, or during the initial calculation of the content. This showed another set of bugs that Kohei, Eike and I fixed before we branched 3.5 off.
“More than 4,000 documents were checked with this approach, which has already significantly improved 3.5.0.”
Another developer: “I removed some unused code and fixed bugs, mainly some that were already introduced in 3.4, and some in master that went unnoticed, or indeed were reported.”. This is from Eike Rathke.
Speeding up
Eike Rathke is one of the long established developers we know from Sun/OpenOffice.org. He starts off by talking about his vacation:
“Summer was so poor in July/August that I started to work on LibreOffice 😉 I joined RedHat in October, the Monday right after the LibreOffice conference. One of the things that I reworked then, was the class ‘Date, Time and DateTime’. In the old code, the system time was obtained every time during construction. This is unnecessary just to declare a variable. Together with related checking and updating, this resulted in many many unnecessary system calls, which are now not happening any more in 130 out of approximately 350 occurrences. “I expect to have gotten rid of a gazillion of calls to localtime with this change 🙂 Sorry, no real numbers on that.
“Of course I also fixed a lot more code, reported and unreported bugs, the work that “Moggi” Markus Mohrhard has talked about. And I merged some fixes from CWSs pending from (A)OO(o) still under LGPL, and applied/pushed patches. I also helped Moggi improve the Calc named ranges/expression handling, especially with sheet-local names and copy & paste behaviour. ”
Base
Moving on to Base, Lionel has a lot to tell:
“Overall, I’d say I focus on making Base (with scripting) usable again, because I want to use it at my daily job, to replace the Microsoft Access-based business-specific programs I developed in the past. And it was quite broken in early 3.4. Further I fixed some user-visible bugs, e.g.: margins in reports; better, more widely supported, syntax for reporting based on a query + sort; fixed several crashes, fixed PDF-export.
“Maybe most important of all is that I re-enabled ADO (ActiveX Data Objects) on Windows; yet another “common API” for access to SQL databases.” He also made enhancements to passwords, metadata, queries, joins:
“With my work in LibreOffice mostly I ‘scratch my itch’, and I take care of bugs and features where I feel uniquely interested and/or competent: database stuff!”
Lionel stresses that the LibreOffice community has been exceptionally welcoming and quick about recognising his efforts.
[Let me (reporter) remark that it looks a nice idea to have a post somewhere with little more details on Lionel’s work.]
Various easy hack-UI improvements
Olivier Hallot was glad to spend time on several easy hacks, resulting in better usability, interface etc.:
“One hack is about improving the extension manager dialog. Now it allows the user to filter the installed extensions, de-cluttering the dialog and easing the search for an installed extension. Another simple one is adding the command ‘Protect Sheet’ to the sheet guides context menu. I also added 8 new symbols to LibreOffice Math, used in game theory equations. The demand came from a college math professor.”
One of the interesting parts of LibreOffice of course is the localisation. Sometimes that results in strings that are so much longer then the English ones, that the texts don’t fit .. Olivier: “Therefore I made several adjustment in the dialog boxes, to accommodate non-English strings, which are a bit longer and were truncated in the UI.” Another example of improved UI readability.
So, what a Christmas present! And this is only a small snapshot from a few of the hackers we managed to drag away from bug-fixing the 3.5.0 betas – there have been many more, more visible improvements – you can see some in the 3.5 wiki page