One of those things is support for the GTK+ printing API. Francisco Moraes implemented most of this already, but it needed some final touches: a property page allowing you to select what to print, a few minor changes in the layout and the removal of some magic numbers.

Most of these things I completed already a while ago, but there were a few problems with font sizes that I could not quite get a handle on. Francisco was aware of the issue when he was working on GTK+ printing support, but did not find a solution.

The problematic piece of code is in src/planner-print-job.c in the function planner_print_job_get_extents(). As you can see the current font description is set in the layout, a text string is also set and then the pango_layout_get_extents() function is used to get the dimensions of the rendered string. Unfortunately the width returned is about twice what you would expect.

When I got to work on GTK+ printing I saw the same thing; no matter what string I used, the (horizontal) size was always roughly double what I expected. As I’m no expert in pango and font stuff and because planner does not use the vertical size, I only had an estimate for what the horizontal size should be. It determined the width of columns and I could see they were about twice as wide as they needed to be for their content.

Then I thought, maybe it’s using the wrong font. So I searched for where current_font was assigned a value. I found it in planner_print_job_set_font_regular(), planner_print_job_set_font_bold() and planner_print_job_set_font_italic(), all of them in src/planner-print-job.c. They set priv->current_font to either priv->font or priv->bold_font. (I guess the italic function is not used =) ).

So now I wanted to know what priv->bold_font and priv->font were set to. Searching for them showed that they are assigned their value in planner_print_job_new(). In this function the font descriptions are created from a string like “Sans Regular 6″.

If these are the fonts used, then changing “Sans Regular 6″ to “Sans Regular 18″ should have an effect on the width returned by pango_layout_get_extents(), right?

Yes, it _should_ indeed, but it doesn’t. Instead it kept giving me the same width.

I suppose that could happen if the planner_print_job_set_font_* functions were not called, so let’s see what the font IS set to. I used pango_font_description_to_string() for that. Guess what?

(planner:25972): Pango-CRITICAL **: pango_font_description_to_string: assertion `desc != NULL' failed
Determining extents with font: '(null)'

Oops! It turns out that planner_print_job_get_extents() is already called a couple of times before the first call to planner_print_job_set_font_*().

In order to find out where to add calls to planner_print_job_set_font_*(), I will look at where planner_print_job_get_extents() is called and go from there.

Adding a g_print() statement just before each call to planner_print_job_get_extents() that prints the name of the calling function gives me this:

print_job_begin_print

(planner:27322): Pango-CRITICAL **: pango_font_description_to_string: assertion `desc != NULL' failed
Determining extents with font: '(null)'
planner_gantt_print_data_new 1

(planner:27322): Pango-CRITICAL **: pango_font_description_to_string: assertion `desc != NULL' failed
Determining extents with font: '(null)'
planner_gantt_print_data_new 2

(planner:27322): Pango-CRITICAL **: pango_font_description_to_string: assertion `desc != NULL' failed
Determining extents with font: '(null)'
planner_gantt_print_data_new 3

