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

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

On 28/02/14 15:03, Julien Puydt wrote:
> 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 :-/

Thanks, Julien, for the description and for code simplification!  I will 
test it.

--
Eugen