2026-09-10 –, Track Room 1
LibreOffice OfficeBean enables Java applications to embed LibreOffice within their own interface. At the moment, this works through native bridge code on Linux/Unix and Windows, but macOS support is still missing.
I started looking into this through Bug 170415 by trying to add a small Cocoa/JNI bridge for macOS. The first result was partly encouraging: the native bridge connected, and the window could be created without crashing. But LibreOffice itself only showed a grey blank area.
In this lightning talk, I want to share what I tried, where it got stuck, and what I learned from maintainer feedback. The main challenge seems to be that macOS does not handle this kind of cross-process native window embedding in the same way as Linux or Windows. I will also briefly mention the direction I am exploring next: using IOSurface-based delegated rendering instead of trying to make LibreOffice draw directly into a Java-owned view.
This is a short work-in-progress talk about my attempt to understand and improve macOS support for LibreOffice OfficeBean.
I began with what looked like a missing native bridge: OfficeBean has platform code for Linux/Unix and Windows, but not for macOS. My first approach was to add a Cocoa/JNI implementation that could connect Java’s window handling with LibreOffice. That got me a little further than before, because the bridge loaded and the embedded window could be created. But the actual LibreOffice content did not render, leaving only a grey area.
The interesting part is what this revealed. The issue may not be just a missing macOS file or a simple handle-passing problem. From the discussion with maintainers, it appears that macOS has more stringent limits regarding sharing native windows between processes. So the next question is whether OfficeBean on macOS needs a different rendering approach.
I would like to use this lightning talk to share the path I followed, the problems I hit, and the possible next direction with IOSurface-based delegated rendering. I am still working on it, so feedback from people who know VCL, macOS, Skia/Metal, Java, or UNO would be especially helpful.
I am Rohan Singh, a mechanical engineer based in Berlin with a background in sustainable mobility and automotive management. I have always been drawn to systems: how they work, why they fail, and how small improvements can make them better.
My journey with LibreOffice began while I was writing my master’s thesis. I used LibreOffice on macOS for my academic work, and during that time, I ran into a number of bugs and usability issues. At first, they were just problems I had to work around. Over time, they made me curious about what was happening behind the scenes and how an open-source project like LibreOffice handles real user issues.
That curiosity brought me to the LibreOffice Conference in Budapest last year. Meeting the community there changed how I saw the project. It was no longer just a tool I used; it became a place where I could learn, ask questions, and contribute. After the conference, I started exploring macOS-related issues, learning how to navigate the codebase, and contributing C++ patches.
I come from mechanical engineering rather than a traditional software background, and that shapes the way I contribute. I like breaking complex problems down, understanding the root cause, and improving things step by step. For me, contributing to LibreOffice is a way to keep learning while giving something back to a tool that supported my own academic journey.
I am especially interested in open-source collaboration, macOS usability and reliability, sustainable mobility, and making technical communities more welcoming to people from different backgrounds.