Now we have the GtkSourceVIew and GtkSourceBuffer instead of the GtkTextView and GtkTextBuffer.
To implement the Search functionality this change was necessary as GtkSourceSearchContext is used for the search and replace in a GtkSourceBuffer.
Stay tunned for the Search functionality option updates.
Also we made some major changes related to Coding style. From onwards will have the following coding style.
Use tabs to indent the code and spacing to align the parameters.
For next Release of Xpad 4.4 you will have a new look for preference dialog.
You will see the GtkNotebook used to optimize the dialog size. Reason is to use Notebook is if user is having a laptop (10” screen) , then he was not able to see the bottom of preferences window.
First solution was to make it scrollable, but having a notebook makes much better what you say guys.?
In future if options increased on preferences dialog then we can make the Noteook page scrollable.
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 .
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 >
</task>
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.
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.
Its like a headache when you want to debug the reference count of GOjects. You have SystemTap to debug the application but it’s bit of pain to setup it. But once you set it up then it works pretty cool.
But I choose simple way for counting the reference objects GObject-list. Clone it on your machine.
Before making it you need to install libunwind. and fire make command.
after making it use this command :
LD_PRELOAD=~/Development/tools/gobject-list/libgobject-list.so application | grep application -i
it will gives you a reference count of GObject’s.
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 >
</task>
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.
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 :
<task>
<recurring>
<Daily> or <Monthly> or <Weekly> or <Yearly>
<repeats>
<frequency> 5 </frequency>
<on> First </on>
<day> Sunday </day>
</repeats>
</Daily> or </Monthly> or </Weekly> or </Yearly>
<endson>
<occurrences> 4 </occurrences> or <date> dd-mm-yyyy </date> or <never> Never </never>
</endson>
</recurring>
</task>
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.
