What did I do this week?

Last week, me and my mentor started testing mscolab. At first, I exposed my port through ngrok. But the network I/O were extremely slow. I couldn't demonstrate all of mscolab's features. Then we setup an AWS instance with mscolab server deployed. We could test and improve on many of its features. Some things I worked on this week:

1. Adding support to use Postgres
2. Refactoring tests, so that the library code is independent of test configurations.
3. Adding newly created projects to project-list, in real time
4. Add newly permitted collaborators to users-list in project window, in real time.
5. Fix autosave inconsistency when projects are switched

What's coming up next?

There are very few development tasks remaining. Since this is the last week of GSoC, I'd be working on documenting the code I've written, externally. That would take most of my time this week.

Did I get stuck anywhere?

Yes, I got stuck in a bad place for some-time this week. While setting up Postgres, I had to manually autoincrement sequence to assign 'id' to tables, if I explicitly insert rows. I have documented the issue and solution in this blogpost if you're interested in learning more about it.

What did I do this week?

Earlier this week, I worked on a number of major refactoring listed below.

1. displaying user and project details in project window
2. send service message for each 'file-save'
3. add user/add project features added
4. refactoring test/real data setup
5. disable action buttons for non-permitted users. 

Some parts of it have been merged with my branch in origin repository. I'm working on setting up the project for Postgres for internal usage, and disabling autosave for non-admin users. After that, I'm making a PR

What's coming up next?

Next up, are the internal testing of mscolab at my mentor's workplace. Then we can come up with bugs, and features to work on for the next and final week of development cycle.

Did I get stuck anywhere?

No, nothing bothered me for long this week. I did however come up with a design dilemma, where I had to import variables for tests as different names, and manually detect if tests are running, and then set the variable names. However, the app can't be configured to use TEST_* params. We have to set a test environment to change all those params to test params.

What did I do this week?

As discussed in the earlier blog, I worked on tests for GUI to 'checkout' to a previous version of flightpath. After creating a pull request, I parallelly started working on GUI to add users and projects. I also got the pull request reviewed by my mentor.

What's coming up next?

This week, I have to finish up on modifications suggested by my mentor. After first request gets merged, I have to work on displaying user's, project's details in chat window, and active view windows. After that, I'd have to fix an issue due to which table view can't be created more than once for mscolab. Before making the second pull request, I also have to write tests for GUI part related to creation of users and projects.

Did I get stuck anywhere?

I was stuck for a very short while trying to decide if QInputDialog works with multiple inputs, then I designed my own QLabel for my usage.

What did I do this week?

After completing tests and features for mscolab's project window and getting the PR merged, I started working on a more tricky part of the project. Introducing version control to mscolab server's storage. As explained on the previous blog, this is done to introduce some features to project. Mainly the following

1. undo/redo a particular change(commit) - TO BE IMPLEMENTED
2. checkout to a particular commit - IMPLEMENTED

I used 'gitpython' library to handle git related functionalities. For now, the commit hash is stored in 'Change' model. It might seem like it's redundant, which is true, but we'll work on this later to find a way to store every detail in the commit, to scrap the 'Change' model.

What's coming up next?

The aforementioned features are already implemented, I have to write tests before I make a PR. Once the PR is created, I will parallelly start working on GUI to create projects, users, and displaying user and project details in project window. After this, my mentor has planned a testing of added features in development server.

Did I get stuck anywhere?

There were two major places where I got stuck.

1. While introducing version control to file storage,  git commit would not work if this file is opened in 'w'(write mode) in any part of program. I had to close the opened reference, so the most recent changes are committed.
2. I couldn't find a reason to why this happened, but while opening a 'question' with PyQt's MessageBox in an event handler of QListWidgetItem's activate event, it opens multiple times if the 'QListWidget' is reloaded. Maybe because if an item is activated, and another item is added to the list in the event handler, the new item in that index is activated again, in a loop. I avoided it by setting an 'active_change_id' to keep track of the activated item's id and then manually asking an user to press a button to checkout to that change.

What did I do this week?

As it was planned the previous week, I worked on tests for GUI of mscolab's main window. Here is the link to pull-request with the tests and autosave synchronization feature.

Next important thing I worked on is the project window, which has collaborators-listing, chat feature, and 'change' listings. I've finished almost all of the features, with some finishing touches remaining for UX improvements(colorize the UI). I'll make a pull-request for this module after writing some features on Tuesday(2019-07-24). If you want to test features, please look into 'GSOC19-plant99' branch in my fork.

What's coming up next?

Next up, is writing tests for features of project window, and improving the GUI. Then this PR's review might take upto 1.5 working days, considering the amount of new changes and code introduced.

If there's still time, the next feature is to introduce version control in mscolab server's storage. This essentially means, moving from a 'file' based storage to a 'project' based storage. Why are we doing this? To introduce undo/redo functionality, basically the whole 'mss project' would be a git enabled directory with a linear-commit history. If one wants to undo a change, we checkout to the commit before, and write this text to the file, commit in front of HEAD. Thus 'undo'ing the changes introduced after that commit.

Did I get stuck anywhere?

I had a little difficult time figuring out the Widgets I had to use to build the GUI. I ended up using QListWidgets, even for chat-log, and change-log. I doubt if it's the right tool to use. But since it has not obstructed development of other modules, it is not a very big issue, and I will fix this later.

Non-technical note: This week was where every bit of work from the past two months were bundled together and put to use. I realized the importance of writing tests, especially for APIs. I could reuse the clients I wrote for tests, and could get done with things quicker. I'd recommend writing extensive tests, I know I still am missing out on more benefits of them. The note is to express a tiny bit of overjoy I feel when I see everything working nice, and makes me more confident about finishing up for the first release of mscolab.