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
_______________________________________________
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
