Stuff Michael Meeks is doing

This is my (in)activity log. You might like to visit Collabora Productivity a subsidiary of Collabora focusing on LibreOffice support and services for whom I work. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here. Failing that, there are all manner of interesting things to read on the LibreOffice Planet news feed.

Older items: 2021: ( J F M A M J J A S O N D ), 2019, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


2014-12-31: Wednesday

2014-12-30: Tuesday

2014-12-29: Monday

2014-12-28: Sunday

2014-12-27: Saturday

2014-12-26: Friday

2014-12-25: Thursday

2014-12-24: Wednesday

2014-12-23: Tuesday

2014-12-22: Monday

2014-12-21: Sunday

2014-12-20: Saturday

2014-12-19: Friday

2014-12-18: Thursday

2014-12-17: Wednesday

2014-12-16: Tuesday

2014-12-15: Monday

2014-12-14: Sunday

2014-12-13: Saturday

2014-12-12: Friday

2014-12-11: Thursday

2014-12-10: Wednesday

2014-12-09: Tuesday

2014-12-08: Monday

2014-12-07: Sunday

2014-12-06: Saturday

2014-12-05: Friday

2014-12-04: Thursday

2014-12-03: Wednesday

2014-12-02: Tuesday

2014-12-01: Monday

2014-11-30: Sunday

2014-11-29: Saturday

2014-11-28: Friday

2014-11-27: Thursday

2014-11-26: Wednesday

2014-11-25: Tuesday

2014-11-24: Monday

2014-11-23: Sunday

2014-11-22: Saturday

2014-11-21: Friday

2014-11-20: Thursday

2014-11-19: Wednesday

2014-11-18: Tuesday

2014-11-17: Monday

2014-11-16: Sunday

2014-11-15: Saturday

2014-11-14: Friday

2014-11-13: Thursday

2014-11-12: Wednesday

2014-11-11: Tuesday

OpenGL rendering for LibreOffice 4.4

Many areas of LibreOffice have been hugely improved in recent times, from the general cleanup of the code, to the huge VCL / UI layout re-work touching all of our dialogs, the significant re-work of Calc's internals - many areas of the code have had big improvements. One area that has however sadly fallen behind is the Visual Class Libraries (VCL) rendering model - that is used to draw nearly everything in the document, and chrome around it.

Open GL - as-is

OpenGL from the Khronos Group is, of course, the premier cross-platform rendering API for hardware acceleration in the modern world, with implementations from iOS and Android to Windows, Linux & Mac. We have started to use OpenGL in LibreOffice in several places, but unfortunately OpenGL has some pretty unfortunate all-or-nothing type decisions in its platform implementation. What does that mean ? Take for example our infamous Collada duck:

It is a duck
Notice the grey background that surrounds this duck, and unusual sizing handles. This is caused by this all-or-nothing curse: whereby we cannot have a duck 'element' inside a presentation, suitably happily animated - without either having a grey window nailed onto the screen (as is familiar from accelerated video windows), or without taking a major performance hit. The root problem here is that we cannot possibly mix Windows/GDI rendering with OpenGL rendering.

To fix this we need to move LibreOffice rendering into the modern world of hardware accelerated / OpenGL graphics. By rendering all the normal, 2D work into an OpenGL context, we can embed rich, 3D visualisations and data seamlessly into the suite with good performance.

Faster, higher quality rendering

The graphics compute units in modern hardware GPUs are great at rendering (as well as calculating complex spreadsheets). They work in parallel to the CPU, thus (effectively) asynchronously off-loading lots of work from the CPU which can get on with all the heavy lifting to layout your documents.

VCL in contrast, has had extremely variable performance. This is extremely noticeable on mobile devices like Android - where VCL has had to use pure basebmp / CPU rendering on some already under-powered CPU hardware. Meanwhile the powerful GPU cores in your phone/tablet have been idling. By using OpenGL we can ensure that each compute unit is doing the right thing and make optimum use of the available power.

Image scaling is another area where we currently suffer; with several open bugs - first one complains about performance, and then when you lower rendering quality to get performance, another bug complains about rendering quality. Doing high quality image interpolation of large images takes time, even when threaded. People love to whack large, high-DPI images into their documents and presentations. By moving all of the image interpolation work to the GPU we should be able to have our cake: pretty scaled images, and also eat it quickly: with fast rendering.

Another area that is currently slow is gradient rendering; with current VCL implementations, most gradients that you see are decomposed into innumerable smaller polygons by VCL and then many hundreds of these are rendered. This can bring a significant performance penalty. Thanks to Chris Sherlock we now have the ability to render arbitrary gradients in the platform / OpenGL backend. This makes a lot of sense since rendering gradients is something that can be done almost for free by a GPU - lovingly shading each pixel at incredible speed.

VCL / Structural issues

As the Linux world moves to Wayland, LibreOffice will need to adapt. In particular the option of client-side rendering in software (as used in our current gtk3 port) is not incredibly attractive - that suffers from a number of existing rendering problems, as well as being very substantially slower. By moving straight to an OpenGL solution, we should be able to have reasonably optimal Wayland rendering too.

One other problem plagues VCL rendering however; and that is 'immediate' rendering. LibreOffice renders in one of two ways - either immediately: so when you press an 'A' it tries to nail the pixels for 'A' immediately to the screen; or - a very deferred idle rendering which happens a hard-coded 35ms later. This situation is really non-ideal for modern rendering where we want to ensure the scene is perfect before showing it on-screen. However, this is not something that we can fix immediately. Faster deferred rendering will miss 4.4 - the problems are too wide-spread. Having said that, some great work has been done by Jennifer Liebel and Tobias Madl from the Limux team (Munich) - who are implementing a new way for 'idle' tasks - such as re-drawing invalidated rectangles to be run immediately with prioritisation instead of hoping that various combinations of timeouts: 35ms, 50ms etc. arrive in the right order. This should form a great foundation for us to remove immediate rendering in favour of idle rendering without a performance impact in subsequent releases. Thanks also to Kendy (Collabora) for finding and nailing a nasty Windows timer issue; using high-resolution Timer Queues to avoid Windows' (unbelievable) Timers which cannot sleep for less than 10ms.

What we're doing

The new OpenGL rendering code provides a VCL back-end implementation that can be used to render all VCL Windows' content via shared code on all platforms, poke in vcl/opengl for that. Of course, there is also a certain amount of per-platform setup and context management work that has to be done for each platform as well, but the great bulk of the code is fully shared. Markus has also re-factored to help split the Native Widget framework (used for platform theming) and the Text APIs (which are also different per-platform) from the stock GL rendering code.

The new OpenGL backend, thus allows all application rendering to happen to the same OpenGL context. This allows us to avoid a dichotomoy of rendering with GDI or X11 on windows, and then needing to box all 3D / OpenGL content into its own window. This should allow seamless integration of 3D content, as well as giving much better performance particularly on mobile platforms.

Testing VCL implementations

