Re: Strange message list behaviour: row height, threading

[Jack <ostroffjh users sourceforge net>]

Hi Peter,

Looking at that issue, one bit near the bottom of the review caught my  
eye.
     "And in the presize handler (the first size request while  
re-requesting the whole treeview), we've considered the natural width  
in the equasion for fixed height mode (this basically 'bumps' the  
current adjustment values to be at least as big as they are, it acts as  
a grow-only functionality unless before re-validating all rows we've  
reset the internal width/height variables to 0)."

I have not yet delved into the Balsa code, but wonder if it might  
apply.  It smells to me like it should not be relevant, as all rows  
should have the same height - we truncate subjects and do not wrap  
them, but I know better than to make ANY assumptions about how things  
work.  I WILL try to dig into the code, but am not at all sure how  
quickly I'll find and actually understand the relevant pieces.

Jack

On 2019.02.28 18:09, Peter Bloomfield wrote:
> Hi All,
>
> I've been seeing that issue pretty much since the first port from  
> gtk2 to gtk3 (and now, as I recall, even in the gtk4 trial port).  
> I've tried to build a small test case to reproduce it, packing a  
> GtkTreeView in much the same way as in Balsa, but it never shows the  
> issue.
>
> Some discussion in a possibly related issue[0] shows the complexity  
> of tree-view rendering!
>
> I've actually not seen it in a while; each time that happens, I cross  
> my fingers and hope that some minor tweak has fixed it, but it  
> invariably pops up again :-(
>
> Peter
>
> [0] https://gitlab.gnome.org/GNOME/gtk/issues/485
>
> On 02/28/2019 03:16:56 PM Thu, Jack via balsa-list wrote:
> > Hi Abrecht,
> >
> > On 2019.02.28 14:52, Albrecht Dreß wrote:
> > Am 27.02.19 19:24 schrieb(en) Jack via balsa-list:
> >
> > [snip.....]
> >
> > > > I assume all these issues are related, but that's pure guesswork,  
> > > > not based on anything concrete.
> > >
> > > Yes, agree.  The point is: is there any (programmatic?) workaround?
> >
> > Hopefully I will have some time to dig into this a bit in the next  
> > weeks, but I suppose the next step would be to ask on a gtk mailing  
> > list/forum/IRC to see if it's a known issue at all.  It's likely to  
> > be difficult to search for, as I can't think of any good search  
> > terms, although I have not yet tried very hard.
> >
> > In terms of workaround, I hadn't thought about different themes, but  
> > if you found it also affected other themes, then that doesn't seem a  
> > likely pursuit.  Not seeing the problem in other applications using  
> > the same libraries suggests that it might be something in how Balsa  
> > does use those libraries, but that's not very specific or useful.   
> > If we're luck, then browsing the code might suggest someplace to put  
> > some debugging output, although I'm not very hopeful, as I suspect  
> > whatever the cause, the problem doesn't actually manifest until  
> > somewhere deep withing gtk.  I suppose I could recompile gtk itself  
> > with full debugging info available, run under a debugger, and try  
> > interrupting the program when I see the problem.  A lot of setup,  
> > but my best approach for now.
> >
> > Jack