> "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!"

It it's truly 20 layers of abstraction, I'd love to read a blog that spelunks into all those layers and elucidates what they do.

Started in 1988, but since around 2012 we have started to streamline it.

The layers work like this:

1. Old cross platform layer for both operating system specific functionality (OSL) and runtime specific functionality like string handling and bootstrapping (RTL).

2. UI code base is the Visual Components Library (VCL) - Window handling, event loop, controls (e.g. buttons, etc), etc.. This is divided into a platform specific part and a non-platform specific part (allows for easier porting).

3. “Starview Library” (svl) and toolkit Library with extra widgets, etc.

4. SFX2 (Starview Framework v2) dies things like dispatches messages, creates a “shell” for each program.

After that I get a bit lost, it it’s mostly app specific stuff.

There’s also a component model baked in called UNO (Universal Network Objects) which is a network transparent component hosting environment - it’s what allows the use of Python and Java, with obviously a C++ specific purpose environment. It’s kind of cool, but also many folks don’t want to use it any more than necessary.

I think it helps to understand that it was a German company who created StarView, they really though in terms of layering :-)

I vaguely remember that StarDivision (the original company) offered separate licenses for the VCL as a cross-platform UI library in the 90s. If memory serves, it was available for DOS, Windows, OS/2 and Solaris back then.

And MacOS. It was reviewed by Dr Dobbs magazine, wish I had the original library source code! I’m a bit of a Libreoffice code historian, but there is no source code history before the year 2000...

Not sure if you'll see this since I'm a bit late, but I have two questions:

1. I've been wondering this for a while but never knew who/where to ask, but where's the original StarOffice code dump? What actually got dumped? I'm fascinated by that whole transition timeline, both in terms of its own history and also as one of many code dump events. (One of these days I'll go learn about Mozilla.)

2. Are there any interesting tidbits floating around? Any old DOS-era or early-Windows-era code, for example? I wonder if (with great effort) I could build something for Win3.1. (Of course I realize I'm not describing LO at all here)

2000 is pretty old, as tech goes, surely something fun got captured. The only reason I can see for super-old code not floating around somewhere is that it was explicitly excluded.

Actually, maybe not for Windows 3.1 (it did run in this) but there was a shim layer where the developers inplemebted something called uwinapi. Thus implemented NT functions for Windows 95 and 98, and in fact it was used layer for a few functions that didn’t work in Windows XP but did in Vista.

There is a whole bunch of code in the SAL that works for OS/2 but it has maintenance overhead. Both uwinapi and the OS/2 port have been removed from Libreoffice.

As for a code dump before 2000 - man, I would love that. But sadly, it doesn’t exist. The Star/Sun/Oracle guys chanted VCSes a few times. They had a procedure for merging patches into the trunk that was insane - and we have lost the history of those branches so from between 2001 to 2009 the code becomes harder to follow.

Unfortunately, there are decisions that were made before 2000 but that’s lost to us now due to a lack of version history from before this point.

I see, wow. Thanks for the info.

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?

Honestly: yes. LibreOffice is quite a friendly place, and there's even a list of beginner bugs that help with getting your foot in the door. They like new developers.

It might take more than a few hours (e.g. you'll need to set up a dev environment - but the builds are quite robust nowadays unlike some projects), and the codebase is complicated - but contributing to LibreOffice was fun and helped me gain real world software experience. I'd only worked on small personal projects before LO.

You definitely won't cause harm, and there are devs who will try to help you get your patch submitted. (They even employ someone to help new contributors get up to speed and to help get their patches in.) As chris_wot said, get on irc and people will generally be able to help you get set up. (IRC presence tends to vary by time and day, jfyi.)

The first step is setting up the build environment on your operating system and completing a successful build. Depending on your computer, the build might run for 4 hours :)

The articles on building are found in the General Programming Guidelines box in this index: https://wiki.documentfoundation.org/Development

Then you will want to pick an easy hack: https://wiki.documentfoundation.org/Development/EasyHacks Note that there are more challenging easy hacks marked by the difficultyInteresting keyword. This step also implies you will create an account on the Bugzilla.

If the easy hack is not an ongoing thing, you should comment on the Bugzilla report about your desire to work on it and assign it to yourself and change status to ASSIGNED.

If the easy hack is an ongoing task, you might want to check https://gerrit.libreoffice.org/ if there are some unmerged patches related to it by searching for message: and the bug number. This will allow you to be confident about avoiding duplicate work.

To start working on your patch, you typically create a new branch:

git checkout -b my-branch-name

as advised in the "Sending a Patch to Gerrit" section of this: https://wiki.documentfoundation.org/Development/gerrit

The topic of amending patches is dealt in this additional article: https://wiki.documentfoundation.org/Development/gerrit/Submi...

Easy hacks come with mentors attached to them, so the patch reviews should not get stuck in a limbo. Regarding "normal" patches, they might sit there even for some weeks, but I hope the situation improves when TDF hires the new developer mentor(s): https://blog.documentfoundation.org/blog/2017/11/07/job-sear...

Btw. there is a job search for feature implementation going on: https://blog.documentfoundation.org/blog/2018/01/16/tender-c...

Hop onto IRC - #libreoffice-dev on Freenode

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.

This doesn't have much relevance for LO. Devs there are generally welcoming. You'll still get honest feedback but they generally want your code in the codebase, and want to help you get it in a shape to land it.

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...

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

Thank you very much for the overview! I'll check out the QA IRC this weekend, and look through the links you've shared. Hope to see you around too. :-)