One area that VCL has not been ideal is the lack of a well written test / demo application. This is somewhat ironic since the LibreOffice code-base stated off decades ago as the demo app for the VCL toolkit. Over the last week, we've done a little expansion and started to implement something that aims at exercising all of the relevant backend / VCL API in an easy to extend fashion.

Naturally, the OpenGL code is not for everyone - neither now, or for the forseable future. Many OpenGL implementations have debilitating bugs, despite using only a small and simple sub-set of OpenGL features : we believe that will need to black-list these. Similarly, we will want to white-list newer and more stable drivers, but of course users will be able to choose between legacy and OpenGL rendering too.

What it looks like

So - when you put all of that together; it is advancing rapidly. Markus just checked some code into master which shows some of the VCL primitives that we can render already:

VCL demo - coming along

Ongoing work

You can play with the work on master; clearly LibreOffice is not rendering perfectly with this yet - that goes without saying; and help is much appreciated in the lead-up to LibreOffice 4.4; we love to work with other people.

Credits

Thanks to Markus Mohrhard (Collabora), Louis-Francis Ratté-Boulianne (Collabora), Ptyl Dragon (CloudOn), Chris Sherlock, along with more future / pending work in-progress from Michael Jaumann working on OpenGL canvas and Stefan Weiberg on OGL Transitions both mentored by Thorsten Behrens (SUSE).

2014-11-10: Monday

2014-11-09: Sunday

2014-11-08: Saturday

2014-11-07: Friday

2014-11-06: Thursday

2014-11-05: Wednesday

2014-11-04: Tuesday

2014-11-03: Monday

2014-11-02: Sunday

2014-11-01: Saturday

2014-10-31: Friday

2014-10-30: Thursday

2014-10-29: Wednesday

2014-10-28: Tuesday

2014-10-27: Monday

2014-10-26: Sunday

2014-10-25: Saturday

2014-10-24: Friday

2014-10-23: Thursday

2014-10-22: Wednesday

2014-10-21: Tuesday

2014-10-20: Monday

2014-10-19: Sunday

2014-10-18: Saturday

2014-10-17: Friday

2014-10-16: Thursday

2014-10-15: Wednesday

2014-10-14: Tuesday

2014-10-13: Monday

2014-10-12: Sunday

2014-10-11: Saturday

2014-10-10: Friday

2014-10-09: Thursday

2014-10-08: Wednesday

2014-10-07: Tuesday

2014-10-06: Monday

2014-10-05: Sunday

2014-10-04: Saturday

2014-10-03: Friday

2014-10-02: Thursday

2014-10-01: Wednesday

2014-09-30: Tuesday

2014-09-29: Monday

2014-09-28: Sunday

2014-09-27: Saturday

2014-09-26: Friday

2014-09-25: Thursday

2014-09-24: Wednesday

2014-09-23: Tuesday

2014-09-22: Monday

2014-09-21: Sunday

2014-09-20: Saturday

2014-09-19: Friday

2014-09-18: Thursday

2014-09-17: Wednesday

2014-09-16: Tuesday

2014-09-15: Monday

2014-09-14: Sunday

2014-09-13: Saturday

2014-09-12: Friday

2014-09-11: Thursday

2014-09-10: Wednesday

2014-09-09: Tuesday

2014-09-08: Monday

2014-09-07: Sunday

2014-09-06: Saturday

2014-09-05: Friday

2014-09-04: Thursday

2014-09-03: Wednesday

2014-09-02: Tuesday

2014-09-01: Monday

2014-08-31: Sunday

2014-08-30: Saturday

2014-08-29: Friday

2014-08-28: Thursday

2014-08-27: Wednesday

2014-08-26: Tuesday

2014-08-25: Monday

2014-08-24: Sunday

2014-08-23: Saturday

2014-08-22: Friday

2014-08-21: Thursday

2014-08-20: Wednesday

2014-08-19: Tuesday

2014-08-18: Monday

2014-08-17: Sunday

2014-08-16: Saturday

2014-08-15: Friday

2014-08-14: Thursday

2014-08-13: Wednesday

2014-08-12: Tuesday

2014-08-11: Monday

2014-08-10: Sunday

2014-08-09: Saturday

2014-08-08: Friday

2014-08-07: Thursday

2014-08-06: Wednesday

2014-08-05: Tuesday

2014-08-04: Monday

2014-08-03: Sunday

2014-08-02: Saturday

2014-08-01: Friday

2014-07-31: Thursday

2014-07-30: Wednesday

2014-07-29: Tuesday

LibreOffice under the hood: progress to 4.3.0

Today we release LibreOffice 4.3.0, packed with a load of new features for people to enjoy - you can read and enjoy all the great news about the user visible features from so many hardy developers, but there are of course also some contributors whose work is primarily behind the scenes in places that are not so easy to see. These are of course still vitally important to the project. It can be hard to extract those from the over fourteen thousand commits since LibreOffice 4.2 was branched, so let me expand:

User Interface Dialog / Layout

The UI migration to Glade based layout of VCL widgets is finally approaching the home straight; more than two hundred dialogs were converted this release; leaving the final dialogs rather hard to find - help appreciated. Many thanks to Caolán McNamara (Red Hat) - for his incredible work here, and also Szymon Kłos, Michal Siedlaczek, Olivier Hallot (EDX), Andras Timar (Collabora), Jan Holesovsky (Collabora), Katarina Behrens, Thomas Arnhold, Maxim Monastirsky, Manal Alhassoun, Palenik Mihály, and many others ... Thanks also to our translators who helped in the migration of strings.

Graph of progress in UI layout conversion

If you'd like to get involved in driving this to 100%, checkout Caolan's howto and his great blog: 99 to go update (now only 65) illustrated by this:

Build improvements

We've improved a lot this cycle in terms of buildability, and ease of comprehension - important for new contributors.

Visual Studio support

