Google Summer of Code 2025 - Daily logs

GSoC_BRLCAD_arbalest_logo

Tips on how to read the logs:

In the “PRs” section you will find all the pull requests (PRs) related to my Google Summer of Code 2025 project.

In the “Logs” section instead you will find what I worked on each day. Most of the features/bugs I worked on each day are underlined and have a superscript number ^#n. This number is equivalent to the id of the PR that contains the underlined features/bugs. This was done to show in which PR my work went each day.

If the superscript number is ^x, it means that the feature that I worked on was discarded etiher to focus on more important features or because my idea/approach was wrong.

PRs

Arbalest

PR#59 = Removed using directives in header files
PR#60 = Reverted the hacks done to create a personalized title bar and restored the “standard Qt” look for the title bar
PR#61 = Removed some superfluous MainWindow’s methods and memory waste
PR#62 = Standardized the QStyleSheet “arbalest_simple.qss” to appear the same way on Windows (Windows 11) and Linux (Ubuntu 24.04.1 LTS)
PR#63 = Added a dedicated method that sets UI elements icons and added more theme variables for icon colors
PR#64 = Added support for changing themes at runtime (without having to close and reopen the application)
PR#66 = Completely redesigned the ObjectTree class to better reflect how a “.g” database is structured (in order to handle better handle borderline situations) and to greatly improve building time speed (more info here)
PR#67 = New console QWidget (based on libqtcad’s QgConsole), that supports the execution of GED commands, command completion, object names completion and command history

MOOSE

PR#3 = Modified Parse() method so that it returns additional informations regarding the command execution
PR#5 = Changed callbacks argument from Database::Object (the actual object) to const char* (the object name) in order to avoid issues related to using rt_db_get_internal() inside a callback function (these issues are better described in this and this messages)

Logs

Community Bonding Period:
- 05/08 Thu: Discovered that my project got accepted! 😊🎉
- 05/09 Fri: Dealt with all the GSoC-related bureaucratic stuff
- 05/10 Sat: Created this repo to share with my mentors what I am working / have worked on
- 05/12 Mon: Made a quick fix to revert the hacks done to create a personalized title bar and restore the “standard Qt” look^#60. For now I tested this code only on Ubuntu 24.04.1 LTS
- 05/13 Tue: Started working on prototyping a basic CLI in order to try to identify possible issues that could arise^#67 (so that I can discuss them with the mentors before the Coding Period starts)
- 05/14 Wed: Participated in the “Welcome 2025 Contributor talk and Q&A” by the GSoC team
- 05/15 Thu: Kept working on the CLI prototype^#67
- 05/19 Mon: Tried to build and compile brlcad, MOOSE and arbalest on Windows 11, but without any luck (for some reason arbalest cannot execute properly because it does not find Qt6OpenGLWidgets). Although, I spotted a bug that can be easily solved: when compiling arbalest, I got the error rpcndr.h: 'byte': ambiguous symbol (this is a known issue with Windows headers). To fix it, I simply removed the using namespace std; in Utils.h, and I then changed all the few instances where this statement was meaningful by manually adding std::^#59
- 05/20 Tue: A storm caused a problem with my Internet Service Provider in my local area, so I didn’t have Internet. Anyway, I kept trying to build arbalest on Windows 11, but with no success unfortunately
- 05/21 Wed: Still no Internet. I kept working on the CLI prototype^#67
- 05/22 Thu: Internet got fixed finally. Also I kept working on the CLI prototype, particularly exploring if it is possible to use the already created QgConsole (in libqtcad)^x
- 05/23 Fri: Kept working on the CLI prototype and kept exploring libqtcad’s QgConsole^x
- 05/25 Sun: Started working on the new theme creator feature^x, focusing on how to make it so that themes can be changed at runtime (without closing and reopening the application)
- 05/26 Mon: Kept working on the new theme creator feature^x
- 05/27 Tue: Found a way to make it so that themes can change at runtime without restarting the application^#64. I need to make it sure that it works correctly in all possible cases
- 05/29 Thu: Worked on the CLI prototype^#67, focusing on the best way to bridge or reuse qtcad’s Qt Widgets without breaching arbalest’s clean and easy-to-scale implementation
- 06/01 Sun: Video chat with BRL-CAD’s old and new GSoC contributors and mentors before the Coding Period officially begins
Coding Period (1st half):
- Week 1:
  - 06/02 Mon: Prepared PR#59 and PR#60 that I will do after I can test them on Windows 11. Kept trying to build arbalest on Windows 11.
  - 06/03 Tue: Worked on fixing how arbalest themes appear on Linux^#62. Kept trying to build arbalest on Windows 11
  - 06/04 Wed: Finally built arbalest on Windows 11! Tested and opened PR#59. Tested PR#60 on Windows 11
  - 06/05 Thu: Participated in the “Special Q&A session regarding the Coding Period” by the GSoC team. Opened PR#60
  - 06/06 Fri: Worked on standardizing how themes look on Linux and Windows 11^#62
  - 06/07 Sat: PR#59 and PR#60 got merged!