(planner:27322): Pango-CRITICAL **: pango_font_description_to_string: assertion `desc != NULL' failed
Determining extents with font: '(null)'
planner_print_job_set_font_regular

planner_print_job_set_font_regular
planner_print_job_set_font_bold
planner_print_job_set_font_regular

Now let’s see if there’s a common parent function of all of these.
The ones with a number behind them are all from the planner_gantt_print_data_new function. A little grepping shows that this function is called from gantt_view_print_init(), which is set as the print_init function for the PlannerViewClass in src/planner-view.h. print_job_begin_print() in src/planner-print-job.c loops through planner’s views (gantt, task, resource usage) and calls print_init for each of them. Lucky for me this is also the function that makes the one call to planner_print_job_get_extents() that I did not yet cover. In other words, the perfect place to insert our call to planner_print_job_set_font_regular().

That concludes the overview of this debugging session.

I just checked in the the changes discussed in this post, so Planner now finally uses GTK+ printing instead of the old libgnomeprint. This should fix a bunch of long-standing problems people were having with printing on Windows. That is, if your GTK+ installation is recent enough.

For this post I will describe what I’ve been doing to fix bug #382548. This bug allows you to create dependency loops in tasks.

The simplest type of loop that can be created is this one:

You could create this by first setting task2 as a predecessor of task1 and then indenting task2 to become a child of task1. Planner does not allow you to do it the other way around, first indenting task2 and then adding it as a predecessor of task1.

To see how Planner tries to detect these loops, we’ll have to take a look at libplanner/mrp-task-manager.c.

There are basically two operations you can perform on a task: moving and setting predecessors. All other actions are mapped to these two. Indenting a task for instance is implemented as moving it under a new parent. To check if these operations can be performed without creating loops, two functions named mrp_task_manager_check_move() and mrp_task_manager_check_predecessor() are used. Both of these functions have the following structure:

1. perform the operation in the dependency graph
2. traverse the graph to detect loops
3. undo the operation in the dependency graph
4. return a boolean indicating whether or not the operation can be done without creating loops

The dependency graph that these functions refer to is a directed acyclic (or at least it should be ) graph. The tasks will be nodes in this graph and the edges are either predecessor relationships or child-to-parent relationships. Think of this graph as showing the order in which tasks can be scheduled; a predecessor must be scheduled before its successor and children should be scheduled before you are able to tell the duration of the parent. Note that adding a predecessor to a parent task has to result in adding this predecessor to (certain) children of the task as well, otherwise it would not be clear from the graph that none of the children can be scheduled before the predecessor has been scheduled.

The above is implemented as follows for adding a predecessor. mrp_task_manager_check_predecessor() calls add_predecessor_to_dependency_graph(), which connects the predecessor node with the parent node and then calls add_predecessor_to_dependency_graph_recursive() that loops over all children, connects the predecessor node to them and calls itself for the children’s children. If the predecessor link in the above image had been created when task2 was already a child of task1, then this recursive adding of predecessors would have connected task2 to task2, thereby creating a loop.

When a task that is already a predecessor of another is indented, the process is a bit different. mrp_task_manager_check_move() calls remove_task_from_dependency_graph() to remove the task node from its current position in the graph followed by add_task_to_dependency_graph() to add it at the new position. add_task_to_dependency_graph() reconnects the task to all of its predecessors and finally connects it to its new parent. Keen readers may have noticed that planner has not done anything yet about the predecessor relationships of the new parent. If the task that is being indented is a predecessor of its new parent, Planner would happily indent and create the situation seen in the image above.

What should be done when a task is moved under a new parent is to add all predecessors from the parent as predecessors to the task and all of its children. This is part 1 of the fix for #382548.

Unfortunately even with this fix, the following is still possible.

The reason for this is that loop detection is only started at the task that is indented (task2 in this case). Take a look at the “before” and “after” pictures of the dependency graph for indenting task 2. The dotted lines indicate predecessor relations and the normal lines child-to-parent relations. As you can see starting traversal at task2 will not go through the loop that was created.

Ok, so how about starting loop detection at the indented task and each of its children individually?

Let’s take a look at the loop detection function check_predecessor_traverse():

static gboolean
check_predecessor_traverse (MrpTaskManager *manager,
                            MrpTask        *task,
                            MrpTask        *end,
                            gint            length)
{
        MrpTaskGraphNode *node;
        GList            *l;

        if (length > 1 && task == end) {
                return FALSE;
        }

        /* Avoid endless loop. */
        if (imrp_task_get_visited (task)) {
                return TRUE;
        }

        imrp_task_set_visited (task, TRUE);

        node = imrp_task_get_graph_node (task);
        for (l = node->next; l; l = l->next) {
                if (!check_predecessor_traverse (manager, l->data, end, length + 1)) {
                        return FALSE;
                }
        }

        return TRUE;
}

This is first called as check_predecessor_traverse (manager, predecessor, predecessor, 1);.
First it returns FALSE (i.e. reports a loop) if the current task is the same as the one passed in ‘end’ and this is not the first call. Then it aborts searching down a path if it has been there before. Next it marks the current task as visited so it will not continue searching when it comes here the next time through another path. And finally it will go on to all tasks that follow the current one in the graph.

What I wanted to know before implementing the proposed solution of starting loop detection at the indented task and each of its children is if I could get away with calling check_predecessor_traverse() multiple times without marking all nodes ‘unvisited’ in between. As you can see the function only detects loops that include the task that it starts at and only if none of the nodes in the loop have been visited before.

I think the answer is no and here’s why:

1. assume we start with a graph without cycles
2. now if adding a predecessor to a child results in a loop, this means there is a forward path from the child to the predecessor
3. this forward path either goes through visited nodes or it doesn’t
4. if it doesn’t, the check_predecessor_traverse() function will detect a loop when it is called on this child
5. if it does go through visited nodes, then there was already a forward path from the visited node to the predecessor
6. because the visited node has been visited before, there must already be a forward path from a node that the traverse function started at to the visited node
7. because we only call the traverse function on nodes that the predecessor is added to (the indented task and all its children), there must also be a forward path from predecessor to the node the traverse started at
8. this means that there is a loop that would have been detected in the earlier check_predecessor_traverse() call

This is part 2 of the fix. I just committed these fixes in libplanner/mrp-task-manager.c (revision 894).

It would have been fun to use a model checker to formally verify the last part, but in the end looking for one took too much time. If anyone has a suggestion, please let me know.

Just last week I got a request to add support for libgda-3, because some distributions were dropping support for older libgda versions. I expected this to be more or less a configure fix, but it turns out it was quite a bit more work than that.

Planner accesses the database from two files: libplanner/mrp-sql.c and src/planner-sql-plugin.c. Both used a convenience function called sql_execute_query() which was just a wrapper around gda’s gda_connection_execute_single_command() and is used to do both queries (SELECTs) and other commands (BEGIN, INSERT, …). It was even used to execute a whole bunch of commands in one go when setting up the planner database. In the mean time libgda has become more strict in checking what is passed to its functions (and rightly so), forcing me to properly fix this code.

The three functions available are gda_connection_execute_select_command(), gda_connection_execute_non_select_command() and gda_connection_execute_command(). The first two are just wrappers around the second. Since planner is only interested in query results for single select queries and does sometimes need to execute multiple commands at once, I decided to split sql_execute_query() into two functions:

• sql_execute_query():
  uses gda_connection_execute_select_command() and returns a GdaDataModel * that you need to pass to g_object_unref() when it’s done with it, and
• sql_execute_command()
  uses gda_connection_execute_command() and returns a gboolean indicating success or failure. This function cleans up whatever results it receives on its own.

I then went through the sources modifying all calls to sql_execute_query(). The result of calls to sql_execute_query() will now always be stored in a local variable named model, while the result of sql_execute_command() will be stored in the gboolean success. I think it’s important to have such a clear distinction between cases where you have to catch a return value and clean up an object and cases where you don’t.

After modifying configure.in to detect the right GDA version and making the above changes as well as a few other fixes, it was time to run some tests.
*create a few task*, *save*, *load*.. hmm.. did I just see that task duration change?…
*modify task length*, *save*, *load*.. no, wait.. the project start date is shifting.. it’s 31 January 2008 now
*modify something*, *save*, *load*.. now it’s 30 January 2008!?

I could hardly believe my changes were causing this problem and sure enough, the same happened with svn HEAD. Some debugging and quite a bit of reading of the postgresql docs made it clear that the cause of this was a different interpretation of dates between Planner and postgresql. On one hand we were doing the calculation from time to seconds-since-epoch ourselves in Planner, but on the other we were letting postgresql do the reverse calculation when a project was loaded. The time zone used in these calculations was UTC for Planner, but local time for postgresql.
An example:

A seconds-since-epoch value of 86400 (which is the number of seconds in a single day) corresponds to the timestamp 02 Jan 1970 00:00:00 UTC.

1. When planner saves a project with a start date equal to 86400, it will store 02 Jan 1970 in the database.
2. When planner loads the project, it asks postgresql to do the conversion to seconds-since-epoch. Postgresql interprets the date to be local time, which at this time is UTC + 1 in my case. My local time of 02 Jan 1970 00:00:00 corresponds to 01 Jan 1970 23:00:00 UTC, so postgresql returns 86400 – 3600 = 82800 seconds-since-epoch.
3. When planner saves this project again, it will store 01 Jan 1970 in the database as a date without time, shifting the project start date not just by an hour but by an entire day.

This bug has now been fixed, but I’m still working on the libgda-3 changes. I broke compatibility with older gda versions, so I’ll have to restore that. I’ve put the latest version of the libgda-3 patch online for anyone to take a look at it and maybe contribute. I’m only working on it during CET evenings, so there’s at least an 18-hour window for a second person to work on it without having to solve merge conflicts all the time. Just send me your changes before I start working on it the next day.

For some time now I’ve been working on Gnome Planner and just last week I found myself updating the topic of #planner on GIMPNet every night to keep people informed of my progress on some requested feature. After a few of those rather short and cryptic descriptions, I decided to look for a better way to present this information: this blog.

In this blog I plan to write about what I’m working on, which is most likely to be Planner and maybe some Gentoo stuff. I’m not good at writing stories, so I’ll stick to the technical stuff. There are lots of things that this blog could do: provide insight into what Planner developers are working on or what the roadmap looks like, give prospective developers an easy way to get familiar with the project, generate more involvement from the community, etc. I have no idea if anything will come out of this, but let’s give it a try.

Tomorrow I plan to write about the stuff I’m working on at the moment: getting Planner’s database support in better shape.