
Restructuring a giant, ancient codebase to make LibreOffice work well everywhere - buovjaga
https://fosdem.org/2018/interviews/michael-meeks/
======
ZenoArrow
Thank you for sharing this article. Speaking personally, it comes at a great
time. I've been toying with the idea of getting involved in open source, and
was particularly interested in pushing forward open source office suites.

Something that I'm particularly interested in with LibreOffice is helping the
core being decoupled from the UI, to both help with portability and to speed
up the rate of UI innovation. I had thought that I may have to start by
myself, but based on this article it seems that the current LibreOffice
developers are thinking along similar lines.

If any LibreOffice developers are reading this, are there any sub teams setup
that may be a good fit? To give some idea of my background, I would describe
myself as a tester that knows how to code (not in C++ alas, but I'm familiar
enough with debugging at a low level).

~~~
buovjaga
Regarding the UI, there are certainly some... curiosities. To give you a
random anecdote from the trenches:
[https://bugs.documentfoundation.org/show_bug.cgi?id=107087#c...](https://bugs.documentfoundation.org/show_bug.cgi?id=107087#c16)

"It's challenging to fix as one needs to tunnel certain data through 20 layers
of abstraction, but hey, that's improved UX for you!"

If you want to get into triaging bugs, I welcome you with open arms. I am
desperate to get us more helping hands as after nearly 10000 analysed reports
I am anxious to diversify.

Here is the index of our QA tech articles:
[https://wiki.documentfoundation.org/QA](https://wiki.documentfoundation.org/QA)

Basic debugging info for triagers:
[https://wiki.documentfoundation.org/QA/BugReport/Debug_Infor...](https://wiki.documentfoundation.org/QA/BugReport/Debug_Information)

Debugging for devs:
[https://wiki.documentfoundation.org/Development/How_to_debug](https://wiki.documentfoundation.org/Development/How_to_debug)

Binary bisecting:
[https://wiki.documentfoundation.org/QA/Bibisect](https://wiki.documentfoundation.org/QA/Bibisect)

If you were thinking of working on the UI, please get in touch with the design
team, which includes some devs (but could really use 10 more!):
[https://wiki.documentfoundation.org/Design](https://wiki.documentfoundation.org/Design)

You will find me in the QA IRC channel (and most others):
[https://wiki.documentfoundation.org/QA/IRC](https://wiki.documentfoundation.org/QA/IRC)

I'm heading to sleep now, though, but I hope to see you around!

~~~
voltagex_
Do you think someone (with a programming background) can help in say, 2 to 4
hours by just jumping in, or am I going to cause more harm than good?

~~~
scrapcode
This articulates almost every experience I've had with trying to contribute my
time to any open source project that has any size. I really think I've figured
something out that'll help. I spend many hours getting X codebase to compile /
work on my machine. I fix said issue and feel great about it! It never even
gets looked at and/or it gets smashed to shreds with criticism by the same
person that submitted the feature req / bug / whatnot.

~~~
Zancarius
I feel you, especially as someone with a bit of social anxiety any time I
think I'm doing something helpful or useful (like writing this comment),
because that concern is always in the back of my head. I don't have any
particularly good advice that you likely haven't read or heard before, but
sometimes it's useful to read/hear it from others who've been in the same
boat.

In my experience, and this goes doubly so for small FOSS projects, you _have_
to remember that it's someone else's baby. Maybe they were the person who
started it, maybe they've been there since the early days, or maybe they have
an unusually strong attachment or sense of ownership over whatever it is
you're changing. At any rate, the moment you submit a patch, there's always
the risk that it may be met with harsh criticism (sometimes deserved;
sometimes not), and at least part of that may be the nature of the human
psyche. So, the best defense is to do things by the book, if there's an
established process, or failing that, persistence. Sometimes, just the
existence of a patch in the wild--even if it isn't accepted by the developer--
can be enough to motivate them toward a fix. I've seen plenty of relatively
minor fixes get rejected only to be fixed hours later by a maintainer because
the patch got them _thinking_.

Let's be honest, even if it bruises the ego a little: As a user, I don't care
how it gets fixed. I'm not in it for the glory. I just want it to _work_.

There's of course the usual advice [1]: Keep your pull requests/patches short
and targeted. Don't try to do too much, because larger, more widely reaching
patches are likely to be ignored or turned down. Document what you can, why
you did what you did, and what you intended to fix; but don't be too verbose
(guilty, as you can see here!). Asking follow-up questions is instrumental if
it's rejected, because there's probably something that was missed or
overlooked. Of course, this doesn't obviate issues with projects that have a
distinct lack of communication skills or toxic personalities. Ironically, I've
had some luck with non-committal/non-responsive maintainers by forking small
projects, applying my changes and moving on, only to find some weeks later
that they want to pull my changes. In those cases, I never expected a fix--I
just needed it to work _yesterday_ \--and I needed somewhere to publicly
source the fixed copy from. That upstream wants the resolution as well is
merely an added bonus.

But the key is (polite) persistence. It's also the hardest to do if you don't
want to seem rude or pushy. I also think that rejection and criticism play on
our fear of failure (whether or not we admit it), which may kill
participation. Just don't give up: Think of the other users who don't have
your skill set to fix the underlying problem and consider that you're
advocating for _them_!

[1] [https://www.atlassian.com/blog/git/written-unwritten-
guide-p...](https://www.atlassian.com/blog/git/written-unwritten-guide-pull-
requests)

~~~
Vinnl
Well, skip the anxiety, because this is good advice :)

------
niftich
He has a slide deck [1] that he links to in the interview, where he tries to
highlight some challenges with grokking large codebases, and techniques one
can use to compartmentalize understanding and build from there. I found it
both a bit too colloquial yet also too opaque, but there's some useful nuggets
in there.

It also speaks to a significant problem: large codebases are inherently
difficult to understand, which forms a barrier to entry. This is despite the
fact that most software makes use of various abstractions to break problems
into smaller parts.

In the general sense, I believe it's worth thinking about how the particular
abstraction mechanisms used in software impact a new contributor's
productivity, vs. the productivity of someone more familiar with the codebase,
especially for projects that are developed in the open, or with high developer
turnover.

[1] [https://people.gnome.org/~michael/data/2016-04-29-solving-
pr...](https://people.gnome.org/~michael/data/2016-04-29-solving-problems.pdf)

~~~
jandrese
I've always found abstraction to be a double edged sword when trying to
understand codebases. Sometimes it helps define the intent, but other times
I'm going "WTF is this thing for real?" and tracking the abstractions through
several files.

My favorite is tracking down a member function and being completely confused
until I realize that I missed one of the layers and it was overridden in that
instantiation.

~~~
manmal
IMO the most important thing when introducing a layer of abstraction is the
name of the new component. I sometimes spend 2 or more minutes making up a
name that best describes what this layer is about.

ProTip: _Manager or_ Controller is not a good name. To me a good name is eg
„PostDetailSerializerResolver“ - it’s a component that will resolve
serializers for post detail objects. And according to concept of single
responsibility, it should only do that. If you need it to do more, you must
change the name.

~~~
vanderZwan
> I sometimes spend 2 or more minutes making up a name that best describes
> what this layer is about.

Some of the best refactoring I ever did for long-term code-maintenance was
nothing more than untangling a web of abstraction layers and renaming them to
fit the actual context, changing nothing to the functionality of the code.

Sometimes you start out with an idea for what the architecture will be, but
then things change and the naming isn't updated.

------
ktpsns
It's so amazing that the dinosaur LibreOffice/OpenOffice is still maintained.
From the codebase, it is probably similarly old-fashioned like Thunderbird.
Some folks may say it is hopeless to modernize. For me it does not even matter
whether that's true or not -- it is a well-done and partially timeless and
universal tool in my everyday work flow. While there are fancy and modern
alternatives like the (closed source) Google Docs, LibreOffice always stays as
a fall-back solution if nothing more works. Thank you for this work,
developers!

~~~
mapgrep
I recently discovered that Microsoft literally will not sell you Office for a
computer not connected to the internet. You cannot buy this product, I tried
very hard, lots of escalation, etc.

Needless to say, LibreOffice works very nicely in an offline environment, and
it's very rare that I find a file it does not handle well. (The only example I
have — a Word document with Track Changes enabled, heavily revised by multiple
people, multiple times over many days. L.O. seemed to lose track of the
changes and showed a wrong document. I imagine for most people this is pretty
rare.)

And you don't have to worry about malware (for those tempted to pirate
Microsoft Office).

~~~
taspeotis
I'm a bit confused by this. Microsoft normally has excellent offline
activation capabilities for all the three letter agencies that buy their
software and run it on internal networks.

~~~
fny
Enterprise editions exist with 100% offline installation, but unfortunately,
home and business licenses have an "offline install" that requires online
activation...[0]

This has been a huge PITA for me since I often need Word and Excel on a
computer that's restricted from accessing the internet.

[0]: [https://support.office.com/en-us/article/Use-the-
Office-2016...](https://support.office.com/en-us/article/Use-the-
Office-2016-offline-installer-f0a85fe7-118f-41cb-a791-d59cef96ad1c)

~~~
taspeotis
This is a bit kafka-esque:

> You need to be connected to the internet to download this installer file,
> but once that's done, you can then install Office offline on a PC at your
> convenience.

> ...

> After your Office installation is complete, you need to activate Office. Be
> sure you're connected to the Internet and then open any Office application,
> such as Word or Excel.

I mean the lede is "problems with slow speed or unreliable connections" but at
the same time ... offline is offline.

------
eloy
I'm quite surprised that the markup incompatibility with Microsoft Office is
still an issue. Are they actively sabotaging the Open Document Foundation, or
is it just really difficult to achieve?

~~~
pbhjpbhj
Have Microsoft completely solved compatibility between different/same versions
of MS Office now?

~~~
pletnes
Nope, I ran into word documents that word could not render just last month.
And I hardly use word; I edit about 1-5 docs per month.

------
chris_wot
I'm trying to document the internals:

[https://chrissherlock1.gitbooks.io/inside-
libreoffice/conten...](https://chrissherlock1.gitbooks.io/inside-
libreoffice/content/)

I've also been, on the quiet, go through the commits and summarise it better.
Before 2009, there was this insane way of grouping commits and it makes it
hard to know who did what to the code!

------
thinkloop
Would be nice to restructure the article next to make it readable on mobile.

~~~
fredsted
Reader Mode in Safari works well on this.

------
gnachman
I recall seeing a Google tech talk over ten years ago where they talked about
cleaning up OpenOffice (or was it StarOffice?) it was memorable because they
mentioned it did #define private public. I’m impressed they kept at it and it
sounds like it’s going well. Still glad it’s not my project, though :)

~~~
the-tml
Sounded unfamiliar, so I checked. The Apache OpenOffice sources indeed have
three such lines left (all in obscure fairly irrelevant parts of the code; two
inside odd #ifdefs that are never true, one inside their OS/2 (yes!) backend).
LibreOffice naturally hasn't any such crap any longer.

~~~
olavk
Do you know why both Apache OpenOffice and LibreOffice still exists?

~~~
chris_wot
History. Check the Wikipedia article.

------
nshm
Michael Meeks is a wonderful guy, love his "Up early..."

------
dingdingdang
Personally wish people would stop tinkering with the UI - polish but do not
tinker/change needlessly. Case in point being that Linux likely remains fringe
as a desktop platform simply because of it's continual tendency to morph on
the UI side of things.

Then again, Win10 is going down the same route so maybe it will all even out
(...).

~~~
aetherspawn
You mix UI and UX polish, and the UX on OpenOffice is honestly not very good
... I only had to use it the other day and struggled with finding half a dozen
things that are just obvious with Word.

~~~
jmiserez
* obvious to Word users

For complete novices, yes the UI is not very intuitive. But Word isn’t much
better either.

I recently had to start using Word again at work and even though the ribbons
_seem_ intuitive and user-friendly, actually finding the feature I needed has
not always been easy. I’ve had to Google quite a bit (the help is excellent
though).

At least in LibreOffice everything is always in the menus and does not
suddenly disappear if your window is not wide enough.

~~~
oblio
Office now has a command search box.

------
SubiculumCode
Generally I find their suite pretty full features and functional. There are
occasional conversion snafus with MS formats, but honestly that is less on
them and more on MS.

In all honesty, my biggest issue is that Calc can slow to a crawl when a sheet
gets even moderately large, especially if using filter/sorting.

~~~
chris_wot
I’ve upvoted you - this sort of feedback is invaluable! Do you have an example
spreadsheet? If you could log a bug and upload it, that would be helpful.

~~~
SubiculumCode
Open a LibreOffice Calc doc. Put a 1 in A1. Drag down to a thousand or so.
Then drag to the right replicating that series out to say LL. On my decently
beefy laptop (i7 quad core, 16 GB RAM, 8 Gb RAM free) it slows to an absolute
crawl. On my server (16 dual threaded cores, 64G RAM), it can handle quite a
bit more before slowing to a crawl.

~~~
SubiculumCode
laptop windows. Server Ubuntu

~~~
chris_wot
Try the bugzilla -
[http://bugs.documentfoundation.org/](http://bugs.documentfoundation.org/)

------
e943uu9nt
I love these sorts of projects and solving these sorts of problems. However, I
don't have time to work on an Open Source project, and can't due to employer
restrictions anyway. So I get out my inner refactoring by going to the Code
Review Stack Exchange [0]. Check it out if you want to do some analysis of a
small self-contained piece of code.

[0]
[https://codereview.stackexchange.com](https://codereview.stackexchange.com)

------
mscppcon24
This reminds me of a presentation[0] from Microsoft at CPPCon about using the
same giant ancient Office codebase on iOS and Android as on Windows.

0\. [https://cppcon.org/bonus-talk-cxx-in-ms-
office-2014/](https://cppcon.org/bonus-talk-cxx-in-ms-office-2014/)

------
ygh0309
Error:Execution failed for task ':createStrippedConfigMain'. > A problem
occurred starting process 'command 'D:/android/mobile-config.py''

~~~
buovjaga
Are you trying to build the Android Viewer on Windows? I believe no one has
ever done that, so I recommend you to stick with Linux:
[https://wiki.documentfoundation.org/Development/BuildingForA...](https://wiki.documentfoundation.org/Development/BuildingForAndroid)

------
anotherevan
Try doing that with your dynamically typed language.

~~~
Retra
It's really not going to be easy either way.