Not only did Jesus Corrius add initial support for Visual Studio 2013, but we had a major win from Honza Havlíček who (building on Bjoern Michaelsen (Canonical)'s similar KDevelop work) implemented building a Visual Studio project file - allowing much improved build / debugging support video or just: make vs2012-ide-integration.

OpenGL as a run-time dependency

In the past when we needed an OpenGL code-path we would link a separate shared library to OpenGL and then dynamically load that component - as for the OpenGL slideshow. In 4.3 we unified all of our OpenGL code to use glew and now have a central VCL API for initializing and linking in OpenGL, making it much easier to use in future. Another benefit of using glew is the ability to check for certain extensions at run-time dynamically to better adapt to your platform's capabilities rather than having to work vs. a baseline.

Pre-compiled-headers / PCH updates

Thomas Arhnold discovered that our pch files (used for accelerating windows building) had bit-rotted, and did a fine cleanup sweep across them. That significantly reduced build time for a number of modules.

Graph of compile-time speedup from improving pre-compiled headers

Mobile code-size reduction

A lot of work was put into LibreOffice 4.3 to allow us to shrink the code to fit a mobile footprint nicely. Thanks to Matus Kukan (Collabora) for splitting a large number of UNO components into individual factory functions - to allow the linker to garbage collect un-used components. Matus also created a python script solenv/bin/native-code.py to share the building of lists of components to statically link in for various combinations of functionality. Tor Lillqvist (Collabora) did some re-work on ICU to package the rather large data tables as a file instead of code. Vincent Saunders (Collabora) worked away to improve dwarfprofile to identify larger pieces of object file and where they came from. Jan Holesovsky de-coupled lots of accessibility code, and removed lots of static variables dragging in un-needed code. Miklos Vajna turned OOXML custom shape preset definitions (oox::drawingml::CustomShapeProperties::PresetsMap) from generated code to generated data: that allowed removal of 50k lines of code. Thanks to Tsahi Glik / CloudOn for funding this work.

Code quality work

There has been a lot of work on code quality and improving the maintainability and cleanliness of the code. Another 75 or so commits to fix cppcheck errors are thanks to Julien Nabet, along with the huge scad of daily commits to build without any compile warnings -Werror -Wall -Wextra on every platform with thanks primarily to Tor Lillqvist (Collabora), Caolán McNamara (Red Hat), and Thomas Arnhold.

Assert usage

Another tool that developers use to ensure they do not introduce new bugs is assertions; historically the OOo code base has had custom assertion facilities that can easily be ignored, and so most developers did just that; thanks to Stephan Bergmann (Red Hat), we have started to use the standard assert() macros in LibreOffice, which have the important advantage that they actually abort the program: if an assertion fails, developers see a crash that is rather harder to ignore than some text printed on the terminal. Thanks to all who asserted the truth.

Graph of number of run-time assertions
Rocking Coverity

We have been chewing through the huge amount of analysis from the Coverity Scan, well - in particular Caolán McNamara (Red Hat) has done an awesome job here; his blog on that is typically modest.

We now have a defect density of 0.08 - meaning 8x bugs in every 100,000 lines of code found by static checking. This compares rather favourably with the average open source project of this size which has 65 per 100,000 lines. Perhaps the most useful thing here is Coverity's report on new issues - many of which are rather more serious than the last few, lowest priority un-triaged reports.

This was achieved by 2679 commits, 88% of them from Caolán, and then Norbert Thiebaud, Miklos Vajna (Collabora), Noel Grandin, Stephan Bergmann (RedHat), Chris Sherlock, David Tardon (RedHat), Thomas Arnhold, Steve Yin (IBM), Kohei Yoshida (Collabora), Jan Holesovsky (Collabora), Eike Rathke (RedHat), Markus Mohrhard (Collabora) and Julien Nabet

Import and now export testing

Markus Mohrhard's great import/export crash testing has been expanded to 55,000+ problem/bug documents, now covering the PDF importer, and our crash and validation problem counts continue to drop. We import each of these documents, and then export them into each export format that we support; eg. an ODS would be re-exported as ODS, XLS, XLSX, etc. Markus also re-wrote and simplified the test script in python to make it simpler; however we routinely suffer from this test (running for 5 days and consuming a beefy machine) locking up Linux of several distributons, kernel versions, on both virtual and real hardware; which has a negative impact on usefulness.

Re-factoring big objects

In some cases LibreOffice has classes that seem to do 'everything' and include the kitchen sink too. Thanks to Valentin Kettner, Michael Stahl (RedHat) and Bjoern Michaelsen (Canonical) for helping to re-factor these. As an example SwDoc (a writer document) now inherits from only nine classes instead of nineteen, and the header file shrunk by more than three hundred lines.

Valgrind fixes

Valgrind continued to be a wonderful tool for finding and isolating leaks, and poor behavior of various bits of code - although normal code-paths are by now rather valgrind clean. Dave Richards from Largo very kindly donated us some CPU time on his new 80x CPU Linux machine to burn it in. We used that to run Markus' import/export testing under valgrind, and found and fixed a number of issues. valgrind logs here. We would be most happy to help others with their boxes in need of load testing.

Address / Leak Sanitizer

There are some great new ways of doing (compile time) code sanitisation, and thanks to Stephan Bergmann (RedHat) we're using them enthusiastically -fsanitize is available for Clang and gcc 4.9. It lets us do memory checking (like valgrind) but with visibility into stack corruption, and to do that very significantly faster. Some details on -fsanitize for libreoffice are available. Lots of leaks and badness have been fixed using the tool, thanks too to Markus Mohrhard, and Caolan McNamara.

Unit testing

We also built and executed more unit tests with LibreOffice 4.3 to avoid regressions as we change the code. Grepping for CPPUNIT_TEST() and CPPUNIT_ASSERT as last time we continued the trend of growth here:

Graph of number of unit tests and assertions
Our ideal is that every bug that is fixed gets a unit test to stop it ever recurring. With 1100 commits, and over eighty committers to the unit tests in 4.3 it is hard to list everyone involved here, apologies for that; what follows is a sorted list of those with over 20x commits to the qa/ directories: Miklos Vajna (Collabora), Kohei Yoshida (Collabora), Caolán McNamara (RedHat), Stephan Bergmann (RedHat), Jacobo Aragunde Pérez (Igalia), Tomaž Vajngerl (Collabora), Markus Mohrhard (Collabora), Zolnai Tamás (Collabora), Tor Lillqvist (Collabora), Michael Stahl (RedHat), Alexander Wilms

SAL_OVERRIDE and more

Traditionally C++ has allowed significant ambiguity in overriding methods, allowing the 'virtual' keyword to be ommitted in overrides, and also allowing accidentally polymorphic overrides. To prepare for the new C++ standard here we've annotated all of our virtual methods that are overridden in sub-classes with the SAL_OVERRIDE macro, to ensure that we are building our vtables correctly. Many thanks to Noel Grandin, and Stephan Bergmann (RedHat) for building a clang plugin to help to build annotation here with another to verify that the result stays consistent. That fixed several long-standing bugs. As a bonus when you read the code it is much easier to find the base virtual method declaration: it's the one that is not marked with SAL_OVERRIDE.

QA / bugzilla

This release the QA team has grown, and done some amazing work both triaging bugs, and also closing them, getting us back well under the totemic one thousand un-triaged bug barrier. Currently ~750 un-confirmed which is the lowest in over two years. Thanks to everyone for their great work there, sadly it is rather hard to extract credits for confirming bugs, but the respective hero list overlaps with the non-developer / top closers listed below.

We also had one of our best bug-hunting weekends ever around 4.3 see Joel Madero's write-up. The QA team are also doing excellent job with our bibisect git repositories to isolate regressions to small blocks of commits - which makes life significantly easier for developers.

One metric we watch in the ESC call is who is in the top ten in the freedesktop Weekly bug summary. Here is a list of the top twenty people who have appeared most frequently in the weekly list of top ten bug closers in order of frequency of appearance: Jorendc, Kohei Yoshida (Collabora), Maxim Monastirsky, tommy27, Joel Madero, Caolán McNamara (RedHat), Foss, Jay Philips, m.a.riosv, Julien Nabet, Sophie Gautier (TDF), Cor Nouws, Michael Stahl (RedHat), Jean-Baptiste Faure, Andras Timar (Collabora), Adolfo Jayme, ign_christian, Markus Mohrhard (Collabora), Eike Rathke (RedHat), Urmas. And thanks to the many others that helped to close so many bugs for this release.

Bjoern Michaelsen (Canonical) also write up a nice taxonomy of our twenty five thousand reported bugs so far, and provided the data for this nice breakdown:

Graph of bug stats over the development of 4.3

Code cleanup

Code that is dirty should be cleaned up - so we did a lot of that.

The final death of UniString

While we killed our last tools/ string class in 4.2 and switched to clean, uniform OUStrings everywhere - we were still using some 16bit quantities to describe text offsets elsewhere. Thanks to Caolán McNamara (Red Hat) for finally enabling writer to have >64k paragraphs - a long requested feature by a certain type of user, see the related blogpost.

VCL code / structure cleanup

The Visual Class Libraries - the LibreOffice native toolkit has not been given the love it deserves in recent years. Many thanks to Chris Sherlock for several hundred commits - starting to cleanup VCL. That involves lots of good things - giving the code a more logical structure so it is easy to find methods; systematically writing doxygen documentation for API methods, ensuring that API methods have sensible, descriptive names and starting to unwind some poor legacy design decisions; much appreciated.

Ongoing German Comment redux

We continued to make some progress on translating our last lingering German comments across the codebase to good, crisp technical English. Many thanks to Luc Castermans, Sven Wehner, Christian M. Heller, Philipp Weissenbacher, Stefan Ring, Philipp Riemer, Tobias Mueller, Chris Sherlock, Alexander Wilms and others. We also reduced the number of false positives and accelerated the bin/find-german-comments tool in this cycle.

Graph of remaining lines of German comment to translate
Automated code re-factoring using Clang

One hero of code cleaning is Noel Grandin who is constantly improving the code in many ways; eg. writing out un-necessary duplicate code to use standard wrappers such as SimpleReferenceObject. Noel has been heavily involved in Clang plugins to re-write a lot of our error prone binary file format / stream overrides pStream >> nVar seems like a great idea until you realise that an unexpected change to the type of nVar far away tweaks the file format. These operators are now all re-written to explicit ReadFloat type methods enhancing the robustness of the code to changes. Noel also created plugins to inline simple member functions, detect inefficient passing of uno::Sequence, and OUString. Stephan Bergmann (RedHat) also wrote a number of advanced linting tools, checks for de-referencing NULL pointers, quickly catching inlining problems on Linux that cause most grief on Windows, and re-writing un-necessary uses of sal_Bool to bool. Stephan also wrote a plugin to find unused functions and unused functions in templates, as well as warning on illicit conversions of literal to bool e.g. if (n == KIND_FOO || KIND_BAR). All of this improves the readability, consistency, reliability and in some cases performance of the code.

Improving lifecycle

Takeshi Abe invested lots of time this cycle in improving our often unhelpful object lifecycle. Using smart pointers not only makes the code more readable and often shorter, but also exception safe which is very useful.

DocTok cleanup

This cleanup saved nearly 80k lines of code and make the codebase much simpler to understand thanks to Miklos Vajna (Collabora) you can see the before & after pictures in his blog.

Holding the line on performance

Performance is one of those hard things to keep solid. It has an alarming habit of bit-rotting when your back is turned. That's why Matus Kukan (Collabora) has built a test machine that routinely builds LibreOffice and runs a suite of document loads, conversions etc. under callgrind. Using callgrind's simulated CPU has the beautiful property of ensuring repeatable behaviour, and thus making any small reduction or improvement in performance noticeable and fixable. It is easy to see that in a graph - admire the crisp flatness of the graph between significant events. The X axis is time (annotating the axis with git hashes is not so photogenic).

Graph of various documents performance

Often we only check performance just before a release, its interesting to see here the big orange hump from a performance fragility found and fixed as a direct result of these tests. Raw callgrind data is made available for trivial examination of the latest traces along with a flat ODS of the previous runs.

Getting involved

I hope you get the idea that more developers continue to find a home at LibreOffice and work together to complete some rather significant work both under the hood, and also on the surface. If you want to get involved there are plenty of great people to meet and work alongside. As you can see individuals make a huge impact to the diversity of LibreOffice (the colour legends on the right should be read left to right, top to bottom, which maps to top down in the chart):

Graph showing individual code committers per month

And also in terms of diversity of code commits, we love to see the unaffiliated volunteers contribution by volume, though clearly the volume and balance changes with the season, release cycle, and volunteers vacation / business plans:

Graph of number of commits per month by affiliation

Naturally we maintain a list of small, bite-sized tasks which you can use to get involved at our Easy Hacks page, with simple build / setup instructions. It is extremely easy to build LibreOffice, each easy-hack should have code pointers and be a nicely self contained task that is easy to solve. In addition some of them are really nice-to-have features or performance improvements. Please do consider getting stuck in with something.

Graph of progress closing easy hacks over time

Another thing that really helps is running pre-release builds and reporting bugs just grab and install a pre-release and you're ready to contribute alongside the rest of the development team.

Conclusion

LibreOffice 4.3 is the next in a series of releases that incrementally improve not only the features, but also the foundation of the Free Software office suite. Please be patient, it is just the first in a long series of monthly 4.3.x releases which will bring a stream of bug fixes and quality improvements over the next months as we start working in earnest on LibreOffice 4.4.

I hope you enjoy LibreOffice 4.3.0, thanks for reading, and thank you for supporting LibreOffice.

Raw data for many of the above graphs is available.

A French translation of much of this is available.

2014-07-28: Monday

2014-07-27: Sunday

2014-07-26: Saturday

2014-07-25: Friday

2014-07-24: Thursday

2014-07-23: Wednesday

2014-07-22: Tuesday

2014-07-21: Monday

2014-07-20: Sunday

2014-07-19: Saturday

2014-07-18: Friday

2014-07-17: Thursday

2014-07-16: Wednesday

2014-07-15: Tuesday

2014-07-14: Monday

2014-07-13: Sunday

2014-07-12: Saturday

2014-07-11: Friday

2014-07-10: Thursday

2014-07-09: Wednesday

2014-07-08: Tuesday

2014-07-07: Monday

2014-07-06: Sunday

2014-07-05: Saturday

2014-07-04: Friday

2014-07-03: Thursday

2014-07-02: Wednesday

2014-07-01: Tuesday

2014-06-30: Monday

2014-06-29: Sunday

2014-06-28: Saturday

2014-06-27: Friday

2014-06-26: Thursday

OOXML SDK project opened up

It is great to see Microsoft's OOXML SDK project open sourced today; clearly while Collabora Productivity backs ODF as the preferred document format - we're pleased to see more FOSS appear out there in this space.

So what is it ? - Microsoft just open-source'd just under nine thousand lines of C#, with around a hundred thousand lines of code generated from the OOXML schemas. It is under an Apache 2.0 license, which seems reasonable (though I'd prefer a copy-left).

