Package: cdebconf-gtk-udeb Version: 0.258 Severity: important X-Debbugs-Cc: Simon McVittie <s...@debian.org>
Hi, The 0.258 update is *very* important for us since it makes extra sure (together with libgtk2.0-0-udeb 2.24.33-2) we don't run into relayout loops meaning hangs from a user point of view. Yes, it comes at a price: focussing on the last items of a GtkTreeView no longer works correctly. There might be simpler (shorter) ways to trigger this but the following is robust: - Initially detected while testing an encrypted LVM install in Swedish (confirming all hangs go away), when reaching the partition layout confirmation dialog, the selected entry is the last one in the list, but the selection isn't seen. One might wonder where the focus is, why no entry was selected, etc. Since that can happen in various places, I think users might get confused. That should not be specific to Swedish, it just happens to be the first occurrence I noticed. - Slightly shorter (`kvm -m 1G -cdrom mini.iso`, no disk layout or even disk required), pick a language like French and all default choices, until the mirror country selection, pick the very last one (États-Unis), and on the mirror host selection, pick the very last one again (the actual hostname doesn't matter). Now, on the next dialog, hit “Revenir en arrière” (Back), and see the selected hostname isn't focussed. Another step back shows the selected country isn't focussed either. That should happen with other languages as well, using French has the main advantage for me to get the appropriate keyboard layout automatically plus get two “back” steps that exhibit the problem (other countries might not have a mirror list as big as the US one). With both gtk+2.0 and cdebconf being uploaded recently, I've made sure to determine what triggers this: - bulleye: OK - unstable: KO - bullseye + gtk2.0: OK - bullseye + cdebconf: KO My first hunch was that the focus_path callback (one-shot call, it disables itself once it has triggered gtk_tree_view_scroll_to_cell on the first expose event) happens before the set_text_in_idle one, and that's indeed correct. I suppose we have a slightly taller widget at first, we scroll down to the bottom; then when set_text_in_idle happens, the widget is resized slightly smaller, the position is not correct anymore (it's no longer “full-bottom” but a little higher as seen in the scrollbar), and the selected line gets out of sight. I've tried various things like having the focus_path happens in a “_later” indirection using the same kind of logic as Simon introduced for setting the text (with a different priority), but that would happen waaay before set_text_in_idle anyway. I've also tried to implement a “double-tap” approach, letting the callback be called twice, so that we would focus first, let the text be set and get a new expose event, and re-focus. But it seems the amount of events we need to reach this point is not constant (I didn't conduct a real study but it seems one might need up to 4-5 such events). Next on my list of things to try was adding a pointer to the frontend object (and its `data` member) so that we could keep the callback alive until set_text_in_idle has done its job. I thought it might need some mutex or locking around a counter of pending set_text calls and I haven't touched that yet. And today, the following rang a bell… :) https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/7 I'm happy to be told whether the vague idea above looks like a workaround that could or even should work before diving a little more into it, and/or to be suggested better ideas! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
