What did I do this week?

This week I had limited tasks to do, mostly tasks related to existing PR's. Other than some minor fixes I had to implement some more things in Tree2D which included some minor UI fixes, some changes in tutorial, adding tests. Below is the detailed description:-

1. Tests, tutorial changes, UI fixes for Tree2D: The Tree2D lacked some things like proper UI resizing, relative indentation, tests for the UI class. These were added with this PR. Currently, the indentation, resizing needs some improvement, which will be fixed after feedback from this week's meeting. Also, tests for Tree2D, TreeNode2D were added as well.
2. Updating Panel2D tests, re-recording the events: This PR is almost done with just some tests blocking the PR. The tests were added this week, but tests for some callbacks that are associated with window event are still not added. This is because there is no way to count the WindowResizeEvent without actually using the API of the window provided by the OS. This can become very complicated very soon so, these tests may be added in the future.
3. Fixing the failing CI's for #443: The CI was failing on this PR and needed some fixing which was done this week. This PR still needs some refactoring before the all CI's pass. This will hopefully be fixed before this week's meeting.
4. Addressing all comments regarding #442: Previously, it was pointed out that the some code can be extracted into a function and can be reused in other methods. So, this week the extracted method was updated to reuse even more code and now almost no code is repeated
5. Adding has_border flag in Panel2D: Adding a has_border flag in Panel2D: Previously, to create the borders 4 Rectangle2D's were used and they were created everytime even when border_width was set to 0. This would take a lot of wasted system resources. To fix this, a flag is added in the the constructor which is by default set to False. If false, the borders are not initialized and the resources are saved.

Did I get stuck anywhere?

Fortunately, this week I didn't get stuck anywhere.

See you guys next week!

What did I do this week?

This week I had relatively few tasks and most of them were to fix some bugs/design flaws that were discussed in last week's meeting. Other than that, I had to implement a few things in the Tree2D UI element that will be discussed in detail below. I also had to update some existing PR's in order to make things work well. Below are the list of things I worked on this week:-

1. Extracted Button2D class from elements to core: Button2D was placed in elements during the UI restructuring. The problem with that was that Button2D was needed in other UI elements outside UI elements present in elements in Panel2D. SO, it was decided to create a rule that only the UI elements that do not depend on any other UI element are allowed to be placed in core UI elements. Button2D does not depend on any other UI element so it was extracted from elements to core.
2. Adapting GridLayout to work with UI elements: This was a PR that aimed to add support for UI elements to be placed in a grid fashion. the problem was that there still some circular imports even after UI restructuring, primarily because UI was being imported in the layout module that in turn indirectly imported some UI elements making them circularly dependent. To remove the circular imports, it was decided to determine the UI element by checking for a add_to_scene method attribute in the instance. I updated the existing PR to implement the same.
3. Continuing my work on Tree2DThe Tree2D lacked some important things related to design and visual aspect of it. Before, if the children of any node exceeded its height they would just overflow. To prevent this I came up with a few solutions two of which were to either add a scrollbar on the overflowing node or to simply auto resize the parent node. Currently, there is no global API for the scrollbar and it has to be manually setup in a UI element, this will be hopefully implemented in the near future probably using layout management. Till then the auto resizing has been implemented for the nodes. In future, an option for scrollbar will be added.

Did I get stuck anywhere?

I am still stuck with adding tests for panel resizing PR. As it needs windows events to be recorded as well. I tried to propagate the event to the interactor first but that just lead to that particular event being registered multiple times. I will try to find a workaround for it.

What is coming up next?

If the Tree2D gets merged by this week then I'll probably work on other UI elements. Other tasks will be decided in the next meeting

See you guys next week!

What did I do this week?

The UI restructuring was finally merged this week. This means UI is now a submodule in itself and provides different UI elements based on their types which are, core, elements, containers and some helper methods/classes. So, this week my main tasks were to rebase and fix merge conflicts of my open PR's. Other than that, I had to continue my work on Tree2D UI element and finish the remaining aspects of it. Also, I had to create an example demonstrating how to use the newly added UI element. Many use cases were discussed in the open meeting like, an image gallery which displays preview image on the title and when expanded reveals the full scale image. I am thinking of adding multiple examples for the Tree2D to brainstorm on its certain features. Also, I had this annoying bug in Panel2D which didn't allow it to be resized from the bottom right corner. It was resizing from the top right corner. I had to address this bug as well. Below are the tasks in detail:-

1. Rebasing all PR's w.r.t the UI restructuring: As discussed in the earlier blogs, due to circular imports and large size of the UI module, a bit of restructuring was required. This week the PR that converts the UI into a sub module was finally merged. This meant I had to fix all the merge conflicts and rebase all UI related PR's. So, I rebased all the UI related PR's and fixed the merge conflicts. Currently, there are still some PR's that need some attention as still some of the imports are circular in nature. This means if the issue is correct then some more restructuring is required, which will be hopefully done in the near furture
2. Continuing the work on Tree2D: This week I continued my work on Tree2D, TreeNode2D. I had to fix/add multiple features on both the classes but my priority was to fix the looks of the UI element as well as make it easier for the user to manipulate the UI element. The first thing that I fixed was node offsetting, when a node is collapsed and expanded the nodes below the current node should also offset. Previously, only the child nodes within the same parents were offset and not the nodes/parent beyond that. With some minor adjusting, now the nodes are offset recursively and all child/parent nodes below the current nodes are offset. Secondly, before only a node could be added to a node which meant it wasn't any easy way to add any other UI element to a node but with some updates/fixes any UI element can be added to a node. Also, the Tree2D lacked some properties/methods to easily manipulate it. So, i added some properties/methods that allow to easily/efficiently manipulate individual node inside the Tree2D. Below is the current state of the Tree2D. In the below tree, two panels are added to a child node after the tree has been initialized. Also, the coordinated of the child elements are totally fluid i.e they can be placed anywhere inside the content panel by passing normalized or absolute coordinates.
3. Fixed Panel2D bottom corner resizingPreviously, the panel would not resize from the bottom left corner but it would resize from top right corner. I didn't understand what was going wrong and was stuck on this for a long time. But I finally figured out the problem, I was calculating the Y-offset wrong as well as the panel resized from the top side instead of bottom. With some minor tweaking the bug was gone and the panel resizes correctly from the bottom right corner.

Did I get stuck anywhere?

I got stuck on recording events for the updated panel UI element. The panel updates w.r.t the window size but I couldn't figure out how to record the events invoked by the window. Unfortunately, I still haven't figure out how this will be done. My guess is that I have to propagate the event first to the interactor and then to the UI element.

What is coming up next?

I will probably finish up the GridLayout, Tree2D UI along side some other UI's. This will be decided in the next meeting

See you guys next week!

What did I do this week?

This week I had very few tasks to do, almost all of them revolved around UI elements and adding stuff to the UI module. Earlier, it was pointed out that due to some design issues, importing certain modules into others caused circular imports which led to importing the specific modules inside a class/method which is not the best approach. This will be resolved as soon as the PR that fixes this issue is reviewed/merged in the codebase. In the meantime, all the PR's related to UI will be on hold, which is why this I had few tasks this week. The tasks are described below in detail:-

1. Addition of watcher class in UI:This is finally done, as described in the previous blogs this was something that was on hold for a long time. Primarily, due to other tasks I couldn't work on this but this week due to less tasks I was able to complete the watcher class and create a PR. This PR adds support for a watcher class in the UI elements. The purpose of this class is to monitor a particular attribute from the UI element after it has been added to the scene. If the attribute changes in the real time, a user defined callback is triggered and the scene is force rendered. Currently, if any attribute of the UI element changes after it is added to the scene it does not get updated accordingly. The only way to update the UI element would be to add a custom user hook that will be triggered when a particular event that can change the attribute is invoked. This is highly ambiguous as some unmonitored event can easily change many attributes of the UI element. Also it would be really hard to add user hooks for so many events. The watcher class does this automatically, it monitors the attribute for changes and if the attribute changes, a user defined callback is triggered. If this is something that is required in the UI module, then in the future a good addition would be to monitor the UI element instance as a whole instead of a single attribute .
2. Addition of Tree UI in the UI module: Another task for this week was to work on either Tree UI or the Accordion UI. I chose to work on Tree UI as it is very interesting to implement and the logic for Tree is almost similar to that of an Accordion. So far, I have managed to implement TreeNode2D. The Tree UI contains several nodes and each node can have its own sub-nodes/children. Also, each node has an expand/collapse button which can be used to chow/hide the underlying children. The Tree UI would take some sort of data structure that contains nodes/sub-nodes and convert each node to TreeNode2D and add all the processed node to the main Panel. So far this the result I have achieved:
3. Resize Panel2D on window resizingThis PR adds support for resizing Panel2D on WindowResizeEvent. This means that the Panle2D resizes itself with respect to the chnaged window size. It also retains its maximum possible size and does not overflow. Also, this PR adds support for resizing the Panel2D for the bottom right corner. A placeholder button is placed at the bottom right corner of the Panel2D and when it is dragged by the placeholder the Panel2D resize accrdingly. Below is an example:-
4. Also, I did some testing of GridLayout when placed inside a resizable Panel2D. This will need to be worked on before advancing any further. Currently the elements present in the Panel2D do not resize properly w.r.t the changed panel size. Hopefully, this will be fixed in the future PRs.

Did I get stuck anywhere?

Fortunately, I did not get stuck this week.

What is coming up next?

The tasks for the next week will be decided in this weeks meeting.

See you guys next week!

What did I do this week?

This week my tasks revolved around layout and UI elements. The primary goal for this week was to adapt the GridLayout to work with different UI elements. Currently, GridLayout just supports vtk actors and not UI elements, my task was to modify the class to support UI elements. The other tasks for this week are described below in detail:-

1. Adapt GridLayout to support UI elements: This was the main task for the week and the aim for this was to actually modify GridLayout to support UI elements. This was not possible before because GridLayout only supported vtk actors (because of certain methods only being provided by vtk actors). I modified the main class itself along with some utility functions. The problem that I faced during this was circular imports. Currently, the structure of FURY doesn't allow certain modules to be imported into other modules because of circular imports. A way to get around this was to actually import the modules inside the methods but this is not ideal always. This will be fixed in the future PRs where the UI module will be redesigned. I also added support for grid position offsetting, which basically means that the position of the UI elements that are placed in the Grid can be offset by a global offset passed in the constructor of GridLayout class. Below is an example showing the current state of GridLayout with different UI elements:- . I also created a brief example to demonstrate how to use GridLayout of different cellshapes with UI elements link to which is here
2. Reviewed the FileDialog2D PR: This PR added support for FileDialog2D in the UI module. The PR needed to be reviewed in order to merge it as soon as other required PRs were merged. One of the mentors already reviewed the PR briefly my job was to review the PR for any remaining bugs.
3. Study #422 PR to understand contours around the drawn markers: In my previous week's tasks I created a PR to add support for borders in Panel2D. The borders were individually customizable just like in CSS which meant 4 Rectangle2D objects were needed to represent border in each direction. This is not ideal for a scenario where a lot of Panel2D are present in the scene as it can be performance taxing. A possible solution for this was to actually look how this was implemented in the #422. This PR allowed drawing millions of markers in one call that too from the GPU. Interestingly, each marker had a contour surrounding it which is exactly what we needed for Panle2D. This is something that can be considered in the future for border implementation in other complex UI elements.
4. I also continued my work on the watcher class that I mentioned in the previous week's blog. The work for this is almost done and just needs some tests implemented, which should be done soon

Did I get stuck anywhere?

Fortunately, I did not get stuck this week.

What is coming up next?

Next week I would probably continue to work on GridLayout and possibly other layouts as well, other tasks will be decided in the next meeting.

See you guys next week!