LibreOffice Conference 2026: Exploring macOS OfficeBean Support in LibreOffice

Duration: 10:06 934 transcript words EN summary

Video summary

Rohan presented his findings regarding the integration of OfficeBean support into LibreOffice for macOS, a journey that began during his thesis work where he encountered various bugs and interface limitations. While Windows and Linux already possessed implementations allowing Java applications to control LibreOffice windows via OfficeBean, macOS lacked this native capability. His initial approach involved using AWT canvas within a Java application to display the window, relying on JNI for native code interaction and UNO plugins to communicate with the LibreOffice backend. However, early testing revealed that while the Java test case successfully launched, the LibreOffice component could not access the designated area, resulting in a gray screen instead of the expected content. The root cause of this issue was traced back to how the display area surface is exposed on macOS, specifically involving Objective-C implementations for JSurface layers rather than the manually defined Cocoa view structures initially assumed. Further investigation into the LibreOffice source code revealed two critical failures: the creation of a child frame returned a null pointer, indicating no frame was actually created, and the `setPlugInParent` function remained incomplete in its implementation. Consequently, the system failed to properly attach the LibreOffice instance to the external parent window, preventing the rendering of the Aqua VCL, which is the native graphical interface for the macOS backend. To resolve these discrepancies, Rohan plans to analyze process IDs from logs comparing both the Aqua VCL and the Java application to determine if they share the same identity or if pointers are correctly reaching the intended NS view. He acknowledges that since the Java application and LibreOffice run as two distinct processes, bridging this gap requires careful handling of platform-specific information and native code interactions. This next phase of his research aims to clarify whether the pointer is being passed to the correct location and how to successfully implement the missing layers between the plugin parent and the system data preview. Ultimately, Rohan's presentation highlighted that while the path forward involves significant technical hurdles related to macOS architecture, the community support seen at previous conferences provides encouragement for tackling these challenges. His work serves not as a complete fix but as a foundational exploration into the complexities of porting Java-based office integration to Apple's operating system. By identifying specific points of failure such as null pointers and incomplete parent setting functions, he has laid the groundwork for future developers to build upon, potentially leading to a fully functional OfficeBean experience on Mac OS in collaboration with the broader LibreOffice community.

Read the full video transcript

Shall I start or should I wait? Shall I begin or should I wait for I think this one is for plastic. Yep. >> No, I'm just waiting for him. I mean, >> I thought he would. No, I can start. Okay. >> Yeah. Good evening everyone. Uh I'm Rohan and today I'm here to present what I have. It's >> okay. Hi everyone. Today I'm here to present today. Sorry. Hey, I'm Rohan. Today I'm here to present what I have experienced while uh while exploring office beam support on Mac OS. So it's it's basically what I have learned not a complete fix that I'm going to explain today. Uh so my journeys began when I uh when I was working on my thesis extensively. I was using Libra Office for the work and then I struggled with it a bit and I uh came across some bugs and few of the rough edges and then I started to then I then I intrigued and I started to look for the community and for what's behind the interface and after attending the liberal office conference at Budapest I was encouraged and because I saw the people working on it and the community how well are they Okay. Uh so what I have uh what I have learned office bean allow Java application to control a Libra office window and traditionally it display the libra office window on uh Java. Windows and Linux already have their uh implementations but Mac OS didn't have it. So in in the beginning it looked straightforward that uh we just look for the implementation that we already have and then we can just make or we can just do the work for the Mac OS version as well. the the path uh the path I followed up to approach this task. The Java application contained uh the AWT canvas the window will contain the AWT canvas where the office should appear and the JNI would would be would allow the native code and then Java AWT interface would uh provide the information about the area where the window would appear. and which would be the platform specific information uh about the drawing area which which is for Mac OS is uh uh will led for the led you to the NS view uh pointer for this the UNO will communicate with the uh with the Libra office uh you using the plug-in parent and in the end the echo echo VCL would provide the child window for Libra office. Uh after testing uh uh in the for the testing uh with a small Java test case containing AWT frame and uh and the office bean uh canvas. I I ran it through my build uh I ran through my build just to uh get the test done. But in the beginning I encountered few of the bugs with with my uh incompatible libraries. So I rebuild it and when the first case happened successfully, it showed the Java content area but the Libra Office uh uh couldn't access it. So it it showed the gray gray gray area as you can see in the see in the screenshot from my uh test case that confirmed observed that uh that the Java window was uh was the test successfully happened but the libra office couldn't find the find the area to render. In the regard then I uh examined the examined how Java exposes the display area surface for the Mac OS where I found where I found according to my first interpretation that the platform info would manually define the Coco view structure. in my first interpretation but when I looked for the open GDK headers I came across that that's not it because uh it described it differently as a objective uh different u sorry it described differently as object C objective C object implementation for J surface layers Therefore that's why uh in the beginning there was gray area appeared. Then later I read through the libra office source code just to guide myself what was the pro problem where I understood the parent window value is expected to go and where it would go. uh it has it has to pass through the plug-in parent and then it has multiple layers that uh that is VCX window then the system parent data preview and in the end it will appear at the Aqua VCL which is Mac OS native graphical interface for back end. Therefore, I found out two uh two parts that the create child frame returns null pointer. That means there was no child frame that was created and secondly the set plug-in parent which was still in the uh to-do implementation. Uh so it wasn't successfully attaching the libra office to the external parent. and and that then that's when Patrick's feedback helped me to go through this problem where he raised a question about uh the Java application and the Libra Office application are just two different processes. So here I intend to compare the uh process ids from the logs for Aqua VCL and for the Java to compare if they have the same ids if the pointer is getting to the correct NS view or not. Uh that's what I'm planning to do next. Yeah, thank you for having Thanks for having me. Now some question the hands. I have the microphone and you can make the open for the feedback or suggestion or questions. Nothing. You understand? Fantastic project. Yes. Okay. So, >> thank you so much.