Google Summer of Code Final Work Product

• Name: Praneeth Shetty
• Organisation: Python Software Foundation
• Sub-Organisation: FURY  
• Project: FURY - Update user interface widget + Explore new UI Framework

Proposed Objectives

• SpinBoxUI
• Scrollbar as Independent Element
• FileDialog
• TreeUI
• AccordionUI
• ColorPickerUI

Stretch Goals:   

• Exploring new UI Framework
• Implementing Borders for UI elements

Objectives Completed

SpinBoxUI:

The SpinBoxUI element is essential for user interfaces as it allows users to pick a numeric value from a set range. While we had an active pull request (PR) to add this element, updates in the main code caused conflicts and required further changes for added features. At one point, we noticed that text alignment wasn't centered properly within the box due to a flaw. To fix this, we began a PR to adjust the alignment, but it turned into a larger refactoring of the TextBlock2D, a core component connected to various parts. This was a complex task that needed careful handling. After sorting out the TextBlock2D, we returned to the SpinBoxUI and made a few tweaks. Once we were confident with the changes, the PR was successfully merged after thorough review and testing.

Pull Requests:

• SpinBoxUI (Merged) - https://github.com/fury-gl/fury/pull/499

TextBlock2D Refactoring:

This was a significant aspect of the GSoC period and occupied a substantial portion of the timeline. The process began when we observed misaligned text in the SpinBoxUI, as previously discussed. The root cause of the alignment issue was the mispositioning of the text actor concerning the background actor. The text actor's independent repositioning based on justification conflicted with the static position of the background actor, leading to the alignment problem.

To address this, the initial focus was on resolving the justification issue. However, as the work progressed, we recognized that solely adjusting justification would not suffice. The alignment was inherently linked to the UI's size, which was currently retrieved only when a valid scene was present. This approach lacked scalability and efficiency, as it constrained size retrieval to scene availability.

To overcome these challenges, we devised a solution involving the creation of a bounding box around the TextBlock2D. This bounding box would encapsulate the size information, enabling proper text alignment. This endeavor spanned several weeks of development, culminating in a finalized solution that underwent rigorous testing before being merged.

As a result of this refactoring effort, the TextBlock2D now offers three distinct modes:

1. Fully Static Background: This mode requires background setup during initialization.
2. Dynamic Background: The background dynamically scales based on the text content.
3. Auto Font Scale Mode: The font within the background box automatically scales to fill the available space.

An issue has been identified with TextBlock2D where its text actor aligns with the top boundary of the background actor, especially noticeable with letters like "g," "y," and "j". These letters extend beyond the baseline of standard alphabets, causing the text box to shift upwards.

However, resolving this matter is complex. Adjusting the text's position might lead to it touching the bottom boundary, especially in font scale mode, resulting in unexpected positioning and transformations. To address this, the plan is to defer discussions about this matter until after GSoC, allowing for thorough consideration and solutions.

For more detailed insights into the individual steps and nuances of this process, you can refer to the comprehensive weekly blog post provided below. It delves into the entire journey of this TextBlock2D refactoring effort.

Pull Requests:

• Fixing Justification Issue - 1st Draft (Closed) - https://github.com/fury-gl/fury/pull/790
• Adding BoundingBox and fixing Justification (Merged) - https://github.com/fury-gl/fury/pull/803
• Adding getters and setter for properties (Merged) - https://github.com/fury-gl/fury/pull/830
• Text Offset PR (Closed) - https://github.com/fury-gl/fury/pull/837

ScrollbarUI as Independent Element:

We initially planned to make the scrollbar independent based on PR #16. The main goal was to avoid redundancy by not rewriting the scrollbar code for each element that requires it, such as the FileMenu2D. However, upon further analysis, we realized that elements like the FileMenu2D and others utilize the Listbox2D, which already includes an integrated scrollbar. We also examined other UI libraries and found that they also have independent scrollbars but lack a proper use case. Typically, display containers like Listbox2D are directly used instead of utilizing an independent scrollbar.

Based on these findings, we have decided to close all related issues and pull requests for now. If the need arises in the future, we can revisit this topic.

Topic: - https://github.com/fury-gl/fury/discussions/816

Other Objectives

Reviewing & Merging:

In this phase, my focus was not on specific coding but rather on facilitating the completion of ongoing PRs. Here are two instances where I played a role:

