Hi Simon! Simon McVittie <s...@debian.org> (2021-05-17): > My instinct is that it's far, far too late to be moving to GTK 3 this > cycle, and I'd prefer to get a suitable hack into GTK 2 if we can > find one. We can make it #ifdef DEBIAN_INSTALLER to avoid disrupting > the installed system.
If you're happy with further assisting us with getting away with GTK 2 one more time, that's very fine with me! Huge thanks for all your work and help so far! > I think d-i will need to move to GTK 3 early in the Debian 12 cycle, > but hard freeze is not the time to be fast-forwarding through 10 years > of GUI library development. From my little “feasibility survey” over the last few days, there seem to be a number of obvious issues to solve indeed! > Getting > https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/4 > into cdebconf would make this easier, although we can revert it for > the sake of a smaller diff once we think we have a solution if the > release team are grumpy about it. I'm very happy to see this patch merged, and possibly released into bullseye. The most obvious side effect I can anticipate is possibly bigger /var/log/installer/syslog files in the installed systems, but users are expected to compress them anyway before attaching them in installation reports (BTS and/or lists size limits). Would you like that to be released into unstable right away? I'm happy to deal with it if that helps testing stuff. > 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. GTK asks Pango "if you wrap lines at width x, how much space > will you need?", then uses the result to re-run the layout algorithm, > which changes the width available, which causes the layout algorithm to > be re-run and so on. Under normal circumstances, this runs for a few > iterations and then stabilizes at one size, terminating the loop, but > when I select Sinhala from the language menu, the width flaps between > 71 and 72 pixels, with each re-layout resulting in the other width. 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. > I think this might be related to the fact that when the layout is > calculated at the narrower width, Pango decides that there isn't space > to put the "." at the end of a paragraph on the same line as the last > word, and so wraps it to the next line, which is fine; except that > you'd expect the space required for the last word to get a bit smaller > when the "." is not included, but actually Pango tells GTK that it will > need 1 pixel *more* for "අසම්පූර්ණයි" than for "අසම්පූර්ණයි.", resulting in it > flapping between the narrower and wider width. I don't know why that > happens - perhaps the Indic shaper is drawing a character at the end of > a line more elaborately, or something? Maybe the Indic shaper makes the problem more obvious but I definitely saw a similar hang (even if I hadn't patched the installer to generate log lines to make extra sure) with plain English when starting in rescue mode. > However, either 71 or 72 pixels seems a ridiculous width to be trying to > squish multiple sentences into, so arguably it's a bug in GTK 2's layout > algorithm that it is even considering that as a size. The GTK 2 layout > algorithm does not necessarily make much sense, and the fact that it > can feed back into itself is probably a GTK 2 design flaw. During the > GTK 3 cycle it was redone to be in terms of "height for width" (if I > give you this width, how much height will you need? the mode cdebconf > will end up using) and "width for height" (the opposite, rarely used) - > so hopefully GTK 3 avoids this failure mode. However, it also seems wrong > that telling Pango that less width is available can result in it saying > it needs *more* minimum width, and maybe preventing this from happening > would get GTK 2 to do the right thing. > > 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 might result in the text > being clipped at the right margin (or left margin in Hebrew/Arabic), or > even having its "ink rectangle" overlap with the next widget to the right > (or left); but for d-i, which always uses the full screen width and in > practice has a generous amount of space for its text, we might get away > with it? In a very brief test that seemed to resolve the Sinhala thing, > but I haven't tried the other paths that lead to infinite loops. Please > could someone who has tried the other scenarios provide a walkthrough? What I can think of that's not (entirely) full-width: - buttons at the bottom; - checkboxes to toggle password/passphrase visibility (but they might be on their own line actually); - anything that can be accompanied by a scrollbar. All in all, we should have plenty of space most of (if not all) the time. And to be honest, if we end up having rendering glitches but a non-hanging/crashing installer for Buster, I can live with it. Walkthrough for the English vs. rescue mode, using QEMU: - Get an sda.img image to “rescue” (see below). - Build a netboot/gtk/mini.iso from git master (the TRANSSTATUS is important for languages that aren't English, as that file makes it possible to distinguish which translations are usable): make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=bullseye TRANSSTATUS=translation-status - Run build/dest/netboot/gtk/mini.iso against it with: kvm -m 1G -cdrom build/dest/netboot/gtk/mini.iso -hda sda.img -boot d - Accept all default values. - Once the disk has been detected and scanned, a number of options are proposed, pick the first one (executing a shell in the context of the installed system) → hang. To speed things up, you can fetch an image to rescue along with my last mini.iso build here:a https://mraw.org/~kibi/smcv/ Note: The hang doesn't happen if one picks French or German at the beginning. > If you want to replicate my super-verbose printf debugging: […] Thanks for the details, I'll give it a shot! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
