The image logos are protected by copyright to LibreOffice and GSoC.

Basic IDE Object Browser & Code Auto-completion

Mentors - Jonathan Clark, Prof. Rafael Lima, & Hossein

Last year, I participated in Google Summer of Code with LibreOffice, working on the Histogram Chart. While it was a great experience, I felt I still lacked the skills to work independently within the large codebase. This year, I was given the opportunity to return and tackle a project that would not only be an important contribution but would also help me develop the skills to navigate the code with confidence.

The project's goal was to modernize the LibreOffice BASIC IDE by introducing a reliable Object Browser for API and macro exploration, and laying the groundwork for modern code-completion features like dot-triggered suggestions and Ctrl+Space

Project Link - https://summerofcode.withgoogle.com/programs/2025/projects/iLT9BxsA

Project Goals & Achievements

The primary goal was to bring modern IDE features to the LibreOffice BASIC IDE. This involved a deep investigation into LibreOffice's internal APIs, developing a data provider to fetch this information, and integrating it into new UI components.

The main achievement of the project is a fully functional, stable, and performant Object Browser. This new tool allows developers to navigate the complex UNO API and browse all loaded BASIC macro libraries from within the IDE. Key features include a two-pane hierarchical view, a powerful search engine with ranked results, and context-aware links to external documentation.

A significant part of the project also involved a deep architectural journey. An initial monolithic, multi-threaded prototype, while functional, was plagued by instability and race conditions.

Basically, the overall goal for the initial part of the project was to make a sort of an inventory -

So the month of May mostly went in exploring and building the Master Information table -
https://docs.google.com/spreadsheets/d/1t5wp6QO1YHEZB6QihkFyqdTGpvZ6yyKzT8HEtJVppsw/edit?usp=sharing

and here is also a document I prepared for the understanding of the Basic and Basctl directory -
https://drive.google.com/file/d/1zxf0FyRdMxfG4jrk3e6Lk-iby9wh3fOO/view?usp=sharing

It not just involved finding and exploring it also included to compare different ways of getting information. Looking at how Microsoft VBA presents its own API information browser.

The process of re-architecture this into a series of clean, synchronous, and maintainable patches was a critical achievement, resulting in a much more robust final product and providing invaluable lessons in software engineering.

Technical Summary

The core technical challenge was to access and process introspection data from two very different sources: the pre-compiled UNO type system and the live, runtime state of BASIC macros.

Investigating Data Sources:

This was the most critical PoC, as it tested the exact C++ mechanism that would power the final IdeDataProvider. The goal was to query the live, in-memory UNO type system.

1. UNO API: The investigation revealed that while Interface Definition Language (.idl) files are the source of truth, they are compiled into binary Registry Database (.rdb) files for runtime use. The key discovery was the com.sun.star.reflection.theCoreReflection service, a powerful C++ singleton that provides live, programmatic access to all loaded UNO type information.

2. BASIC Macros: For user-written code, the SbiParser and SbiSymPool components were identified as the core mechanisms that parse BASIC source and build a symbol table of all functions, variables, and constants.

From Asynchronous Complexity to Synchronous Simplicity:

A major challenge was preventing the UI from freezing while fetching the ~17,500 UNO types. The initial approach involved a complex, multi-threaded architecture with a background thread for data loading and a caching system to feed the UI in chunks. This design introduced significant complexity and race conditions.

Guided by mentors, a pivot was made to measure the performance of a simple, synchronous data scan. Bench-marking revealed that a full scan on a release build completed in just ~0.15 seconds—a negligible one-time cost. This data-driven decision led to the removal of all background threading, dramatically simplifying the code, eliminating race conditions, and improving stability and maintainability.

The Monolith and the Rebirth:

The initial development was done in a single, large Gerrit patch. This approach proved to be a significant obstacle, as UI integration flaws introduced early on created a cascade of hard-to-debug stability issues, including shutdown crashes and "ghost" windows. After weeks of fighting these symptoms, a strategic decision was made to abandon the monolith. The project was rebuilt from the ground up as a series of small, logical, and reviewable patches. This methodical approach was crucial for achieving the final stable and well-architected result.

https://gerrit.libreoffice.org/c/core/+/186822 here is the big monolith patch.

Final Merged Patches

• Patch 1: Core Data Structures: https://gerrit.libreoffice.org/c/core/+/189934

• Patch 2: Integrating the Blank Shell UI: https://gerrit.libreoffice.org/c/core/+/191206

• Patch 3: The Synchronous Solution: https://gerrit.libreoffice.org/c/core/+/191405

• Patch 4: Scope Selector & Dynamic Refresh: https://gerrit.libreoffice.org/c/core/+/191886

• Patch 5: UI Interactivity & Member View: https://gerrit.libreoffice.org/c/core/+/191923

• Patch 6: Right-Pane & Documentation Link: https://gerrit.libreoffice.org/c/core/+/192050

• Patch 7: Details Pane & Status Bar: https://gerrit.libreoffice.org/c/core/+/192079

• Patch 8: Activating the Search Engine: https://gerrit.libreoffice.org/c/core/+/192237

Working of Object Browser: https://www.youtube.com/watch?v=-TqSmjFQ5hI

What is remaining?

The navigation buttons, which were part of the original monolith patch, still need to be implemented in the new synchronous architecture. The second major part of the project, the Code-Auto Completion and Suggestion engine for the IDE, remains to be done. However, the robust IdeDataProvider built for the Object Browser now provides a solid foundation for this future work. I am confident that I can now approach and implement this functionality.

Here are the weekly mails
Week 1: https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html

Weeks 2-3: https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html

Week 4: https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html

And here is the entire week 4 mail thread (sorted according to thread): https://lists.freedesktop.org/archives/libreoffice/2025-June/thread.html

Week 5: https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html

Week 6: https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html

Week 7: https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html

Week 8: https://lists.freedesktop.org/archives/libreoffice/2025-July/093572.html

Week 9-10: https://lists.freedesktop.org/archives/libreoffice/2025-August/093662.html

Week 11: https://lists.freedesktop.org/archives/libreoffice/2025-August/093694.html

Week 12-13: http://lists.freedesktop.org/archives/libreoffice/2025-August/093738.html

Week 14: https://lists.freedesktop.org/archives/libreoffice/2025-September/093784.html

Longer version with historical explanation of the Object Browser working - https://devanshvarshney.com/basic-ide-complete-journey

My Experience with GSoC 2025

My Favorite Part of GSoC

Learning not just how to think, but what to think. This year I just enjoyed working and kept sharing what I was solving with my friends.

Most Challenging Part

Paying attention to details. I have a hard time keeping my attention, and working in GSoC has highlighted this for me. I kept missing details right in front of me. This missing out of details kept showing up until the last patch, but I cannot thank Jonathan enough for keeping up with all these tiny details and showing me how to really look at them.

A Deeper Lesson from a Simple Helper

During development, I created a small IdeTimer class to benchmark performance. My initial implementation of the getElapsedTimeMs() method included an if block to handle cases where the nanosecond calculation resulted in a negative value. During code review, it was pointed out that this block was unnecessary because the final calculation would work out correctly due to integer arithmetic properties.

sal_Int64 IdeTimer::getElapsedTimeMs() const

{

TimeValue aEnd; osl_getSystemTime(&aEnd);

sal_Int32 nSeconds = aEnd.Seconds - m_aStart.Seconds;

sal_Int32 nNanos = aEnd.Nanosec - m_aStart.Nanosec;

// This is the "if block" in question

if (nNanos < 0) { nSeconds--; nNanos += 1000000000; }

return (static_cast<sal_Int64>(nSeconds) * 1000) + (nNanos / 1000000);

}

It took me a while to fully grasp this. This experience was a practical lesson in simplicity and avoiding over-engineering. The key takeaway was to trust the well defined mathematical properties of the data types I am using. The code review process worked exactly as it should it challenged an assumption, led to a deeper understanding, and resulted in simpler, cleaner code.

A Lesson in Cross-Platform Reality

Nothing taught me how truly difficult cross-platform development is more than one particular bug. For weeks, a feature would work flawlessly on my macOS machine, only to crash instantly with a "red-black tree" error on the GTK builds for Linux.

The VCL provides a single API, but the underlying native toolkits—Cocoa on macOS and GTK on Linux—behave very differently. My code was accidentally telling the framework to clean up an internal "placeholder" object that it had already cleaned up for me.

The lenient Cocoa backend on my Mac silently ignored this invalid request, hiding the bug and giving me a false sense of stability. The strict GTK backend, however, correctly identified this as a corruption of its internal state and chose to crash rather than risk rendering a broken UI.

This was my real-world lesson: cross-platform development isn't just about using a shared API. It's about writing code that respects the strictest rules of all target platforms. The bug was always in my code; my primary development environment just happened to be the one that hid it from me. It's a humbling experience that has profoundly shaped my approach to writing robust code.

Improved Programming Skills

Everyone keeps talking about what and how to write good code, but I learned or rather, realized where to write the code. There is this dialogue of Kevin Spacey from House of Cards, “Power is a lot like real estate. It's all about location, location, location. The closer you are to the source, the higher your property value.” I perceive that where you place your code determines the entire structure and complexity of the system.

Compared to last year, I am now much more comfortable with the codebase. Working on the BASIC IDE has given me a very deep dive. Implementing complex or practically unwanted solutions, while costly in time, gave me a very good understanding of how not to approach a problem.

Advice for Future Contributors

Compared to last year's GSoC where I found finding the right place to make a change difficult, this year the biggest challenge which I identified while working is defining my goal for the day and what I am going to do. For example, I would say that today I will send a mail or complete a given document, and it kept getting derailed because I wasn't defining what needs to be done in how much time. If a bug or implementation was taking time, I would spend my entire day on it, not being able to catch up with what I said I would do.

Don't let that happen. I plan to incorporate a technique my mentor from last year, Tomaž, uses: defining my daily tasks on a sticky note in front of my screen.

How I Rate Myself

Compared to last year, after more than five months of constantly working with the code and implementing some unnecessarily complex solutions, I am now comfortable and can work independently. This year I would rate myself around a 7 out of 10, as the process of breaking down the monolithic patch gave me the confidence to know how to approach a problem from the very beginning.

And I cannot thank enough to my mentors Hossein, Prof. Lima, and specially Jonathan all the meetings which we had and the maneuver which they helped me to take to reach this goal. But, it is more than that for me given my ADHD these 5 months have helped me to sit and focus on just one thing and being able to almost consistently do a single thing.