Hi everyone, As my Google Summer of Code 2025 journey comes to a close, I'd like to share a final report on the work done to bring a modern Object Browser to the BASIC IDE. This project has been an incredible learning experience, taking me from a complex, buggy prototype to a series of clean, stable patches.
Final Report - https://devanshvarshney.com/libreoffice-google-summer-of-code-final-report-basic-ide *Final Demo Video*: https://www.youtube.com/watch?v=-TqSmjFQ5hI This mail summarizes that entire journey. *Part 1: The Monolith - A Prototype Built on Lessons* https://gerrit.libreoffice.org/c/core/+/186822 (Patch 37) My project began with a classic rookie mistake: I jumped straight into writing code. My "aha" moment came in my first mentor meeting, where I was given a crucial directive: "Figure out how to get the data first." This shifted my focus from coding to a deep investigation of the UNO API, BASIC's runtime, and the LibreOffice build system. This "data-first" approach was the foundation for everything that followed. After the initial investigation and some successful C++ PoCs, I built a large, monolithic prototype patch. The original plan was to make small patches but I kept committing in this. This prototype was ambitious and implemented many of the final features for data and UI responsiveness on-demand loading, and a functional search. However, this monolith was built on a flawed and fragile UI integration I had created in the early weeks. As a result, it was plagued by deep stability issues: - A "Ghost Parent" crash caused by a synchronous UI deadlock. - Race conditions during initialization that slowed startup to over 6 seconds. - Crashes on shutdown due to incorrect lifecycle management. For weeks, I tried to fix these bugs, even going down a rabbit hole investigating what I mistakenly thought was a macOS-specific issue. The real problem was the monolith itself. It was too big, too complex, and its foundation was unstable. The turning point came in a discussion with my mentors. We acknowledged that the monolith had served its purpose as a prototype but was now an obstacle. The new, mentor-guided strategy was to abandon it and begin the disciplined process of breaking it down into a series of clean, logical, and reviewable patches. *Part 2: The Refactoring Journey - Building It Right* This is where my real learning accelerated. By breaking down the work into small, focused patches, I could see a clear path forward. *Patch 1: Core Data Structures* We started from scratch with a clean foundation, introducing only the IdeSymbolInfo data structures and empty C++ class skeletons. No logic, no UI—just the bedrock. Gerrit: https://gerrit.libreoffice.org/c/core/+/189934 *Patch 2: Integrating the Blank UI Shell* This patch introduced the .ui file and correctly integrated a stable, dockable, but empty window into the IDE, following the established patterns of the VCL framework. Gerrit: https://gerrit.libreoffice.org/c/core/+/191206 *Patch 3: The Data Provider and the Power of Simplicity* This was a key moment. My instinct was to re-implement the complex, Background thread data loader from the monolith and then also with caching then I shifted this to Cooperative Multitasking. Instead, my mentor Jonathan Clark asked me to first benchmark a simple, synchronous approach. Then he also benchmark and the results were surprising: in a release build, the entire UNO API scan took only ~0.15 seconds. This hard data allowed us to discard the complex code and choose a simple, robust, and maintainable synchronous solution. Gerrit: https://gerrit.libreoffice.org/c/core/+/191405 *Patches 4-8: Layering on Interactivity* With a stable foundation, the remaining features were added layer by layer, with each patch having a single, clear purpose: *Patch 4: Activat**e the "Scope" selector for dynamic filtering.* This patch activated the "Scope" drop-down, allowing users to filter between "All Libraries" and "Current Document." It also made the browser dynamic, automatically refreshing its view when the user switched documents. https://gerrit.libreoffice.org/c/core/+/191886 (Scope) *Patch 5: Implement on-demand tree expansion and member display.* This is where the browser became truly useful. I implemented the OnNodeExpand and OnLeftTreeSelect handlers, connecting the left-hand tree to the right-hand members pane. Users could now explore the API hierarchy and see the members of any selected object. https://gerrit.libreoffice.org/c/core/+/191923 (UI Interactivity) *Patch 6: Add double-click actions (go-to-source and API docs).* This patch enrich the right pane by adding on-demand expansion for nested types and a powerful double-click action. Double-clicking a UNO type now opens its official API documentation page, while double-clicking a BASIC macro navigates directly to its source code. A members cache was also added to improve performance. https://gerrit.libreoffice.org/c/core/+/192050 (Right-Pane) *Patch 7: Activate the Details Pane and Status Bar.* This patch activate the informational panes. The details pane now shows a rich, formatted signature for any selected symbol, and the status bar provides helpful context like member counts and the final data load time. https://gerrit.libreoffice.org/c/core/+/192079 (Details Pane) *Patch 8: Implement the idle-time search indexing and UI.* The final patch in this series implement the search feature. It uses an asynchronous, idle-time task to build the search index without impacting startup performance. The UI is de-bounced for a smooth experience, and results are ranked to show the most relevant matches first. https://gerrit.libreoffice.org/c/core/+/192237 (Search) The final result is a stable, responsive, and feature-rich Object Browser. *A Deeper Lesson: The IdeTimer Story* A small detail that captures my learning journey is the IdeTimer class. I had added an if block to handle negative nanoseconds, which felt unintuitive. During review, my mentor pointed out that it was mathematically redundant. This taught me a practical lesson: trust the well-defined properties of the tools you're using and avoid writing unnecessary code. It's a small example, but it represents the shift from writing code that feels right to writing code that is proven to be simply correct. *A Lesson in Cross-Platform Reality: A Tale of Two Tree Views* 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 cryptic "red-black tree" error on the GTK builds for Linux. The VCL provides a single API, but the underlying native toolkit" 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. *The biggest challenge I identified working this year GSoC?* Compared to last year 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 of the day what I am going to do. Like for example I said that today I will send a mail or say I will complete the 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 is taking time I went on spending my entire day on it and not being able to catch-up what I said I will do. *What's Next* The foundational Object Browser is complete. The next major goals are to re-implement the Navigation Buttons (Back/Forward) on this new stable base and then tackle the original, ultimate goal of this project: providing context-aware code auto-completion in the IDE editor. I cannot thank my mentors Jonathan Clark, Prof. Rafael Lima, and Hossein enough for their guidance, patience, and for steering me back on course when I went astray. Their wisdom was the most valuable part of this entire experience. Thank you to the entire LibreOffice community as well for your support and for providing such a fantastic environment to learn and grow. Historical Weekly Reports: 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 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 -- *Regards,* *Devansh*
