GSoC 25: BASIC IDE - Object Browser Architectural Breakthrough [WEEK 8]
Devansh Varshney
varshney.devansh614 at gmail.com
Sun Jul 20 15:21:17 UTC 2025
Hi everyone,
This week marks a transformative leap for the Object Browser (OB). We have
evolved from a static UI shell to a live, data-driven tool, overcoming
foundational challenges with UI freezes and API discovery through a robust
architectural redesign.
The OB now dynamically populates the full UNO API hierarchy on demand, a
milestone achieved with Patch 18. This update provides a comprehensive
overview of the architecture and the precise status of the project.
Gerrit Patch: https://gerrit.libreoffice.org/c/core/+/186822
Live UI Screenshot:
https://bug-attachments.documentfoundation.org/attachment.cgi?id=201912
== Key Architectural Achievement: The Two-Cache System ==
Our success hinges on a two-phase caching strategy that solves the classic
"introspection vs. discovery" dilemma.
1. The Session Cache (The Dictionary): We recognized that UNO's
reflection system is for "introspection" (looking up known types), not
"discovery" (browsing). The solution is a complete, in-memory map of all
~20,000 UNO entities (IdeDataProvider::m_hierarchyCache). This is built
once in a background thread (~0.9s) and makes all hierarchy browsing
instantaneous.
2. The UI Bookmark Cache (The Sticky Note): To handle nodes with
thousands of children without freezing, the ObjectBrowser::m_aNextChunk
map acts as a bookmark. It tracks the next 50-item chunk to be rendered,
enabling a responsive, "infinite scroll" experience. Here after having a
discussion with mentors I proposed 2 paths to get rid of this UI freeze
One was to copy the m_hierarchyCache session cache from data-provider to
Our UI file and other was to use a sort of Bookmark. Now I recently saw
How Instagram has made some conscious UI designs to not to load everything
At once in the UI so for example we have Bookmarks on Instagram and as I
Many lists they used to load all at once now only first 3 bookmarks folder
Are shown and you have to press the + icon to load more.
So, here are we also using the same technique I did not go with the copy
entire session cache in UI which I got green flag from mentors rather as
A proof of concept before implementing this addition session copy I went
with this UI bookmark approach and it is working well.
My thought process was that UI should be dumb and only be dealing with
the what and how to show not dealing with the data at all.
This hybrid model gives us the best of both worlds: a fast, complete data
model and a highly responsive UI.
Flowchart: The Two-Cache Architecture
1 +-------------------------------------------------------------------------------+
2 | PHASE 1: ONE-TIME SESSION CACHE (IdeDataProvider) |
3 | (Builds the complete API map in the background) |
4 +-------------------------------------------------------------------------------+
5 |
6 v (Feeds complete, ordered child
lists to the UI)
7 +-------------------------------------------------------------------------------+
8 |. PHASE 2: UI BOOKMARK CACHE (ObjectBrowser) |
9 | (Renders the data in responsive 50-item chunks) |
10 +-------------------------------------------------------------------------------+
11 |
|
12 | [User expands "com.sun.star"]
|
13 | -> Bookmark is at index 0. Render children 0-49. |
14 | -> Update bookmark to 50.
|
15 |
|
16 | [User clicks "Show 50 more..."]
|
17 | -> Bookmark is at index 50. Render children 50-99. |
18 | -> Update bookmark to 100.
|
19 |
|
20 +-------------------------------------------------------------------------------+
== Status as of Patch 18 ==
The OB is now highly functional. Here is a precise breakdown of what is
working versus what remains.
What is Working:
- A stable, dockable UI shell, responsive due to UnoHierarchyInitThread.
- Infinite UNO API expansion, free of freezes, thanks to the bookmark cache.
- "Show more..." lazy loading, with click-handling bugs now resolved.
- The right-hand RightMembersView correctly populates with members.
- The DetailPane and StatusBar display signatures and performance data.
- SplitterPersistence correctly remembers pane positions between sessions.
What is Not Yet Working (Our Goals for Week 9):
- Application Macros Population: Blocked. The logic in
ImplGetChildrenOfBasicLibrary is flawed and prevents BASIC libraries from
being displayed.
- UI Coloring: Not working. The custom renderers exist but are not
triggered, likely due to an issue in how AddEntry passes data to the view.
- Global Search: Partially working. The backend SearchFlat is functional,
but the UI does not yet display the results with the correct coloring or
hierarchy.
- History Navigation: The Back/Forward buttons are wired but not yet fully
functional.
== Next Steps for Week 9 (July 21-27) ==
Our focus is to resolve these specific, well-understood gaps:
1. Fix Application Macros: Correct the logic in
ImplGetChildrenOfBasicLibrary to query the BasicManager properly.
2. Enable UI Coloring: Fix the AddEntry function and verify the .ui
column definitions to ensure the custom renderers are triggered.
3. Refine Global Search & History: Connect the final UI elements once the
underlying logic and rendering are complete.
This week's architectural success has unblocked all future development. The
long-term vision of potentially unifying the Object Browser and Object
Catalog (discussed in the Week 6 email and clarified with Hossein) now rests
on a much stronger foundation.
Thank you for your invaluable guidance and collaboration.
I have also added a txt file in case the diagrams format went off direction.
Week 1 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html
Week 2 and 3 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html
Week 4 mail(Thread) -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html
Week 5 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html
week 6 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html
Week 7 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html
Regards,
Devansh
-------------- next part --------------
Subject: GSoC 25: BASIC IDE - Object Browser Architectural Breakthrough [WEEK 8]
Hi everyone,
This week marks a transformative leap for the Object Browser (OB). We have
evolved from a static UI shell to a live, data-driven tool, overcoming
foundational challenges with UI freezes and API discovery through a robust
architectural redesign.
The OB now dynamically populates the full UNO API hierarchy on demand, a
milestone achieved with Patch 18. This update provides a comprehensive
overview of the architecture and the precise status of the project.
Gerrit Patch: https://gerrit.libreoffice.org/c/core/+/186822
Live UI Screenshot: https://bug-attachments.documentfoundation.org/attachment.cgi?id=201912
== Key Architectural Achievement: The Two-Cache System ==
Our success hinges on a two-phase caching strategy that solves the classic
"introspection vs. discovery" dilemma.
1. The Session Cache (The Dictionary): We recognized that UNO's
reflection system is for "introspection" (looking up known types), not
"discovery" (browsing). The solution is a complete, in-memory map of all
~20,000 UNO entities (IdeDataProvider::m_hierarchyCache). This is built
once in a background thread (~0.9s) and makes all hierarchy browsing
instantaneous.
2. The UI Bookmark Cache (The Sticky Note): To handle nodes with
thousands of children without freezing, the ObjectBrowser::m_aNextChunk
map acts as a bookmark. It tracks the next 50-item chunk to be rendered,
enabling a responsive, "infinite scroll" experience. Here after having
discussion with mentors I proposed 2 paths to get rid of this UI freeze
One was to copy the m_hierarchyCache session cache from data-provider to
Our UI file and other was to use a sort of Bookmark. Now I recently saw
How Instagram has made some conscious UI designs to not to load everything
At once in the UI so for example we have Bookmarks on Instagram and as I
Many lists they used to load all at once now only first 3 bookmarks folder
Are shown and you have to press the + icon to load more.
So, here are we also using the same technique I did not go with the copy
entire session cache in UI which I got green flag from mentors rather as
A proof of concept before implementing this addition session copy I went
with this UI bookmark approach and it is working well.
My thought process was that UI should be dumb and only be dealing with
the what and how to show not dealing with the data at all.
This hybrid model gives us the best of both worlds: a fast, complete data
model and a highly responsive UI.
Flowchart: The Two-Cache Architecture
1 +---------------------------------------------------------------+
2 | PHASE 1: ONE-TIME SESSION CACHE (IdeDataProvider) |
3 | (Builds the complete API map in the background) |
4 +---------------------------------------------------------------+
5 |
6 v (Feeds complete, ordered child lists to the UI)
7 +---------------------------------------------------------------+
8 | PHASE 2: UI BOOKMARK CACHE (ObjectBrowser) |
9 | (Renders the data in responsive 50-item chunks) |
10 +---------------------------------------------------------------+
11 | |
12 | [User expands "com.sun.star"] |
13 | -> Bookmark is at index 0. Render children 0-49. |
14 | -> Update bookmark to 50. |
15 | |
16 | [User clicks "Show 50 more..."] |
17 | -> Bookmark is at index 50. Render children 50-99. |
18 | -> Update bookmark to 100. |
19 | |
20 +---------------------------------------------------------------+
== Status as of Patch 18 ==
The OB is now highly functional. Here is a precise breakdown of what is
working versus what remains.
What is Working:
- A stable, dockable UI shell, responsive due to UnoHierarchyInitThread.
- Infinite UNO API expansion, free of freezes, thanks to the bookmark cache.
- "Show more..." lazy loading, with click-handling bugs now resolved.
- The right-hand RightMembersView correctly populates with members.
- The DetailPane and StatusBar display signatures and performance data.
- SplitterPersistence correctly remembers pane positions between sessions.
What is Not Yet Working (Our Goals for Week 9):
- Application Macros Population: Blocked. The logic in
ImplGetChildrenOfBasicLibrary is flawed and prevents BASIC libraries from
being displayed.
- UI Coloring: Not working. The custom renderers exist but are not
triggered, likely due to an issue in how AddEntry passes data to the view.
- Global Search: Partially working. The backend SearchFlat is functional,
but the UI does not yet display the results with the correct coloring or
hierarchy.
- History Navigation: The Back/Forward buttons are wired but not yet fully
functional.
== Next Steps for Week 9 (July 21-27) ==
Our focus is to resolve these specific, well-understood gaps:
1. Fix Application Macros: Correct the logic in
ImplGetChildrenOfBasicLibrary to query the BasicManager properly.
2. Enable UI Coloring: Fix the AddEntry function and verify the .ui
column definitions to ensure the custom renderers are triggered.
3. Refine Global Search & History: Connect the final UI elements once the
underlying logic and rendering are complete.
This week's architectural success has unblocked all future development. The
long-term vision of potentially unifying the Object Browser and Object
Catalog (discussed in the Week 6 email and clarified with Hossein) now rests
on a much stronger foundation.
Thank you for your invaluable guidance and collaboration.
I have also added a txt file in case the diagrams format went off direction.
Week 1 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-May/093264.html
Week 2 and 3 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093362.html
Week 4 mail(Thread) -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093392.html
Week 5 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-June/093443.html
week 6 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-July/093493.html
Week 7 mail -
https://lists.freedesktop.org/archives/libreoffice/2025-July/093527.html
Regards,
Devansh
More information about the LibreOffice
mailing list