Bug#988951: regression: focus_path on last items no longer works properly
On Fri, 21 May 2021 at 21:54:15 +0200, Cyril Brulebois wrote:
> focussing on the last items of a GtkTreeView
> no longer works correctly
FYI I didn't receive the initial message reporting this bug, only the
follow-up, despite you having X-Debbugs-Cc'd me. I'm not sure why. Luckily
`bts show --mbox` exists.
> - 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).
I can read French somewhat better than Swedish (and infinitely better
than Sinhala where I don't even recognise the glyphs), so this is probably
the more convenient test-case :-)
> 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.
Please could you share what you tried so I can check whether it's doing
something wrong? I feel as though this approach ought to be workable -
an idle callback with higher priority is guaranteed to happen sooner
(but note that smaller numbers are higher priority), and in my experience
idle callbacks of the same priority seem to get run in the order they
were scheduled.
The stuff here with expose events is beyond my GTK knowledge, but I
feel as though it's probably not idiomatic, and there might well be a
higher-level way to do it.
Note that the use of focus_path says
We need to focus the row *after* the widget realization, see #340007
but #340007 was a bug in the old GTK-on-DirectFB installer, and the
message opening the bug specifically said that it didn't affect
GTK-on-X11. So perhaps this delay isn't even necessary any more?
smcv
Reply to: