GSoC 2024: Week 3 Report

It’s been a while since I have given any updates, so here we are.

I listed down the demos that needed to be ported according to their length (S, M, L depending on the Lines of code)

I planned to work on 3 demos daily, 1 LOC type each, which was different from how it panned out. I’ll attach the list here for it to be more clear for everyone.

Week 1

The first demo I worked on was the Dialog demo. It was straightforward, but one thing that kept confusing me was the package declarations and how to know which packages to include. Only after going through the documentation of the functions that didn't work, did I understand the exact terms to use to declare these packages.

I also added the Python port for this demo, one thing (not specific for this port) but the first time I got to know about was the use of `_parameters` which are parameters that may or may not be used by the function but are still needed by the signal calls.

Actions demo took me some time to understand and implement mostly because of the lack of understanding of how Simple Actions work and the `notify.connect` function parameters. I also needed to make some changes to make the user-visible strings according to the style guide. Another interesting thing was that the Vala formatter checks the surrounding code and then formats the rest of the code. Initially, my code was not being formatted correctly because I had missed a space when declaring the main method.

All of the code improvements/suggestions were given to me by my reviewers Diego Ivan and Lorenz Wildberg. I am thankful to them for going through each of my demo ports (No matter how messy or unclean the code was) and answering all of my questions and doubts. If you’re reading this Diego I’m sorry for my Screencast port.

Okay, the next demo I worked on was CSS Gradients. This was a bigger port and needed the creation of different methods for generating and updating the CSS values. If you need more information about what each demo does, I recommend reading blogs written by Akshay and Sriyansh. This demo uses methods of the Gtk.StyleContext class, the class is deprecated and hence the CLI produces an error when running the checks. Sonny has had to make an exception for it in the CLI to make it work.

One thing that helped me during all of the ports was to see the previously written code and understand how it was implemented. The style guide was also helpful in keeping the code clean and aligned with the other demos. At a certain point, I combined all of these along with improvement suggestions from my reviewers into a notes file.

Week 2

(This week will look more fruitful, I had good flow days this week and was starting to understand more about how the ports function).

Drawing Area demo port utilized multidimensional arrays, which in Vala are declared differently from other languages! You use arr_name[,] or arr_name[,,] where the commas represent the dimensions.

No function in GLib can convert degrees to radians. Hence, Lorenz suggested creating a function that could be used for the next GLib iteration and our demo.

Then I worked on numerous smaller ports, I’ll summarize their difficulty and things I learned from them in brief:

Frames, Label, and Menu Button demos were relatively easier to port and I was able to implement them quickly. The one thing that I was getting wrong up until here was not using explicit declarations for variables to make the code easier to comprehend.

Font Dialog demo utilizes async methods with await/yield calls to ensure that there is something returned always (required output/ error thrown). When implementing this demo in Vala I had compiler warnings stating implicit .begin() is deprecated

//Compiler throws an implicit begin warning
custom_button.clicked.connect (on_clicked);
 
//Fixed by explicitly connecting to the begin method
custom_button.clicked.connect (on_clicked.begin);

Network Monitor demo in particular took a lot of my brain cells, the whole code was rather easy to implement. The only thing that took most of my time was setting the value for the LevelBar, the value was to be fetched from NetworkMonitor, and the function that does this is NetworkMonitor.connectivity (which has a return type of enum). I did not realize that enum values can be cast into double and ended up creating a switch case iterator for the various connectivity types. The conditional loop was a better solution for the problem but Diego suggested that we cast it to double for consistency with other demos.

This week ended with a few more ports, namely Popovers, Power Profile Monitor, Spell Checker, Toggle Button, and Tooltip.

Here is your reward for reaching this far into the post

Week 3 (This may have taken longer than I anticipated)

The table of the ports? This is that table after Week 3

This week I worked on porting Progress Bar, Save File, Select Folder, and Spin Button(This demo was fun). All of the demos seemed less intimidating since they utilized similar functions and methods that I had already implemented in previous demos. Needless to say, it took extra time to port the last remaining demos because those were much longer and harder to keep track of.

Menu demo used container variables and one way to implement key and value pairs in Vala is to use HashTables (I had only heard about Hash tables being very useful before). It took me a lot of googling and trial and error to use a HashTable. Vala also supports syntactic sugar for set and get methods. This allows us to insert/lookup values to and from the table using keys and values as table indices

Eg:     content_type_params.insert ("charset", "UTF-8");
        //Instead of calling insert method, you can insert into the value of 
        //charset index of the table
        content_type_params["charset"] = "UTF-8";  

        //Similarly for lookup
        var name = query.lookup ("name");
        string name = query["name"];  

HTTP Server demo uses HashTables, it also uses Soup.Server to deliver a local host server that can handle web requests.

Maps demo was an interesting one to port, the code in Python and Javascript utilized checking for (Not a Number) NaN characters but we used float.try_parse to check if the latitude and longitude entries are valid. It checks if the number is a valid float and if possible parses it to float.

The same week I ported Session Monitor and Inhibit. I had no understanding of the demo itself until Diego explained it to me very thoroughly.

File Monitor allows you to monitor file changes and see the changes you’ve made to the file in any text editor of your choice. The only issue with this port was the method to replace the contents of the file was inserting nonreadable text and the text editor was giving me issues when opening the file.

We fixed it by moving the handler to a separate async method call. It also took a huge chunk of time to port the Notification demo into Vala only to realize it couldn’t work. When using Vala in Workbench, the code and preview run as separate processes, and hence GApplication would not be registered properly and just gives a lot of other errors that I do not understand at the moment.

Another demo that used HashTables was Scrolled Window demo. The table was used to store Orientation and Scrollbars as key and value pairs.

As of writing this blog, Screencast, and Camera demos remain to be ported. These make use of the GStreamer library. There is already a draft PR for Screencast, the implementation requires further discussion with the reviewers.

These have been the updates from my side, thank you for reading. I would again like the thank Diego and Lorenz for all their help with reviewing and improving the ports.

It is time I move to the next part of my GSoC project and work on redesigning the Workbench Library. I will be back with more updates, stay tuned for those!

Until then