Where is it ? - The OOXML SDK is hosted at github - a great place to get distributed, non-hierarchical, peer based community involvement. Unfortunately the free-flowing goodness of github has an un-necessary roadblock that goes with it, hopefully one day people generally will learn.

Will LibreOffice use it ? (no) - Well mostly no; we have our own internal parsing mechanisms written in C++, this C# code targets the Common Language Runtime which has a different scope. We also have an efficient, and tuned internal document model that doesn't match even our ODF XML format - for example repeated formula are stored in groups to assist with OpenCL calculations so even if languages matched, switching to another representation would make little sense.

Will LibreOffice use it ? (yes) Having said that the OOXML SDK includes a rather nice validator. In recent years Markus, a Collabora engineer, has been developing an awesome torture test that loads fifty-thousand documents and re-exports them to umpteen formats consuming a big machine for around five days. One of those export formats is OOXML, after export we like to validate those to try to avoid interoperability regressions. New and improved validation can only help there, particularly the ability to go beyond a simple schema validation to check extra constraints. OOXML / Strict validation would also be lovely. Naturally we need Mono support (which I hear is coming) since all our headless automated tests run under Linux. We also currently allow configuration with --with-export-validation that validates the output from all of the unit tests that are run during compilation - it would be useful to have a command-line tool for this too.

