[vim/vim] GTK4: Resize immediately on size_allocate() call (PR #21020)

[Foxe Chen]

Fixes #21016

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/21020

Commit Summary

• 19c6446 resize immediately on size_allocate() call

File Changes

(3 files)

• M src/gui.h (7)
• M src/gui_gtk4.c (7)
• M src/gui_gtk4_f.c (46)

Patch Links:

• https://github.com/vim/vim/pull/21020.patch
• https://github.com/vim/vim/pull/21020.diff

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21020@github.com>

[h_east]

h-east left a comment (vim/vim#21020)

Thanks for picking this up. A few things I would like to sort out before this
goes in.

This removes 9.2.0940

gui.pending_form_w/h/skip and the check in vim_form_resize_idle_cb() are
9.2.0940, which fixed #21006: the shell lost columns every time a window was
split. The allocation that arrives is still the one computed before the
request, and combining that old width with the new base width yields fewer
columns, which the next request is then based on. In the GTK4 CI job that took
test_popupwin from eleven failing tests down to one.

Calling gui_resize_shell() directly does not change that arithmetic, so I
expect #21006 to come back. Could you run test_popupwin in the GTK4 CI job with
this patch applied?

gui_resize_shell() now runs on every allocation

last_width and last_height were also the guard that notified Vim only when
the size actually changed. Without them gui_resize_shell() runs on every
size_allocate(), including the ones where nothing changed, and each of those
does out_flush(), gui_gtk_init_decor_height(), gui_position_components(),
gui_update_scrollbars(), gui_update_cursor() and
gui_gtk4_calculate_bleed().

Redrawing inside size_allocate

When the size did change, gui_resize_shell() goes on to shell_resized(),
set_shellsize() and update_screen(), so a full Vim redraw now happens inside
GTK's allocation phase, and gui_position_components() moves the scrollbars
there as well. I think that is what the idle callback was there to avoid. Do
you see any layout warnings or repeated allocations with this?

Does it fix #21016?

As far as I can tell the cause of #21016 is that gui_set_shellsize() raises
gui.num_rows without telling the drawing area, so the row cache keeps the old
size while Vim draws the new number of rows. When the window later gets its full
size, gui_resize_shell() recreates the cache and drops everything in it, and
shell_resized() is skipped because gui.num_rows, Rows, Columns and
screen_Rows / screen_Columns already agree. This patch does not touch that,
although it may change the timing enough to hide it.

I have a smaller change for that in #21021, which keeps the drawing area in sync
in gui_set_shellsize(). Happy to go with whichever holds up.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21020/c5260917443@github.com>

[Foxe Chen]

64-bitman left a comment (vim/vim#21020)

Closing in favor of #21021

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21020/c5261549172@github.com>

[Foxe Chen]

64-bitman left a comment (vim/vim#21020)

I think PR should be reconsidered. It is seems to fix an issue where the draw area does not update:

https://github.com/user-attachments/assets/60d0f905-88f0-4386-9274-13883c458f0c

This only seems to happen on debug builds for me, so its possibly a timing issue?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/21020/c5295632055@github.com>