If you are eli­gi­ble and you are look­ing for a great sum­mer intern­ship, apply!

The pro­gram is here, projects ideas and moti­va­tion to par­tic­i­pate are in my pre­vi­ous post.

Dead­line is April 8 (I know, I’m ter­ri­bly late).

Hello fel­low students!

If you like to code and you have no plans for this sum­mer, con­sider apply­ing for the Google Sum­mer of Code with GNOME!

I did that last year, and it is a fan­tas­tic expe­ri­ence for lots of rea­sons. Here’s a few:

• You work from wher­ever you like, when­ever you like (as long as you Get Things GNOME Done, it’s great)
• You get paid to con­tribute in a FLOSS project! In three months, you have time to make an impor­tant con­tri­bu­tion too!
• It looks great on you CV, and your works gets great visibility
• You get Google’s swag
• You get to go to GUADEC (the Gnome con­fer­ence), with is an awe­some expe­ri­ence itself!
• You can fully enjoy almost all August
• You get to blog on planet Gnome, and show your con­tri­bu­tion to the world
• You become a bet­ter coder!

Now that I got your atten­tion, have a look at the project ideas for GNOME. These are just ideas, you are free (and encour­aged too) to come up with your idea: if the idea is awe­some, you are more likely to get chosen!

Per­son­ally, I am root­ing for you to come by and help us improve Get­ting Things Gnome. New ideas and great peo­ple are very welcome!

Don’t post­pone, the dead­line is April 8, and a great pro­posal can be writ­ten in just a few hours. You don’t have to have pre­vi­ous expe­ri­ence in FLOSS devel­op­ment (although it helps). If you are not cho­sen, con­sider con­tribut­ing any­way: your next year pro­posal will be great!