- Week 2:
  - 06/09 Mon: Worked on standardizing how themes look on Linux and Windows 11^#61,#62
  - 06/11 Wed: Finished standardizing how themes look on Linux and Windows 11^#62,#63
  - 06/12 Thu: Worked on a few bugs related to how themes look on Linux and Windows 11^{#61,#62#,#63,#64} (e.g: icons colors, refreshing icons at runtime, refreshing properties at runtime, refreshing viewports background colors at runtime, …)
  - 06/13 Fri: Fully implemented support for changing themes at runtime^#64
  - 06/14 Sat: Ironed out the new style and themes^#62 and the new feature for changing themes at runtime^#64
  - 06/15 Sun: Opened PR#61, PR#62 and PR#63. PR#61 got merged!
- Week 3:
  - 06/16 Mon: Opened PR#64. PR#62 and PR#63 got merged!
  - 06/17 Tue: PR#64 got merged!
  - 06/19 Thu: Started working again on the CLI prototype^x. The first goal is to find the best way to use MOOSE to connect arbalest and libqtcad
  - 06/22 Sun: Tried building a MOOSE module that will act as a C++ layer for libqtcad^x
- Week 4:
  - 06/23 Mon: Kept exploring the best way to have a MOOSE module that will act as a C++ layer for libqtcad^x
  - 06/24 Tue: Worked on the new CLI, focusing especially on the QWidget side of the CLI^#67
  - 06/26 Thu: Studied how libqtcad is implemented as deeply as possible, in order to understand how it can be connect with MOOSE and arbalest
  - 06/28 Sat: Kept studing how the libqtcad library works, focusing on understanding if it is possible to use its contents for arbalest
- Week 5:
  - 06/30 Mon: After more testing, and after confronting my mentors, I came to the conclusion that there is no way to connect the libqtcad library to MOOSE. This is because there is no way to connect them while preserving the main idea behind MOOSE, that is to be “a thin layer on top of BRL-CAD’s core libraries”. Maybe directly accessing the libqtcad library from arbalest could be a good temporary solution?
  - 07/01 Tue: Explored a way to improve the current ObjectTree class^#66, which handles the creation of a tree data structure that represents the opened database. The ObjectTree needs to be improved to support the GED commands that the new CLI will execute
  - 07/03 Thu: Finalized a plan for how to insert a functioning CLI inside of arbalest, that can handle 99% of the GED commands^#66,#67 (MOOSE will handle the execution of commands, while the QgConsole defined inside libqtcad will be used to create the actual QWidget console)
  - 07/04 Fri: Submitted my plan to the mentors and started working on it^#66,#67
  - 07/05 Sat: Discovered, with the help of my mentors, a problem regarding how “in-memory databases” are handled by libged (some GED commands do not work with “in-memory databases” yet, as they are a recent addition). In the mean time, I tried to see if implementing the QgConsole (defined inside libqtcad) directly into arbalest (without passing through MOOSE) would make sense, but it doesn’t^x
- Week 6:
  - 07/07 Mon: Worked on improving the current ObjectTree class^#66. Finding a lot of issues to fix. The main one is having a way of knowing which objects in the database were added/modified/killed by a CLI command, without having to rewrite a GED parser
  - 07/08 Tue: Showed a prototype of the CLI to my mentors, and discussed with them how to tackle the many issues that come with supporting all GED commands
  - 07/09 Wed: In order to know which objects in the database were added/modified/killed by a CLI command, MOOSE should be expanded so that it can support the usage of dbi_changed_clbks() and dbi_update_nref_clbks() (these are librt method that call a specified function when an object in the database changes). These features will be implemented by my mentors
  - 07/10 Thu: Kept working on improving the current ObjectTree class, so that it can support many situations that are now buggy^#66 (eg: killed objects inside a database, combinations that reference items that do not exists)
  - 07/11 Fri: Modified the ObjectTree so that now, instead of using a bunch of hashmaps and sets to represent all the items of the tree, it uses the 2 classes ObjectTreeItem (used for items in the tree) and ObjectTreeItemData (used for objects in the database)^#66. Now the ObjectTree is clearer and more efficient
  - 07/12 Sat: Increased the amount of informations that the ObjectTree can store about the database objects, so that it can support killed objects and combinations that reference non-existent object in the database^#66 (and, maybe in the future, support more advanced features)
- Midterm evaluation: Passed!
Coding Period (2nd half):
- Week 7:
  - 07/14 Mon: Improved the building time of the ObjectTree significantly^#66. My calculations, from a pool of 39 generic databases, show that the new building time decreased by around 66.4% (by 24.3% in the worst case, and by 97.8% in the best case)
  - 07/15 Tue: Created a first connection from the new ObjectTree to the actual GUI widgets^#66
  - 07/16 Wed: Opened PR#66, showing how the new ObjectTree builds, how it works, and how it connects to the GUI (used the ObjectTreeWidget as an example)^#66
  - 07/17 Thu: Fixed a few bugs related to the new ObjectTree^#66, and pushed these changes to the PR#66
  - 07/20 Sun: My mentors created a way for MOOSE to signal database changes. I’m working on using these methods to check when the new ObjectTree gets changed, and update the GUI accordingly^?
- Week 8:
  - 07/21 Mon: Copied the qged console, and started making some modifications to adapt it to arbalest and MOOSE^#67
  - 07/22 Tue: Kept working on the console QWidget^#67
  - 07/23 Wed: Made the CLI able to execute commands using the correct Database (the one of the currently active Document)^#67
  - 07/24 Thu: Worked on how the console and completer look^#67 (eg: QStyleSheet, events, how the results of commands are printed in the console)
  - 07/25 Fri: Finished working on the new CLI^#67 (ironed out the last things)
  - 07/26 Sat: Tried working on implementing ged_cmd_completions() and ged_geom_completions() into CommandString^x, but my solution was not good enough, so my mentors took care of it by implementing ChangeSignalHandler
- Week 9:
  - 07/28 Mon: Finished working on the new CLI (made it so that the command/objects completer works and ironed out the last things)^#67
  - 07/29 Tue: Opened PR#67, containing a QWidget for a CLI. The console is a simplified clone of QgConsole, the console defined in libqtcad and used by qged. It uses MOOSE instead of calling brlcad libraries directly, and it supports command completion, geometry object names completion, and obviously the execution of commands^#67
  - 07/30 Wed: Opened PR#3, containing a new method for MOOSE’s CommandString module, that enables Parse() to give more information regarding the execution of a GED command^#3. Added license, copyright notice and support for multi inputs commands^#67 to PR#67
  - 07/31 Thu: Reworked PR#3, following the directions of my mentors^#3. Participated in “GSoC Final Submission Guidelines Info Session” by the GSoC team
  - 08/01 Fri: Went back on implementing the database change callbacks ChangeSignalHandler^? (added to MOOSE previously by my mentors), in order to update the GUI when the database gets changed.
  - 08/02 Sat: Kept working on implementing the database change callbacks ChangeSignalHandler^?. Also had a discussion with my mentors regarding PR#3
  - 08/03 Sun: Made some small fixes^#3 to PR#3. Finalized PR#66 by moving the entire logic to the new ObjectTree^#66
- Week 10:
  - 08/04 Mon: Added support to commands that request to close the opened document to the console^#67 in PR#67
  - 08/05 Tue: Added support for non-existent objects to ObjectTreeWidget^#68
  - 08/06 Wed: Worked on implementing ChangeSignalHandler to the new ObjectTree^?
  - 08/08 Fri: Found 2 big issues related to using the new MOOSE’s ChangeSignalHandler, particularly regarding the usage of rt_db_get_internal() inside a callback function (these issues are better described in this message). My mentors suggest that maybe ChangeSignalHandler should maybe take const char* objectName as an argument instead of const Object& object (to avoid getting the reference of a non-existent object). PR#3 got merged!
  - 08/09 Sat: Proposed a solution to fix an issue regarding MOOSE’s Parse() new additional informations causing problems with the execution of certain commands^x, but my solution was way too farfetched, and could have been solved in a much simpler way. My mentors took care of the issue instead. Made some adjustments to the console to adapt to the fixes made to MOOSE’s Parse()^#67 in PR#67
  - 08/10 Sun: PR#67 got merged!
- Week 11:
  - 08/11 Mon: Found another issue related to using the new MOOSE’s ChangeSignalHandler, particularly regarding the usage of rt_db_get_internal() inside a callback function (these other issue is better described in this message). To fix this and the previous issues I opened PR#5, which changes ChangeSignalHandler argument const Object& object to const char* objectName (to avoid getting the reference of a non-existent object)^#5. PR#5 got merged!
  - 08/13 Wed: My VM got corrupted, so I had to redo a fresh OS download and build/compile arbalest, MOOSE and arbalest again. In the mean time I reworked how the “final project report” page will look (inside this repo)
  - 08/14 Thu: Kept reworking how “final project report” page will look
  - 08/15 Fri:
  - 08/16 Sat:
  - 08/17 Sun:
- Week 12:
  - 08/18 Mon:
  - 08/19 Tue:
  - 08/20 Wed:
  - 08/21 Thu:
  - 08/22 Fri:
  - 08/23 Sat:
  - 08/24 Sun:
- Final evaluation:
  - …

Resources

Videos

New Arbalest style and themes on Linux (Ubuntu 24.04.1 LTS) with theme change at runtime:

Old Arbalest style and themes on Linux (Ubuntu 24.04.1 LTS)

Images

New Arbalest style and light theme on Windows (Windows 11) with theme change at runtime:

Old Arbalest style and light theme on Windows (Windows 11):

New Arbalest style and dark theme on Windows (Windows 11) with theme change at runtime:

Old Arbalest style and dark theme on Windows (Windows 11):