Going deeper into projects versus finding new ones

In my open source class, I've been tasked with building on my progress from my Hacktoberfest experience by doing more open source work. For this task I had to consider the following:

• working on larger open source projects
• going deeper into projects versus working on new ones
• going open source work over a longer time period versus one week per PR

For this assignment I chose to work more on doodlum/skyrim-community-shaders, a project I worked on during Hacktoberfest 2023. Working on projects I've already worked on wasn't mandatory, but was recommended over working on new projects for a couple reasons:

• I've already setup my development environment
• I'm already familiar with the code base

My work - ImGui Refactoring

My work for this Pull Request was a continuation of the refactoring work I made during Hacktoberfest 2023:
As a quick recap, Skyrim Community Shaders, or CS (for Community Shaders), uses Dear ImGui, a C++ GUI Library, to create and display menus and tooltips. My earlier work was a refactor in one module, Menu.cpp involving the multiline handling of ImGui::Text(). Previously, this module handled multiline tooltips by using consecutive calls of ImGui::Text(), which meant text wrapping could break depending on the user's window size. I corrected this by combining consecutive calls of ImGui::Text() into one.

For example,

ImGui::Text("This is one sentence.");
ImGui::Text("This is another sentence.");

...could be refactored into the following to preserve word wrapping:

ImGui::Text(
    "This is one sentence. "
    "This is another sentence.");

After doing this refactor for Menu.cpp, I was later offered to do similar refactors for the rest of the feature code. Due to my class commitments at the time, I offered to work on these changes at a later date. I was concerned with how I could thoroughly search for consecutive calls without manually reading through every file. Luckily, over the following weeks I learned of a tool that would help me greatly.

git grep, my beloved

Earlier in my open source class we learned about code reading strategies, one of which is using git grep to search for keywords/phrases within a git repository's tracked files and folders. Since I was searching for calls to ImGui::Text(), I was able to quickly search the codebase using the following command:

git grep "ImGui::Text("

Note: The double-quotes are required as my search phrase contains a special character, "(".

Running git grep above gave me output similar to below:

The entire output provides all the files that call ImGui::Text(), which was very helpful. However, I still had to manually review each file for consecutive calls to ImGui::Text() that would be refactored. To help locate these I was able to use my IDE's text search feature (Ctrl + F).

In the end I refactored tooltips in four different shader modules concerning lighting and complex materials. I didn't work on these shaders myself, but the tooltips provide explanations to the players when they use this mod to configure their game's graphics. My changes prevent word-wrapping in all multiline tooltips from breaking.

My Pull Request Experience

There was no Issue associated with my work and Pull Request, as this work was discussed in a previous Pull Request I made. Often, your planned work can be discussed on an Issue thread, but this isn't always the case. Planned work can also be discussed on social media (e.g. Twitter, Slack, Discord) or, in my case, a previous Pull Request.

Learn some Code Reading strategies

Since I've done similar work on this project earlier, I was already familiar with the codebase (at least the GUI-related code) and the kinds of changes I'd have to make. However, this work would have been tedious without git grep, as without it I would have manually sifted through each source code file. For this reason I recommend being familiar with various Code Reading strategies, such as those discussed in my blog post on Code Reading. Code Reading strategies are especially useful when working with large codebases, since you can't (and shouldn't) read every line of code to make your changes.

Have a conversation!

GitHub Pull Requests have comments, which allow contributors and code maintainers to discuss incoming changes.
In my Pull Request, I inquired about newline characters, \n, that were in the tooltips I modified. Using my previous work as an example, I took them out in my changes. However, instead of removing the original tooltips, I commented them out as a reference in case I needed to keep newline characters in my changes.

After a short discussion and a couple minor changes, I was able to remove the code I commented-out and get my PR merged.

Contributing to past projects is fun

Delving deep and making more contributions to a past project is a fun experience. Just by making a second Pull Request I've become more involved and understand a little more of the project. I even recently bought Skyrim for Steam and plan on using this mod myself during my break.