Recently, I worked for Notes help. Notes formerly known as Bijiben is a GNOME 3 app for writing quick notes. It is a very simple, light and easy to use application. There exist other applications also for notes keeping in GNOME git, like Tomboy and GNotes. Here is a very good comparison between these three applications.
Why it was named “Bijiben” also had a reason. Notes developer and the maintainer Pierre-Yves Lutyen was learning Chinese at the time he was developing Notes and hence he named it so. “Bijiben” means “notebook” in Chinese . Later on it is renamed to Notes.
What all I learned while working on Notes documentation is as follows:
First of all I learned how to install jhbuild. This link also proved helpful for installing jhbuild. After successfully installing jhbuild, I had to build Bijiben which was the real difficult task. The command for building Bijiben is jhbuild build bijiben. It took me complete one week to build bijiben. In Ubuntu, it is difficult to compile an application using jhbuild but not impossible. Finally, I could run bijiben using the command “jhbuild run bijiben“. I could see bijiben something like this:
Even after so much of hard work no icons for buttons were visible. But I achieved something. I reported kittykat, my mentor, about the progress. She was quiet happy with my work, though it took time. I asked, why cant I see the icons for the various buttons. She told me to run the command in the terminal jhbuild build gnome-themes-standard. WOW, now I could see the icons too. Thanks to her. Now my Bijiben looks beautiful as in the screen-shot below:
Secondly, after getting the latest version of Bijiben with me, I had to work on Bijiben help. Its index page was quiet outdated. I updated the index page and created two new pages Introduction and Rename from the scratch. Thankfully, my mentor is extremely helping and taught me every bit with great patience. I really love her for this quality of hers.
Earlier also I had worked on mallard but didn’t have idea about its various tags and their attribute values. I created the introduction page and developed the patch for it. I showed the patch to my mentor. My nick on IRC is curiousDTU. She reviewed the patch and below are the excerpts of our conversation on IRC:
<curiousDTU> Hi! this is an updated patch as per your instructions http://pastebin.com/c41yjBc2. please let me know any other correction. Thanks!
<kittykat> why do you have an inline “<links type=”topic” groups=”#first”/>” in the index?
<curiousDTU> ok it is not needed there 🙂
<kittykat> that’s correct, it’s not needed 🙂
<kittykat> and why are you using “xmlns:e=”http://projectmallard.org/experimental/“” in the introduction?
<curiousDTU> removing 🙂
<kittykat> do you know what the “xmlns” bits do?
<kittykat> (you should have a space in “introduction.page\” in the Makefile, so that it’s “introduction.page \”)
<kittykat> (and same for the figures)
<curiousDTU> “xmlns” is XML namespace. and reading further to know more 🙂
<curiousDTU> Makefile corrections done.
<kittykat> “xmlns:its=”http://www.w3.org/2005/11/its“” is the one we use most often, usually to mark stuff that doesn’t need to be translated as such, and sometimes to add comments for translators
<kittykat> GNOME is translated into 40+ languages, so working with translators is actually quite important 🙂
<kittykat> so for example, email addresses and icons should not be translated, while screenshots with text should be translated and it’s up to each author if their names are transliterated
<kittykat> does that make sense?
So this way, I learned some fine details about mallard.
Thirdly, I knew only few basic git commands. They are as follows:
(1) git clone #for cloning a repository from git. (2) git status #for knowing the current status of the local repository. (3) git commit #for committing the new change. (4) git commit --amend #for committing changes made to the previous patch. I most frequently used this command. (5) git show #for seeing the changes made in the commit. (6) git format-patch -1 #for formatting a patch after a commit.
Above are the commands which I need to create patches for the simple bugs. The problem I faced and wanted to discuss here is that I created a single patch for all the work done in all the pages by me. I mailed the patch to my mentor as usual for review. She told me to split the patch for each page that has undergone changes with a suitable commit message. I was puzzled..because I had no idea,how to split patches? Then I looked for the solution on the Internet and found, using the following commands I can split my patch in the way I want:
(1) git rebase -i HEAD~10 # interactive mode brings up an editor with a list of the last 10 commits # pick patch to split, tag with edit (2) git reset HEAD~1 (3) git add -p some-file # go through hunks and select the ones you want # using the 'e' menu option you can edit the patch (in your editor) (4) git commit -m"part one" (5) git add -i # select files to operate on (6) git commit -m"part two" (7) git commit -m"part three" -a (8) git rebase --continue
My Problems got solved. Moving on to the new ventures...