What about ODF ? - ODF still rocks just as much of course. One feature I particularly like is Flat ODF which lets you express an entire document, images and all as a single XML file; in LibreOffice that has comparable performance to zipped ODF.

Is there an ODF equivalent ? - of course ! Generating and parsing ODF or Flat ODF is really pretty simple using any number of platforms and toolkits for ZIP / XML and in-memory DOM models. Then again there is benefit to re-using and adding to semantic sugar around that. In the C# / CLR world you can use AODL, or if Java floats your boat Apache's ODF Toolkit which recently had a new release.

What about validation ? - currently our automated testing tends to use Alex Brown & Cedric Bosdonnat (of SUSE's) nice Office-o-tron which handles both ODF and OOXML, a nice combination to be commended to the OOXML SDK.

Who should I start stoning ? - From my perspective ODF wins the standards beauty contest here hands down, but it's always good to have more developers working in the open and working together. If we have fixes for the SDK I suppose we'll try to contribute them back to github somewhere. Obviously our primary focus is always ODF, as an enabler for the primary goal of a better LibreOffice, and Free Software in every productivity environment. Having said that, we increasingly store and preserve OOXML attributes we have little use for in LibreOffice to re-export in order to ensure high fidelity round-trips. Better validation will be appreciated for that too.

2014-06-25: Wednesday

2014-06-24: Tuesday

2014-06-23: Monday

2014-06-22: Sunday

2014-06-21: Saturday

2014-06-20: Friday

2014-06-19: Thursday

2014-06-18: Wednesday

2014-06-17: Tuesday

2014-06-16: Monday

2014-06-15: Sunday

2014-06-14: Saturday

2014-06-13: Friday

2014-06-12: Thursday

2014-06-11: Wednesday

2014-06-10: Tuesday

2014-06-09: Monday

2014-06-08: Sunday

2014-06-07: Saturday

2014-06-06: Friday

2014-06-05: Thursday

2014-06-04: Wednesday

2014-06-03: Tuesday

2014-06-02: Monday

2014-06-01: Sunday

2014-05-31: Saturday

2014-05-30: Friday

2014-05-29: Thursday

2014-05-28: Wednesday

2014-05-27: Tuesday

2014-05-26: Monday

2014-05-25: Sunday

2014-05-24: Saturday

2014-05-23: Friday

2014-05-22: Thursday

2014-05-21: Wednesday

2014-05-20: Tuesday

2014-05-19: Monday

2014-05-18: Sunday

2014-05-17: Saturday

2014-05-16: Friday

2014-05-15: Thursday

2014-05-14: Wednesday

2014-05-13: Tuesday

2014-05-12: Monday

2014-05-11: Sunday

2014-05-10: Saturday

2014-05-09: Friday

2014-05-08: Thursday

2014-05-07: Wednesday

2014-05-06: Tuesday

2014-05-05: Monday

2014-05-04: Sunday

2014-05-03: Saturday

2014-05-02: Friday

2014-05-01: Thursday

2014-04-30: Wednesday

2014-04-29: Tuesday

2014-04-28: Monday

2014-04-27: Sunday

2014-04-26: Saturday

2014-04-25: Friday

2014-04-24: Thursday

2014-04-23: Wednesday

2014-04-22: Tuesday

2014-04-21: Monday

2014-04-20: Sunday

2014-04-19: Saturday

2014-04-18: Friday

2014-04-17: Thursday

2014-04-16: Wednesday

2014-04-15: Tuesday

2014-04-14: Monday

2014-04-13: Sunday

2014-04-12: Saturday

2014-04-11: Friday

2014-04-10: Thursday

2014-04-09: Wednesday

2014-04-08: Tuesday

2014-04-07: Monday

2014-04-06: Sunday

Mozilla's Extraordinary Situation

Overview

Last night I was appalled and saddened to see that Mozilla's principled decision to do the right thing, and stand up to a savage and vindictive witch hunt, seemingly conducted and cheer-lead both by those employed by Mozilla Corp. and others outside the organisation, had finally worn people down enough to do something that looks horribly illiberal and which seems to betray the very basis of critical protections of freedom of political views. By which I mean accepting Brendan's (apparently principled) resignation. Of course, normally the real reasons behind the scenes are opaque and I've no view or insight into Brendan: his strengths and weaknesses for the role, a great technical CV, industry, leading insight etc. doesn't necessarily make for a great CEO. Quite possibly poor communication around an issue like this is a good enough reason to remove support such that resignation is the only option. However, the communication around the resignation and the new status quo was equally if not more horribly shambolic - lets see how that trend continues. All in all it makes it look like lots of people acted for all the wrong reasons to get a terrible outcome.

Personally I'm a supporter of traditional marrige; but also for reasons of basic justice a supporter of the UK's Civil Partnerships - perhaps a more nuanced view than is possible to express in the profoundly polarized US political system whose aggression seems to significantly infect social discourse; neither do I understand 2008's Prop 8. If your views differ, then my plan is to try to disagree respectfully & charitably.

Much as I admire Matthew Garret & his technical work, his take on the topic

The point is that the community didn't trust Brendan, and Brendan chose to leave rather than do further harm to the community.
leaves out the rather vexed problem of accurately divining what the community wants. I suspect that there was a concerted campaign outside - but more problematically inside Mozilla Corporation to bring the project into disrepute and thus to bring pressure to bear to achieve this objective. There is talk of a 70,000 signature petition - which sounds a lot until you consider a user-base of 450 million. Is it acceptable when sub 0.02% of users sign a petition to act this way ? I suspect it's an unrealistic view that the harm to Mozilla and by extension their great work on the open web is all finished and done with Brendan resigning; at least while an unaddressed injustice is seen, by some, to have been done.

Cowardice ?

Scandal aside a more interesting question to me has been raised:

As a volunteer moderating the Facebook page, it was evident that we had many users complaining and very little supporters. Now that Brendan has resigned, everybody has all of a sudden come out from a shadow. Unexpectedly to say at the least, is that we've got users telling us that we were no longer protecting Freedom of speech and that rights are taken away. Where have these people been hiding?
And it's a good one. Why didn't I speak up for Brendan before ? In my case there were three-fold reasons: first and primarily a lack of time, second a conviction that Mozilla was riding the storm, doing the right thing and that things would die down in time; but there was also a small cowardly fear of knock-on witch-hunting. Last time I discussed anything even tangentially related to this topic I was soundly and (to my view unreasonably) accused of all manner of horrible things. That has rather a chilling effect on the willingness to engage. Furthermore, that dialog is often highly emotive cf. the meritocracy kills hysteria.

Some quotes

Normally when such matters are discussed my perspective is heavily criticized and dismissed as being from a "privileged white male" and thus beyond utterly irrelevant. Perhaps more tellingly, I'm not a Mozillan, and handling the mob is not an easy thing: Mitchell has my profound sympathy. So let me excerpt the following text from two Mozillans self-identifying as homosexuals (neither of whom share Brendan's views), (Planet Mozilla is interesting too) today. In particular I excerpt Things Change, the Mozilla CEO (from K Lars Lohn, first struck out as 'moot' and now removed - checkout the planet for it's last vestiages [Update: now restored but missing the update wrt. threatening] ), those thoughtful quotes, as any, best read in their original context:

Since my involvement long ago I also became comfortable with being gay... I've also come to realize that change, isn't always progressive, and what looks like progress can hide other dangers. Progress is self-validating for the thing labeled progressive, and its too easy to dismiss those that seem to stand in its way but that is no more right than any other form of censorship, ... I've seen recently, too many comments that want to devalue people who stand in the way of progress as exactly the thing that they are trying to fight. LGBT issues were marginalized, and oppressed by society. Oppression is wrong, but don't be too quick to think that marginalized groups can't marginalize others, pushing views aside because they fail to meet socially acceptable criteria, whether that criteria is progress, equality or religion and heteronormativity. We might just all realize that for all someones faults, combining ideas, and not combating them, might just result in a new idea, a new change for all.

and

I am a gay employee of the Mozilla Corporation, and I support my company's decisions regarding the selection of CEO. This doesn't mean that I'm entirely comfortable with the selection, but not because I think Brendan Eich is a threat, but instead because of the public relations repercussions. ... I have friends that hold political opinions that are antithetical to me – I do not exclude them from my life, I embrace my friends. I neither support nor understand their beliefs, but doesn't mean that I throw them away. I cannot condone holding a grudge in perpetuity. To do so would be leaving a wake of enemies behind me whereas I could instead have them as allies beside me where we do agree. ... I say to the larger community calling for the ouster of Brendan Eich, “please don't succumb to the knee jerk reaction.” I did at first, but with some thought, I realize that we need to focus on the future not exact retribution for the past.

Particularly interesting in this latter post is the experience of the witch hunt even against a thoughtful, balanced, gay writer like this, K Lars writes (in bold) To the people that have threatened me about this posting, I can only look at you quizzically, laugh and then walk away.

The Secret Ballot Box as an alternative to mob rule

In the presence of such a difficult situation to unwind it is interesting to examine the Mozilla Foundation's governance - in particular the board that makes these tough calls. In general the idea that a freedom loving organisation should be run by a small (now even smaller), self-appointing board seems extraordinarily problematic from a legitimacy perspective.

It appears that there is a clear pattern of intimidation and harassment of people engaging on one side of this topic. Now, perhaps (as anger seems to build in the other direction cf. input.mozilla.org I hope we don't return to a sadder period of hostility in the other direction, [Update 2014-04-07: input now seems to be a horribly depressing place for all moderates, I'd avoid reading it]) some lose-lose-lose situation where we all end up more polarised would be desparately sad. Either way, the situation is not unexpected - coercive parties of all stripes hate secret ballots so...