1.    CardUI PR:
   I assisted with the CardUI PR by aiding in the rebase process and reviewing the changes. The CardUI is a simple UI element consisting of an image and a description, designed to function like a flash card. I worked closely with my mentor to ensure a smooth rebase and review process.                  
2.            
   • CardUI (Merged) - https://github.com/fury-gl/fury/pull/398
           
3.  ComboBox Issue: 
   There was an issue with the ComboBox2D functionality, where adding it to a TabUI caused all elements to open simultaneously, which shouldn't be the case. I tested various PRs addressing this problem and identified a suitable solution. I then helped the lead in reviewing the PR that fixed the issue, which was successfully merged.
   • ComboBox Flaw (Merged) - https://github.com/fury-gl/fury/pull/768
        

Updating Broken Website Links:

I addressed an issue with malfunctioning links in the Scientific Section of the website. The problem emerged from alterations introduced in PR #769. These changes consolidated demos and examples into a unified "auto_examples" folder, and a toml file was utilized to retrieve this data and construct examples. However, this led to challenges with the paths employed in website generation. My responsibility was to rectify these links, ensuring they accurately direct users to the intended content.    

• Updating Broken Links (Merged) - https://github.com/fury-gl/fury/pull/820

Objectives in Progress

FileDialogUI:

An existing FileDialog PR by Soham (#294) was worked upon. The primary task was to rebase the PR to match the current UI structure, resolving compatibility concerns with the older base. In PR #832, we detailed issues encompassing resizing FileDialog and components, addressing text overflow, fixing ZeroDivisionError, and correcting ListBox2D item positioning. The PR is complete with comprehensive testing and documentation. Presently, it's undergoing review, and upon approval, it will be prepared for integration.    

• Soham's FileDialog (Closed) - https://github.com/fury-gl/fury/pull/294
• FileDialogUI (Under Review) - https://github.com/fury-gl/fury/pull/832

TreeUI:

Continuing Antriksh's initial PR for TreeUI posed some challenges. Antriksh had set the foundation, and I picked up from there. The main issue was with the visibility of TreeUI due to updates in the set_visibility method of Panel2D. These updates affected how TreeUI was displayed, and after investigating the actors involved, it was clear that the visibility features had changed. This took some time to figure out, and I had a helpful pair programming session with my mentor, Serge, to narrow down the problem. Now, I've updated the code to address this issue. However, I'm still a bit cautious about potential future problems. The PR is now ready for review.    

• TreeUI (In Progress) - https://github.com/fury-gl/fury/pull/821

GSoC Weekly Blogs

My blog posts can be found at FURY website and Python GSoC blog.
 

Timeline 

What did you do this week?

During this week, I initiated my work on the FileDialog PR, which had been started by Soham. The initial version of the FileDialog can be found at #294. To start, I focused on rebasing the PR. Since this PR was based on an older version, there were some updates to the overall UI structure that needed to be addressed for compatibility. While handling this, I identified a set of issues that I documented in the current PR #832. These mainly revolved around:

1. Resizing FileDialog and realted components.

2. Rectifying the text overflow problem.

3. Dealing with a ZeroDivisionError.

4. Fixing the positioning of items in the ListBox2D.

I systematically approached each of these challenges:

Resizing FileMenu and Related Components: This was a fairly complex task since it involved intricate dependencies, such as the FileDialog relying on the FileMenu, which, in turn, was dependent on ListBox2D and Panel2D resizing. To make the process manageable, I decided to progress incrementally in a seperate PR a bit later.

Text Overflow Issue: The problem with text overflow was rooted in our previous approach, which involved executing these actions only when the TextBlock2D had a scene property. Although this approach suited the previous version of TextBlock2D, the recent refactoring led to the removal of this property. The scene was previously utilized to determine the text actor's size. However, we had new methodologies to calculate these sizes, which are detailed in #803.

Addressing ZeroDivisionError: The ZeroDivisionError emerged when the total number of values were same as the number of slots. The issue lay in the separation of these values for calculating the scrollbar's height parameter. Unfortunately, this calculation error occurred when this would return us zero while updating the scrollbar. To counter this, I implemented a conditional check to ascertain whether the value is zero or not.

Correcting ListBox2D Item Positioning: Another challenge I encountered related to the improper positioning of ListBox2D item's background. When a slot was not visible, its background was resized to zero, and visibility was set to off. Consequently, during the calculation of updated positions, the height was considered zero, leading to mispositioning. I resolved this by refraining from resizing and solely toggling visibility, achieving the desired result.

Did you get stuck anywhere?

Among the challenges I faced, one notable instance involved addressing the visibility issue in TreeUI. Despite my attempts at various solutions, none yielded the desired outcome. The TreeUI exhibited either full visibility or no visibility at all. In this situation, I sought guidance from my mentor to find a viable solution.
 

What is coming up next?

The FileDialog implementation is nearly finalized, and my plan is to work on any review, feedback or suggestions that might arise. Following this, I will shift my attention towards addressing the TreeUI.

What did you do this week?

Building upon the progress of the previous week, a major milestone was reached with the merging of PR #830. This PR added essential "getters" and "setters" for the new features of TextBlock, making it easier to handle changes. This, in turn, facilitated the integration of SpinBoxUI with the updated TextBlock.

However, while working on SpinBoxUI, a critical issue emerged. As SpinBoxUI allows users to input characters and symbols into an editable textbox, it posed a risk of program crashes due to invalid inputs. To counter this, I introduced a validation check to ensure that the input was a valid number. If valid, the input was converted; otherwise, it reverted to the previous value. After thorough testing and review, PR #499 was successfully merged.

Meanwhile, a concern with the textbox's behavior was identified when SpinBoxUI was scaled to a larger size. Specifically, the text occasionally touched the top or bottom boundary, creating an overflow appearance. Although initial solutions were attempted, the complexity of the issue required further consideration. This issue has been documented in more detail in Issue #838, where it is marked as a low-priority item.

Did you get stuck anywhere?

The challenge of the week centered around addressing the textbox's overflow behavior in SpinBoxUI.

What is coming up next?

Looking ahead, the focus remains on refining the FileDialog component, as the significant progress with TextBlock and SpinBoxUI prepares us to shift attention to other aspects of development.

What did you do this week?

This week, my focus shifted to the SpinBoxUI after wrapping up work on TextBlock2D. SpinBoxUI is a component that allows users to select a value by spinning through a range. To ensure a smooth transition, I made adjustments in SpinBoxUI to align it with the recent updates in TextBlock2D. To make things even clearer and more user-friendly, I initiated a continuous code improvement process. I introduced setters and getters that enable easier customization of TextBlock2D's new features, such as auto_font_scale and dynamic_bbox. These tools simplify the process of adjusting these settings, and you can see the ongoing changes in pull request #830.

Simultaneously, I worked on improving the FileDialog component. Since the FileDialog PR was based on an older version, it required updates to match the recent developments in TextBlock2D. This involved restructuring the code and making sure that everything worked smoothly together. You can checkout the progress here at PR #832.

Did you get stuck anywhere?

Thankfully, this week was quite smooth sailing without any major roadblocks.

What is coming up next?

Looking ahead, my plan is to finalize the integration of the updated TextBlock and SpinBoxUI components. This entails making sure that everything works seamlessly together and is ready for the next stages of development.

What did you do this week?

Continuing from the previous week, it seemed like we were almost done with the TextBlock2D, but there remained a final task of addressing conflicting issues. Being a core part of the UI, TextBlock2D had a few compatibility problems with certain other UI elements.

The default behavior of TextBox2D now includes a dynamic bounding box, which scales automatically based on the contained text. Users can customize this option through a simple flag setting. However, this change affected some UI elements like ComboBox2d, which relied on the default textbox size. Consequently, I had to make updates to ensure compatibility. Additionally, the default initialization of the TextBlock2D was completely static, which led to the possibility of the text extending beyond the background and failing certain tests. To tackle this, I made adjustments to the overflow helper function in the test_elements.py file. After a few tweaks and issue resolutions, the PR was ready for review and was successfully merged after passing the review process.

Did you get stuck anywhere?

I encountered some peculiar test failures that were indirectly related to the TextBlock2D which at first glance didn't came up. Although after some debugging and a thorough line-by-line analysis, I managed to identify and resolve them.

What is coming up next?

My next priority will be completing the SpinBoxUI now that the TextBlock2D is fixed and successfully integrated.