We are heading towards the last stages of the program and I can feel myself wish I could move ahead fast with my work. I often contemplate in solidarity about the work I have done so far. I’ve had my ups and down in the last two months. Managaing several things at once was indeed a challenge. Learning new things everyday was an exhilarating challenge. Persistence at a problem for hours together was something I got adapted to recently.

My approach to software development has completely changed. My earlier view of treating it just as “coding” has completely disappeared. There is so much more to it. Collaboration with other members, willing to wait till the other person reviews and tests your code, approaching a problem from a design perspective, thinking about user experience, and then comes coding. Coding is pretty much the last step, and is often considered the first, which is a wrong approach. The last two months have taught me that having a naive mindset can be disastrous in any software development field.

Moving on with development, this week I focused on convert activity itself, and some of the other basic issues of it. One really cool feature that I wanted to implement was how the activity could preserve units and dimensions in the Journal object and load the same units on acivity resume. The feature in itself is not hard. The sugar toolkit provides with two methods called read_file and write_file. The former is the method read each time an activity resumes from a journal and the latter is used to write metadata about the activity state to the journal object, when the activity is stopped. Both these methods can be reimplemented as per need.

My initial approach was to save the dimension and the two units from the two Conversion entries and load them on activity start. However, I should thought of it earlier because the approach led to a broken state. The reason being I had tried to save the units via their entry number and not name, and as a result they weren’t loading correctly. The other issue I faced was how the RadioButtons that denoted each dimension were not being updated. This is because, by default, the leader of the group which was the ‘Length’ button, is always set active. I decided to manually set the current dimension as active and the PR was set. After yet around round of code review, etc, my mentor decided to remove most of the redundant code in the same PR.

The other activity on my To-Do list was infoslicer. The issue was with how there was a traceback in the logs, which at first seemed pretty harmless. One easy check is to see if the activity runs, and if does, all is well and good. But this does not hold always hold, and the activity is an example of that. The traceback being caused due to wrong handling of datatypes in a particular function call. Turns out that GTK had updated its bindings in the recent versions and that the return value for a function call was now a tuple, instead of just an object. The issue was caused by the code put in place to handle older versions of GTK.

The issue was infact much bigger. The activity supports selecting text via drag and pasting them elsewhere via drop. This feature was not working. The reason being the wrong datatype (a bool type) was being returned instead of an object in place. I fixed the issue by removing the bool return type, rather always return the relevant object, also by removing an already exiting method that was re-implemented once again.

Links to PR: Convert-activity: PR #32 Infoslicer-activity: PR #30