My suggestion would be to adopt best-practise, re-use the existing, hopefully representative, meritocratic membership structures inside Mozilla and give those guys a fair (ie. STV) and secret ballot to allow Mozillans to choose those who govern them and to ensure that minority views of whatever kind are also respected and represented. Of course, quite possibly doing that will result in no change, but it will bring unarguable legitimacy to whatever solution eventually comes out of the political sausage machine; that seems to be sadly absent now.

I hope that a newly elected board would have the authority to make it transparently clear that Mozilla's important and valuable mission is rather orthogonal to promoting other unrelated agendas for everyone's sake.

Other links

Other interesting views from Mozillans at least for my future reference are: Tocqueville on the Freedom of Discussion in America, Sad day, Mozilla is not Chick-Fil-A, Recent Events, FAQtechism, Only what unites us, Freedom of speech in the Mozilla Community, Your Ire Is Mis-directed

Update 2014-04-07

Reading some of the more savage, vinctictive, angry and unpleasant anti-Mozilla / anti-Gay feedback more recently on the 'input' site I'm appalled to even appear to be on the same side of the argument. I'm more eager to respect those individuals who expressed civilised concerns about Brendan's appointment than that extreme. Then again, there are quite a few thoughtful more moderate posters who express their concerns well. Some do believe that promoting a position on this is a core part of Mozilla's mission now. Another thoughtful poster writes on speech and consequences.

Having said that, I'm still convinced this is fundamentally a slow-motion crisis of legitimacy, and nothing to do with anyone's rights, I believe it needs fixing in a way that addresses that.

2014-04-05: Saturday

2014-04-04: Friday

2014-04-03: Thursday

2014-04-02: Wednesday

2014-04-01: Tuesday

2014-03-31: Monday

2014-03-30: Sunday

2014-03-29: Saturday

2014-03-28: Friday

2014-03-27: Thursday

2014-03-26: Wednesday

2014-03-25: Tuesday

2014-03-24: Monday

2014-03-23: Sunday

2014-03-22: Saturday

2014-03-21: Friday

2014-03-20: Thursday

2014-03-19: Wednesday

2014-03-18: Tuesday

2014-03-17: Monday

2014-03-16: Sunday

2014-03-15: Saturday

2014-03-14: Friday

2014-03-13: Thursday

2014-03-12: Wednesday

2014-03-11: Tuesday

2014-03-10: Monday

2014-03-09: Sunday

2014-03-08: Saturday

2014-03-07: Friday

2014-03-06: Thursday

2014-03-05: Wednesday

2014-03-04: Tuesday

2014-03-03: Monday

2014-03-02: Sunday

2014-03-01: Saturday

2014-02-28: Friday

2014-02-27: Thursday

2014-02-26: Wednesday

Response to Cabinet Office's 'Sharing or collaborating with government documents'

The UK Government has solicited feedback on its (excellent) proposals. I've published my response here too to make it somewhat more legible.

Preamble

I was profoundly encouraged by the depth of understanding underlying the Cabinet Offices' recommendation to use ODF for the default format for saving UK Government documents, which I support enthusiastically. It can be viewed as HTML here:

Disclosure

Summary

ECMA, TC45, and OpenXML standardisation

Open Standards and avoiding vendor capture

A language analogy

The importance of ODF as a single document standard

Macros expose implementation details

