On Mon, 17 May 2021 at 23:54:01 +0200, Cyril Brulebois wrote: > Simon McVittie <s...@debian.org> (2021-05-17): > > It looks as though the problem is that the size GTK chooses for a > > GtkTextView (a debconf "note" or similar) is flapping between two > > values. > > Without looking into the code, one might try and keep track of results > that have been seen, and if N/N+1 is detected, maybe just assume this > should be N+1 and move on with other computations? But anyway, further > down your mail you seemed to have ideas already.
It wasn't obvious to me where we'd keep track of this, or how correct it would be to do that - cache invalidation is reputed to be one of the hardest problems in computer science, and this would be one more thing that needs to be invalidated on at least those occasions when the layout has legitimately changed (but without invalidating it too often because that would destroy the workaround). Having reproduced the English/rescue issue and got further with the Sinhala/install issue with the GTK MR referenced below, I think it can also happen that the layout flaps by an amount greater than 1 pixel (I think the most I've seen is 4px), so a special case for n/n+1 isn't going to be enough. One of the reasons this took me a while is that I got distracted by the difference I was seeing being exactly 1px, which I thought might be to do with GTK adding 1px of extra width to make sure there's space for a cursor - but after tracing through it, it seemed like GTK is always adding/removing that width correctly. > > My next thing to get a try when I get a chance will be to make GTK refuse > > to obey Pango when GTK asks Pango to stick to a width limit and Pango goes > > outside that limit, with a g_warning(). This works: https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/2 The other thing I wanted to try was to make cdebconf create the GtkTextView in an empty state, and then populate it with text a little later (perhaps after layout but before drawing, or perhaps drawing one frame without text and then adding the text in the next frame, I'm not actually sure). And that also works: https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/6 Following the rule of thumb that bad interactions between two components should often be fixed on *both* sides, I'd be tempted to clone this bug, reassign to both gtk+2.0 and cdebconf, and apply both changes. As for Pango, I'm afraid figuring out whether it is doing something wrong here is beyond my expertise. If I can characterize the maybe-bug in a clear enough way I can try asking upstream - but as I said before, upstream will be very reluctant to touch this as soon as I mention GTK 2, which has been on life-support for a decade and is now officially dead. smcv
