After roughly porting GTG and liblarch to gtk3, I was supposed to working on debug to make the porting branch more stronger, or in other words, apply coverage [1] into current porting branch. But after some discussion with mentor, we change the plan and decide to port GTG and liblarch to python3 first.
Porting liblarch to python3 is really smoothly. After using official 2to3 script, everything seems to work fine only with some little modificaiton. But I encounter some problem when try to port GTG to python3, cause GTG uses a third party module, `configobj`, to deal with the configuration processing. The problem is that `configobj` has no official python3 port [2]. Though there are some other talented guys ported it to python3 [3], but using unofficial configobj will make it difficult for GTG to release and distribute. So I have to port configobj to some other alternatives. Fortunately, there is an usable alternative in python official library. It’s called `ConfigParser` in python2 or ‘configparser’ in python3. Though it’s not so friendly to use and doesn’t support so many features when compared with `configobj`, we failed to find any other better choice to make everything work.
As I need to prepared for the oral presentation on JCDL[4] at the end of July and after which I spend several days back home from school company with my parents, the progress is somewhat slow during that period of time. When working on port from configobj to ConfigParser, we choose to work based on the current develop branch which is still written in python2 and pygtk. Cause the code doesn’t do anything with GUI and can be written in python3 easily, so there won’t be so much more work and it will be better for testing and backwards compatibility.
I have two main problems during the porting from `configobj` to `ConfigParser`. The first one is that configobj can support get/set configuration via the methods just like dict, but it seems to be really hard the make ConfigParser object work in the same way. Since `configobj` is used in many places, to avoid modifing too many codes and keep the same interface when interacting with configuration file. I just failed to come up with an elegant solution. The second one is that configobj support to save configuration via `.write()` method without any more parameters and object indicating sections in configuration can get the whole config via `.parent` property but both of them are not supported in ConfigParser. Mentor suggested to make it work via python magic like __dict__, __get__ and other underscore methods, but also pointing out that the tricky hack will make it hard for future maintainance.
I forced myself to look through the current code and how config objects are used according to mentor’s suggestion. After listing all the related operations together, I finally think up a solution which should be simple and elegant. Just make everything work via a simple wrapper based on `ConfigParser` object and implementing all needed interface in that wrapper. After being stucked at this problem for severals days, it’s really exciting to hava a not so bad solution. This really consume too much time because I am not familiar enough with the code of GTG and appear to be irritable when refactoring.
Now the porting from configobj to ConfigParser has been successfully merged [5] into development branch with some other bugs fixed and I am working on porting GTG to python3 in last several days. It’s almost done only with some little problem need to be fixed. I will continue working on porting deprecated widgets [6] of gtk3 and setting up coverage testing as well as some other bugs fixing. Let’s continue enjoying the GSoC times!
[1] https://pypi.python.org/pypi/coverage/
[2] http://www.voidspace.org.uk/python/weblog/arch_d7_2010_12_11.shtml
[3] https://bitbucket.org/zubin71/configobj-py3
[4] http://jcdl.org/
[5] http://bazaar.launchpad.net/~gtg/gtg/trunk/revision/1307
[6] https://developer.gnome.org/gtk3/stable/DeprecatedObjects.html