Device and platform choice

Conclusion

2014-02-25: Tuesday

2014-02-24: Monday

2014-02-23: Sunday

2014-02-22: Saturday

2014-02-21: Friday

2014-02-20: Thursday

2014-02-19: Wednesday

2014-02-18: Tuesday

2014-02-17: Monday

2014-02-16: Sunday

2014-02-15: Saturday

2014-02-14: Friday

2014-02-13: Thursday

2014-02-12: Wednesday

2014-02-11: Tuesday

2014-02-10: Monday

2014-02-09: Sunday

2014-02-08: Saturday

2014-02-07: Friday

2014-02-06: Thursday

2014-02-05: Wednesday

2014-02-04: Tuesday

2014-02-03: Monday

2014-02-02: Sunday

2014-02-01: Saturday

2014-01-31: Friday

2014-01-30: Thursday.

LibreOffice progress to 4.2.0

Today we release LibreOffice 4.2.0, packed with a load of new features for people to enjoy - you can read and enjoy all the great news about the user visible features from so many heroic contributors, but there are of course also some contributors whose work is primarily behind the scenes, in places that are not so easy to see - but is still vitally important to the project. It can be hard to extract those from the over twelve thousand commits since LibreOffice 4.1 was branched, so let me expand:

User Interface Dialog / Layout

The UI migration to Glade layout based XML files continues apace with contributions from many individuals, we managed to convert another 280 dialogs in this release, getting us around 70% of the way there. Many thanks to: Caolán McNamara (Red Hat), Manal Alhassoun (KACST), Olivier Hallot (EDX), Faisal M. Al-Otaibi (KACST), Laurent Balland-Poirier, Efe Gürkan Yalaman, Krisztian Pinter, Jan Holesovsky (Collabora), Andras Timar (Collabora), Cao Cuong Ngo, Gergo Mocsi, Katarina Behrens, Abdulmajeed Ahmed (KACST), and Alia Almusaireae (KACST). Thanks also to our translators who helped in the migration of strings.

Graph of progress in UI layout conversion

If you'd like to get involved in driving this to 100%, checkout Caolan's howto and updates.

Build improvements

We've improved a lot this cycle in terms of buildability, and ease of comprehension - important for new contributors.

Much improved compile/run cycle

Six months ago we reported the great news of a pure gnumake build which is faster and sweeter. To compound the goodness for 4.2 we worked hard to ensure that you can compile and then just run LibreOffice without a slow install phase directly after compiling. We build a live, run-able image into instdir/, so:

./autogen.sh
make
cd instdir/program
./soffice -writer
Is enough to get a fully working suite on Windows, Mac or Linux. That avoids a ton of perl, cleans up a lot of scp2/ and includes removing a chunk of install-time setup. Thanks to Michael Stahl (Red Hat), David Tardon (Red Hat), Matus Kukan(Collabora) and Marcos Paulo de Souza. It's always fun to see partners exchanging runnable Windows installs as an instdir.zip.

As an added bonus we also removed some vile platform specific sub-directories from the build infrastructure things like unxlngi6.pro all over the place; if people want to build multiple platforms from the same source they can run configure from a separate directory. Thanks to Michael Stahl (Red Hat), and Tor Lillqvist (Collabora).

Individual localisation builds

Building the large number of localisations that go with LibreOffice - we support 100+ languages out of the box creates quite a compile-time load. Thanks to Bjoern Michaelsen (Canonical) - we can now compile localisation separately from the main package. This helps Linux packagers in multiple ways. The split lowers the requirements for disk space on the build machine (which can be over 25 GB for a release build), which is helpful for porting to more constrained architectures. Builds and respins are faster. With the in-place runnable LibreOffice build into instdir we can also avoid using crufty scp2/ macros interpreted by perl to package these directly. The change also makes it easier to re-spin security fixes without re-building hundreds of unchanged localizations, we look forward to Linux distributions picking this up to ease their packaging and maintenance burden.

Autodoc is dead, long live Doxygen

For many years, horrible hacked version of ... now thanks to Michael Stahl (Red Hat)'s great work doxygen has been taught about LibreOffice's UNO IDL and we've rid ourselves of the cosv, udm and autodoc top level modules - good riddance to 57k lines of code. Thanks also to those who helped to improve, cleanup and 'doxygenize' code comments in 4.2 Julien Nabet, Miklos Vajna (Collabora), Christian Lohmaier (TDF), Thorsten Behrens (SUSE), Stephan Bergmann (Red Hat), Zolnai Tamas (Collabora). You can read our generated documentation for: public API and internal API here.

Code quality work

There has been a lot of work on code quality and improving the maintainability and cleanliness of the code. Another 80 or so commits to fix cppcheck errors thanks to Julien Nabet, the daily rumble of building without any compile warnings with -Werror -Wall -Wextra on each platform with thanks primarily to Tor Lillqvist (Collabora) and Caolán McNamara (Red Hat).

Coverity scan

We have been chewing through the huge amount of analysis from the Coverity Scan, checkout the recent Spotlight Report on LibreOffice. We've seen 210 fixes (and many more closed tickets) in this release alone with many thanks to Caolán McNamara (Red Hat), Eike Rathke (Red Hat), Julien Nabet, Norbert Thiebaud, Andrzej Hunt (Collabora), Markus Mohrhard (Collabora) and Gergo Mocsi

Import and now export testing

Thanks to Markus Mohrhard we have the successful import crasher tests, that now test 45,000+ problem / bug documents from bugzillas across every project we can get our hands on. We load them one by one in a build with paranoid debugging assertions turned on. In recent times, we've also started exporting these documents to multiple different file formats looking for export issues, then, subsequently running whatever validation tools we can on the output. That, over time has a great impact on quality. Output is logged by git hash.

Valgrind fixes

Valgrind continued to be a wonderful tool for finding and isolating leaks, and poor behavior of various bits of code. Thanks to Mark Wielaard for fixing a number of leaks and other problems here, along with many other of the usual suspects.

Unit testing

We also built and executed more unit tests with LibreOffice 4.2 to avoid regressions as we change the code. These are rather hard to measure, since people like to pile up new tests inside existing unit test modules. One simple measure is to grep for the CPPUNIT_TEST() registration macro we can see that we added 216 of these since 4.1 - but we also added more CPPUNIT_ASSERTs per test; over 2160 of these. Our ideal is that every bug that is fixed gets a unit test to stop it ever recurring. With over 80 committers to the unit tests in 4.2, it is a little difficult to list everyone involved here, but it's wonderful to have a firmly entrenched and growing culture of writing unit tests alongside fixes.

Graph of number of unit tests and assertions
QA / bugzilla

This release the QA team has grown, and done some amazing work both triaging bugs, and also closing them. Thanks to Bjoern Michaelsen (Canonical), Robinson Tryon and Joel Madero for doing some great work there - and particularly to our top bug fixers, there is a great list of people responding in bugs here.

