GTG ! Past can not be changed

Hi everybody,

Sorry for the late update, was a little busy discussing about the implementation stuffs .

Anyways let me give you a brief  idea of what I have been able to implement and what’s changed so far .

Now we are following ” Past can not be changed ” rule for handling the edit event.

So What’s changed?

Initially we were storing all the recurring details with each instances, but storing all is useless once task gets overdue or completed as recurring details never gonna used .

So we have changed the little bit implementation stuffs like this :

If task gets overdue or completed then in that case we make the task as a normal task and next instance will be recurring . so eventually we are removing all recurring details when we are making it as a normal task except the rid attribute to keep track of instances which gets created.

How to handle the edit event ?

Following the rule “ Past can not be changed ” , we are providing the edit options ( edit current instance or all instances )  to only the task having the recurring pattern. There is a one “Hidden” task gets created when user open a task for editing, which is used to check that task is actually edited or not.

All instances : –

Doing a simple check that task is actually edited then only reflect the changes in the current instances and according to that future instances gets created .

Current instance only : –

Make the current instance as a normal task and make the Hidden task as active task.

With this, a majority of the work for my GSoC project is complete. Now I will be focusing on optimizing and tidy up my source code .

GTG ! How we are handling overdue task ?

Question comes to mind..what if the task is overdue and GTG launched after few days?

It should be that much intelligent that it could create a task instances which are missed during those period.

For now added a “Touch” attribute in the task structure to keep track of the instances of recurring task.

( P. S. Any better approach is most welcome )

To calculate the next instances we won’t set the “Touch” as it will be considered to calculate next occurrences in future.

Task structure look like this now :

<task rid=Value  id=Value touched=Value >


Removed the Edit event dialog box

GTG user hates popup’s that why removed the edit event dialog box.

This is how the Task browser will look like after editing the task.


Screenshot from 2014-07-04 20:21:39










Two options :

1. Change only current instance

– Will planing to create a hidden task to save previous task attribute and use those attribute to populate future task’s.

2. All instances

– Change all the task attributes except those which are marked as done.

Comments and suggestion are most welcome in order to make this optimized.

GTG ! What if we mark task as DONE?

Here we have to consider two scenarios :

1. If user mark task as Done.
2. If task overdue

In both scenarios we are creating the new task instance, which depends on the recurring details validation.

To calculate the next overdue date we used python3-dateutil package, specially rrule module

What if the task have recurring and normal subtasks ?

– If recurring task have normal task then in that case we will mark them as done and won’t create a new instance.
– If subtask is recurring then will create instance according to recurring details.

Why “rid” added ?

– To keep the track of the recurring instance we need something, that’s why “rid” added.
– It will be useful in case of deleting the multiple occurrence.
– Here is the new task structure :

<task id=Value  recur=Value  rid=Value >


 Edit Recurring event

Added a dialog box for editing the recurring task event.

User can change,

1. Only current occurrence

2. All occurrences

Implementation stuffs are remaining.

Changed constraints of  “End on Date”

– Also few constraints of  “End on Date” are removed.

– Kept the “End on Date”  independent of due date.

– If “End on Date” is before the start date then we show it in red.

In next week I will add support to modify the recurring event.

GTG ! Recurring Task Structure

First of all constraints regarding the Due date are updated.

We are mainly interested in due date rather than start date of task. If task is recurring and Due date is not set, then in that case we should not allow the user to close task.

Show Dialog if Due date is not set !

Connected  “delete-event” to task editor, in callback method we check that if task is recurring and due date is not set then we show the dialog box.

This is how the dialog box look like : ( Message will be changed if it doesn’t look appropriate to anybody )








Now talking about the recurrence task data structure :

Initially we were thinking to go with libical ( an open source reference implementation of the icalendar data type and serialization format .) But GTG is not a calender, that’s why we dropped the idea.

After discussing these with my mentor Nimit Shah, and one of the developer of evolution-Fabiano Fidencio,, We concluded to go with xml to store the recurrence task details.

It will look like this :



        <Daily> or <Monthly> or <Weekly> or <Yearly>


                <frequency> 5 </frequency>

                <on> First </on>

                <day> Sunday </day>


        </Daily> or </Monthly> or </Weekly> or </Yearly>


            <occurrences> 4 </occurrences> or <date> dd-mm-yyyy </date> or <never> Never </never>




P.S Things are written/hidden in code according to repeats option.

Done with setting and retrieving recurrence task details.

Planning to work on modification of task and also how we can add a new instance of task if marked as complete or overdue.

Prepending Icon

How should we show that the task is recurring?

Prepending icon to the task to indicate that it is recurring. I think this is the best approach without modifying much things.

Adding attribute “recurrence” in xml to keep track of the recurring task.

Here is screenshot  :

Icon Prepended










Update summary is in place now.

Planning to handle all detailed information of recurrence and few constraints for Due date.


UI design for adding Recurring task

Here it come’s the new User Interface for adding ” Recurring task’s ” on GTG!

You can find the source code and progress of my work here: Recurring Task

Repeat Task Weekly.

Repeat Task Weekly.












Repeat Task Monthly

Repeat Task Monthly












Added “End On” date constraints.

  1. If the task’s Start date happens later than the  new End on date, we update it (except for fuzzy dates).
  2. If the task’s Due date happens before than the new End on date, we update it (except for fuzzy dates).
  3. If some ancestors’ Due dates happen before the task’s new End on date, we update them (except for fuzzy dates).

Applied constraints for children as well. 

  1. If the child’s Due date happens later than the task’s, we update it to the task’s new End on date.
  2. If the child’s Start date happens later than the task’s new End on date, we update it (except for fuzzy start dates).

While designing the User Interface using Glade, what you do is play with the “Packing” options of the containers e.g setting “expand” , “Padding”, etc. and obviously sometime you have to set the width of the components too  🙂

Why not to set the Packing options of Components?

Because when you set the padding for the components, or other options like expand, fill, etc.  User Interface looks good on the machine on which you have designed it, but when you try to run it on another machine, User Interface looks bad. Looks bad means components won’t be positioned properly.

Also one more thing we need to consider ,User Interface looks ugly when you set fixed Width and Height of components. Because when you try to run them on the other machine having the different resolution or configuration.

Font also matters in some cases [ Not so sure about Font ! In my case I didn’t experienced this. But while finding out the answer for different behavior of  UI on different machine, I think we should consider Fonts too . ]

Very soon you will find update about the summary in code.