Ps: if you have ideas for gtg, talk to me on IRC (GIMPNet/#gtg is our chan­nel, I’m also avail­able on freen­ode as invernizzi)

I’m at GUADEC!

It’s been awe­somely great so far. I’ve finally met the guys I’ve been work­ing with and new peo­ple from all over GNOME. Thanks to them and to the talks I’ve been fol­low­ing we have new ideas for GTG! I’ll tell you about them as they get a lit­tle more pol­ished, but they will involve Telepathy.

As for my GSoC work, the first ver­sion of the Remem­ber the milk back­end is now com­plete. A cou­ple of small bugs still need to be fixed

Thanks to the first days GUADEC wifi, I’ve been able to test my back­ends on an unre­li­able link (now the net­work works perfectly).

We’ve also been hav­ing a small GTG hack­fest to fix the nas­ti­est bugs in trunk.

See you next week, and thanks for all the peo­ple orga­niz­ing GUADEC, giv­ing talks or just being here!

A GTG user, Dami­ano Ven­turin, asked me if it was pos­si­ble to con­vert a mail stored in Evo­lu­tion to a GTG task, as it can be done in mutt.

This is a pretty inter­est­ing ques­tion. There are two dif­fer­ent ways:

• auto­matic con­ver­sion of new mails tagged in some way (e.g. “Note to self: go to surf tomor­row #TODO”)
• man­ual con­ver­sion of the mail cur­rently being read

Both of them work. I’ll show you how:

Auto­matic con­ver­sion of new mails

• Down­load this script, place it any­where you like and make sure you give it exe­cut­ing per­mis­sion (that is, chmod +x <script-name>)
• Open Evo­lu­tion, in the mail tab
• From the menu, select Edit->Message Filters
• add a new filter
• Edit the fil­ter such that it catches only the mails you want to trans­form in tasks
• Edit the fil­ter such that it exe­cutes the down­loaded script

This screen­shot shows all these steps

Here, when a new mail con­tain­ing the text #task is received, the user is noti­fied via the usual noti­fier bub­bles and a new gtg task is created.

Man­ual con­ver­sion of mails

• In GTG, enable the Evo­lu­tion plugin
• In Evo­lu­tion, acti­vate the Mail-to-Task plu­gin (via the menu bar: Edit->Plugins)

Now, each time you want to import a mail in GTG, you should:

• in Evo­lu­tion, from the global mail view (that is, not from an opened mail), right click and select “Cre­ate a task”
• in GTG, syn­chro­nize with evolution.

The Evo­lu­tion plu­gin for GTG will soon be trans­formed in a back­end, which will make the syn­chro­niza­tion com­pletely auto­matic (remov­ing the need for the sec­ond step).

Hello and wel­come to my GSoC report for my eighth week of work about sup­port­ing mul­ti­ple back­ends in “Get­ting Things Gnome!”.

This week, I’ve fin­ished the first com­plete ver­sion of the couchdb back­end. This one is sup­port­ing all GTG’s fea­tures (sub­tasks, tags, fuzzy dates...), so it can be used as default back­end (instead of the xml one).

Its per­for­mances are fairly good: for small and medium sets of tasks (I’ve been test­ing it with ~500 tasks) it’s a tad slower than the xml one, but I sus­pect that for big tasks sets there are speed advan­tages. Any­way, being GTG 0.3 fully asyn­cro­nous, users shouldn’t even notice it.

I’ve writ­ten a unit-test for it, and started to check how it behaves with repli­cat­ing couchdb data­bases. It works quite well (a few crashes occur from time to time), but I’ll test it a bit more next week.

I haven’t been able to get auto­matic repli­ca­tion of the data­base via Ubuntu One so far. I’m start­ing to think that some­thing is wrong in my installation.

Next week, I’ll keep on test­ing the couchdb back­end and I’ll work on fin­ish­ing the RTM one (which should be the last big one, since the Evo­lu­tion one is very easy, thanks to the nice api).

Ciao!

This week, I’ve started to work on  two back­ends planned for my GSoC on “Get­ting Things Gnome!”.
One is the Remem­ber The Milk back­end, for which I’ve writ­ten the authen­ti­ca­tion sys­tem and started to sync task titles (I already have the code for the rest in the old plu­gin, but it will need a bit of refac­tor­ing to make it eas­ier to read and com­pat­i­ble to the new back­end sys­tem).
The more inter­est­ing back­end is the one based on couchdb, which should enable to keep two GTG instal­la­tions in sync. This back­end should also work on the Ubuntu, which has a couchdb imple­men­ta­tion which dif­fers a lit­tle bit from the stan­dard (e.g. deleted records are not really deleted, but are “marked” as deleted — FYI, a good tuto­r­ial on Couchdb and Python is the one on Ars by Ryan Paul). Any­way, so far, it’s work­ing nicely, although it’s not yet sup­port­ing all the fea­tures of a  gtg Task.

This week has been busy for me, since I have (just a few hours ago) dis­cussed my mas­ter the­sis. Any­way, now I’m going to be work­ing full time on GTG, which is nice.

So, this week I have fin­ished the first ver­sion of the Launch­pad back­end (import­ing in a read-only fash­ion launch­pad bugs assigned to some­body in GTG). I’m think­ing if it would be inter­est­ing to have the pos­si­bil­ity of chang­ing some­thing about the bug through its task in GTG, but I haven’t found nice ideas so far. I’ll  look into mak­ing a bugzilla back­end, since many peo­ple requested that.

Sec­ondly, I’ve writ­ten an export back­end to Zeit­geist, so that tasks that have been com­pleted are also vis­i­ble there. This makes it easy to see what it has been done day by day. Another approach would be inform­ing Zeit­geist when a task gets mod­i­fied, cre­ated and so on (like a reg­u­lar doc­u­ment). While this sec­ond approach is more “zeit­geisty” (since it leaves a trace of the activ­ity of the user), I think that for todo items the impor­tant infor­ma­tion to keep trace of is when they get done. I’ll see what users pre­fer when they start using it, or you can leave your opin­ion in the com­ments here.

I’ve also writ­ten a patch to gnome-activity-journal to sup­port TODO items (which are sup­ported in Zeit­geist 0.4 which has just been released, and GAJ is being updated to use that).
That’s what you should get in Sep­tem­ber (~ planned GTG release time):

Next week, I’ve a lot of things to do. A few of them are:

• I’ll add a “remem­ber the milk” back­end, which will have a series of advan­tages ver­sus my old plu­gin (auto­matic sync­ing is one of them)
• I’ll review and ask for merg­ing to trunk the code for my UI and the tomboy back­end, so that other devel­op­ers and brave users can start using my code
• I’ll make order among my threads, since a few libraries that I used have a series of syn­chro­nous calls which can make clos­ing GTG slower than nor­mal. I’ve dis­cussed this with a friend (the cre­ator of Lightspark), and a few inter­est­ing ideas have come out.

Another GSoC week has gone, and my project with “Get­ting Things Gnome!” has moved forward.

We now have a com­plete tomboy back­end. Tomboy notes match­ing a par­tic­u­lar @tag (you can con­fig­ure mul­ti­ple tags, or get all notes) are imported in GTG. The syn­chro­niza­tion is both ways: if you change  some­thing in Tomboy, GTG will be updated and vice versa (and GTG doesn’t need to be run­ning when the mod­i­fi­ca­tion is done).

That back­end comes with a unit test, which has helped me spot a few bugs. The tomboy dbus inter­face is syn­chro­nous, which cou­pled with the pres­ence of a Global Inter­preter Lock in python, has caused a few weird hangs dur­ing exe­cu­tion, as threads were not really indipen­dent. Any­way, now every­thing seems to work fine

Sec­ondly, the new back­end frame­work has landed in GTG Trunk, so my work is start­ing to be tested by a few reck­less testers. Thanks!

Lastly, I’ve been work­ing on a Launch­pad back­end, which imports (read only) the bugs assigned to you on that bug tracker. This one still needs a lit­tle work, as I’ve started work­ing on it yes­ter­day, but it will be ready and tested for next week. The syn­chro­niza­tion engine, which is com­mon for all back­ends (and generic, as the only require­ments it has is that objects it syncs have unique id and a mod­i­fi­ca­tion date), really does most of the work.

As usual, a screen­shot with the Launch­pad back­end at work:

Next week I’ll work a lit­tle less, as I have my “pre-degree” exam. I’ve already done most of the things I’ve put in my pro­posal (I’m miss­ing the RTM and Evo­lu­tion back­ends, which are just a mat­ter of con­vert­ing my old plu­g­ins, and a couchdb back­end –which was optional, but I cer­tantly have the time to do it), so I’m con­fi­dent I will fin­ish in time.

Have a good weekend!

Another week has gone, and new ways to syn­chro­nize things to do have landed in my “Get­ting Things Gnome!” branch.

First of all, there is a new two-way syn­chro­niza­tion engine for tasks (com­plete with test cases), which will be the core of all the back­ends to come.

The first back­end using that is the new TOMBOY–GTG syn­chro­niza­tion: the idea behind this one is that some of you are used to use tomboy to take quick notes, but then they real­ize that they also need that note in their todo list. With this back­end, just adding a tag to the note (like “@tomboy-gtg”) will auto­mat­i­cally add that note to GTG the next time you start it.

So, basi­cally, it’s a way to super­power some of your notes, giv­ing them a way to get sched­uled in your super-busy third-millennium life.

Screen­shot is due:

For now, two-way sync is work­ing for all tasks (not fil­ter­ing them yet), and a few bugs have to be ironed out, the most impor­tant of which is that GTG some­time issues the dele­tion of all tasks when it’s quit­ting (which is rather unpleasant).

Next week, I’m plan­ning to get this plu­gin ready for the users. Then, I think the Remem­ber The Milk back­end will fol­low, and shortly after Evo­lu­tion and CouchDb.