One metric we watch in the ESC call is who is in the top ten in the freedesktop Weekly bug summary. Here is a list of the top twenty people who have appeared most frequently in the weekly list of top ten bug closers; thanks to them tommy27, Caolán McNamara (RedHat), Maxim, Jean-Baptiste Faure, Eike Rathke (RedHat), ign_christian, Foss, Urmas, Joel Madero, Cor Nouws, Julien Nabet, Michael Stahl (RedHat), Maxim Monastirsky, Jorendc, Andras Timar (Collabora), Lionel Elie Mamane, Kohei Yoshida (Collabora), mariosv, bfoman, Thomas Arnhold, Adolfo Jayme (fitoschido), Sophie (TDF), Samuel M., Markus Mohrhard (Collabora), Rob Snelders.

You can read more about bug statistics and background on Bjoern's (interesting) blog (with cats). The overall bug picture can be summarised with some thousands though.

Code cleanup

Code that is dirty should be cleaned up - so we did a lot of that.

The final death of UniString

Perhaps the largest single change in 4.2 which has been underway from the very beginning of the LibreOffice project is removing our obsolete tools/ string class - thus leaving us with only 2x string classes, one for arbitrary encoding 8bit strings, and another for UTF-16 strings. The final commit slayed this monster for good. But of course huge numbers of people have worked hard at this job and associated cleanups for several years now - in this release around thirty people lent a hand; thanks particularly to Noel Grandin for spearheading the work, but also to many others Matteo Casalin, Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ivan Timofeev, Michael Stahl (Red Hat), Thomas Arnhold, Kohei Yoshida (Collabora), Eike Rathke (Red Hat), Tor Lillqvist (Collabora), Palenik Mihály, Markus Mohrhard (Collabora), Luboš Luňák (SUSE), MÁTÉ Gergely, Andrzej J.R. Hunt (Collabora), Christina Rossmanith, Laurent Balland-Poirier, Julien Nabet, Sean Young, Neil Moore, Jelle van der Waa, Donizete Waterkemper and Arnaud Versini.

Finally in 4.3 we will have the first user visible benefit of this work, allowing more than 64k characters in a single paragraph, checkout our still nascent 4.3 features wiki page and a related blogpost. Beyond that, fixing a bug recently it was somewhat interesting to see the morass of string types in the Windows platform.

One fewer temporary file API

We have a number of APIs for handling temporary files with different pedigrees, the oldest and ropiest: tools/tempfile.hxx was kindly written out by Palenik Mihály. Ideally there would be just one (safe) place in sal/ where temp files are handled.

Ongoing German Comment redux

We continued to make some progress on translating our last lingering German comments across the codebase to good, crisp technical English. Many thanks to Philipp Weissenbacher, Philipp Riemer, Laurent Balland-Poirier, Rolf Hemmerling, Chris Hoppe, Rodolfo Ribeiro Gomes, Matthias Freund and Henning Diedler. I suspect the tailing off effect is in part due to a rather substantial number of false positives in our language-guessing bin/find-german-comments tool.

Graph of remaining lines of German comment to translate
Removing dead code through compiler warnings

Lots of dead code was identified (and purged) with the help of recent improvements in Clang/GCC warnings (-Wunsued-function, -Wunused-variable, -Wunused-private-field, etc.) and by using SAL_WARN_UNUSED. (Caolán McNamara (Red Hat), Luboš Luňák (SUSE), Stephan Bergmann (Red Hat), Tor Lillqvist (Collabora))

Windows build & debug wins

The windows build time was reduced by 10 minutes (10% or so) thanks to Bjoern Michaelsen (Canonical) and then promptly slowed down again by adding Link Time Optimisation into the mix for newer Microsoft compilers.

Another much requested feature that helps users to provide excellent stack traces for Windows crashes and hangs, and thus debug / fix those much more rapidly is Cloph's Windows Symbol Server for release builds. Checkout how to get a backtrace - which is a wonderful way for users to provide better bug reports on that platform. Thanks to Fridrich Štrba (SUSE), Luboš Luňák (SUSE), and Christian Lohmaier (TDF).

Calc core refactoring

There is so much to say here, and it will be presented in much more detail shortly at FOSDEM. Suffice it to say that Calc has had a massive internal re-work, improving memory usage, performance in many cases, allowing the use of OpenCL to calculate some formulae on the GPU and more. Many thanks to Kohei Yoshida (Collabora), Markus Mohrhard (Collabora), and to the team from MultiCoreWare: I-Jui (Ray) Sung, Hao Chen, Shiming Zhang, Yiming Ju, Yang Zhang, Hongu Zhong, Ming Li, Min Wang, De Chuang, Feng Zheng, mulei, Xin Jiang, Zhenyu Yuan and more.

Getting involved

I hope you get the idea that more developers continue to find a home at LibreOffice and work together to complete some rather significant work both under the hood, and also on the surface. If you want to get involved there are plenty of great people to meet and work alongside. As you can see individuals make a huge impact to the diversity of LibreOffice (the colour legends on the right should be read left to right, top to bottom, which maps to top down in the chart):

Graph showing individual code committers per month

And also in terms of diversity of code commits, we love to see the unaffiliated volunteers contribution by volume, though clearly the volume and balance changes with the season, release cycle, and time available for mentoring:

Graph of number of commits per month by affiliation

Of course, we maintain a list of small, bite-sized tasks which you can use to get involved at our Easy Hacks page, with simple build / setup instructions. We now have a cleaner, and safer environment to work on improving the code. For example this video that shows how easy it is to get started in LibreOffice development these day. It is also encouraging to see how the Easy Hacks are progressing, lots of them are getting closed - could you close the 400'th ?

Graph of progress closing easy hacks over time

Another thing that really helps is running pre-release builds and reporting bugs just grab and install a pre-release and you're ready to contribute alongside the rest of the development team.

Conclusion

LibreOffice 4.2 is the next in a series of releases that incrementally improve not only the features, but fundamentally the foundations of the Free Software office suite. Of course, it's only the first in a long series of monthly 4.2.x releases which will bring a stream of bug fixes and quality improvements over the next months.

I hope you enjoy LibreOffice 4.2.0, thanks for reading, and thank you for supporting LibreOffice.

Postscript: this item kindly translated to French.

2014-01-29: Wednesday.

2014-01-28: Tuesday.

2014-01-27: Monday.

2014-01-26: Sunday.

2014-01-25: Saturday.

2014-01-24: Friday.

2014-01-23: Thursday.

2014-01-22: Wednesday.

2014-01-21: Tuesday.

2014-01-20: Monday.

2014-01-19: Sunday.

2014-01-18: Saturday.

2014-01-17: Friday.

2014-01-16: Thursday.

2014-01-15: Wednesday.

2014-01-14: Tuesday.

2014-01-13: Monday.

2014-01-12: Sunday.

2014-01-11: Saturday.

2014-01-10: Friday.

2014-01-09: Thursday.

2014-01-08: Wednesday.

2014-01-07: Tuesday.

2014-01-06: Monday.

2014-01-05: Sunday.

2014-01-04: Saturday.

2014-01-03: Friday.

2014-01-02: Thursday.

2014-01-01: Wednesday.


My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@collabora.com)

pyblosxom