The final evaluation period is here. Week 3 was also when my college commenced, which is situated in a far-away village, 220 kilometers from the nearest city/civilization. Calling it a village would be too modest, wheras a city/town might give a wrong image. The journey from my hometown to college takes me 12 hours of continuous travel; bus, flight and train as well. I was extremely tired in the first week, running around and setting up my room, clothes, registration, takes up quite an effort. Not to mention the temperatures here can go beyond 35°C.

I decided to start off with my Phase 3 set of issues. I picked up Convert activity first, as I had some experience with it before. The activity is about converting values between units. The activity supports upto 8-10 different dimensions, including storage, energy, force and so on.

The original issue I started off with was the redesign of the activity. In order keep the design minimal, there was only one Entry widget to input the value to convert. A flip button handled the direction in which the conversion took place. However, despite the minial design, the who activity could be smoother with two separate entries. This would remove the need for the flip button as well.

I began working on it immediately and realised that the direction of the conversion is important. And essentially what change triggers the conversion in what direction. Having methods and signals handled individually for each entry would require a lot of code, and most of the code would be similar, hence introducing a lot of redundencies. At the same time, having a common set of methods would invite more parameters and the way they are passes becomes important to understand the logic behind the conversion. I had to spend a lot of time in trial and error to figure out what would be the most optimum way to change code, with minial change and yet fully functional and capable.

I decided to use what I termed as a layered design. Have the signal handlers individual for each entry and unit, but instead have the function that the handlers call to be common. That way, I can still pass the required parameters and still keep the code length in check and avoid redundencies. The design came out well, but it didn’t cover the whole space. I decided to re-add some of the features from the old design, such as the Conversion Text. After the initial code review, I made further changes in terms of variale names, flake8 errors, order of code and so on, but with very few functional changes.

The other issue I worked upon was the issue of showing the conversion ratio between any two units. While it might seem redundant and pointless, it has a good learning value. Children from the age of 3-12 often find it hard to understand the conversion methods, and thus including a conversion ratio between every set of units is ideal and helpful to learn. I began working immediately, but I chose to base it upon the present master. However, since the design of the ayout and activity were going to be changed sooner or later, I thought of basing my changes on top of the PR rather than master, but went against it, thinking it would be better to treat it as two separate features. After all, I could just rebase my changes later on (Might have to resolve conflicts but that is just a part of the process). The PR itself was simple, and I got a minial working patch out.

I decided to work on it further after redesign PR was merged.

Links to PR Convert-activity: PR #30 [Covert-activity: PR #31] (https://github.com/sugarlabs/convert/pull/31)