[Ekiga-devel-list] Call history view bug, GmCellRendererBitext and gtk+

[Julien Puydt <jpuydt free fr>]

Hi,

this is the tale of a bug hunt. It doesn't end as well as I would like.

A strange bug, in fact: at startup, Eugen only sees one line per entry 
in his call history ; it becomes better only later. At startup, Julien 
(me) has one line and a half par entry (and it doesn't get better later 
because of the infamous clutter crash). The common problem is that two 
full lines should be there.

So there might be something wrong with the initial population of the 
view, so the first thing is to try to print what data the call history 
view receives ; and the answer is : the engine part works! Only the view 
is to blame.

So what exactly do we use to display that information, since obviously 
that is where the fault lies? The GmCellRendererBitext class, which is 
inheriting from GtkCellRendererText. If there's only one and a half line 
per entry, then that means that entries are overlapping, and that points 
to a problem with the get_size in that code.

But why does it fail in the call history view and not in the roster 
view? In both case, our renderer is to the right of a pixbuf renderer. 
But in the roster view, the images are quite big images, while in the 
call history, those images are quite small. So in both cases, the size 
of our renderer in wrong, but in the roster, the presence of the big 
images means the lines are tall enough and there is no overlapping anyway.

So I just had to fix the size computation. Unfortunately it turns out 
our gm_cell_renderer_bitext_get_size method wasn't called, ever. It's 
deprecated in gtk+ 3.<something>! There is some provision in the code to 
still call the obsolete api, but it apparently doesn't work.

So yesterday I just added a few methods of the new api to detect the 
sizes, and committed that because it fixed the display problem (yes, I 
ran ekiga, and no, I didn't test calling because of the clutter crash). 
That made Eugen unhappy: I had added dozens of lines of code... and now 
it crashed after a while! Indeed, I was able to reproduce the crash.

So today I made another try, this time trying to rework the code to be 
much, much simpler. In fact, I removed much of the code, trying to use 
as much as possible the underlying GtkCellRendererText class to avoid 
any problem.

The code is simpler code, but even yesterday's code shouldn't have 
crashed, and did ; the dirty secret is a two year old bug:
http://bugzilla.gnome.org/show_bug.cgi?id=668779

As you can see with the sample code in comment #8, there are simple uses 
of the gtk+ code which can easily give crashes. The fix from yesterday 
(fix for the display issues) was apparently putting us in exactly the 
right conditions to trigger the bug.

The commit I pushed today has simplified the code much, and it looks 
like it doesn't trigger the crash... at least not as much, but I can 
hardly guarantee anything.

That is were things stand for now: the good news is that the display bug 
is gone and the code is (much) lighter and simpler... but we know there 
is a crashing bug lurking :-/

Snark