simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  4da67d8f Move window resize timeouts into the GTK frontend.
  80a87df6 GTK: don't try to change font size in mid-window-resize.
  386b094e Fix GTK1 build.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2022-05-12 20:33:38

commit 4da67d8fa6cf056cb3c9527c59e5a2559bd73e97
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=4da67d8fa6cf056cb3c9527c59e5a2559bd73e97;hp=de66b0313a23d04312235cbf2054b882f554d21f
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 12 18:16:56 2022 +0100

    Move window resize timeouts into the GTK frontend.
    
    In the changes around commit 420fe75552afa94, I made the terminal
    suspend output processing while it waited for a term_size() callback
    in response to a resize request. Because on X11 there are unusual
    circumstances in which you never receive that callback, I also added a
    last-ditch 5-second timeout, so that eventually we'll resume terminal
    output processing regardless.
    
    But the timeout lives in terminal.c, in the cross-platform code. This
    is pointless on Windows (where resize processing is synchronous, so we
    always finish it before the timer code next gets called anyway), but I
    decided it was easier to keep the whole mechanism in terminal.c in the
    absence of a good reason not to.
    
    Now I've found that reason. We _also_ generate window resizes locally
    to the GTK front end, in response to the key combinations that change
    the font size, and _those_ still have an asynchrony problem.
    
    So, to begin with, I'm refactoring the request_resize system so that
    now there's an explicit callback from the frontend to the terminal to
    say 'Your resize request has now been processed, whether or not you've
    received a term_size() call'. On Windows, this simplifies matters
    greatly because we always know exactly when to call that, and don't
    have to keep a 'have we called term_size() already?' flag. On GTK, the
    timing complexity previously in terminal.c has moved into window.c.
    
    No functional change (I hope). The payoff will be in the next commit.

 putty.h             | 12 ++++++++++++
 terminal/terminal.c | 23 +++++++----------------
 terminal/terminal.h | 18 ------------------
 unix/window.c       | 38 ++++++++++++++++++++++++++++++++++++++
 windows/window.c    | 24 +-----------------------
 5 files changed, 58 insertions(+), 57 deletions(-)

commit 80a87df618af3072dbf8a0a74828a4f14d16f937
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=80a87df618af3072dbf8a0a74828a4f14d16f937;hp=4da67d8fa6cf056cb3c9527c59e5a2559bd73e97
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 12 19:38:45 2022 +0100

    GTK: don't try to change font size in mid-window-resize.
    
    If the user holds down Alt-> so that the key repeats, then a second
    call to change_font_size can occur while the window resize from the
    previous one has yet to complete. This leads to the new pixel size of
    the window from resize #1 being interpreted in the light of the font
    size from reesize #2, so that the two get out of step and the
    _character_ size of the terminal changes as a result.
    
    The simplest fix is to disallow starting a second font-size-based
    window resize while the first is still in flight - which, now that the
    'win_resize_pending' flag lives in window.c and not terminal.c, is
    easy to achieve.

 unix/window.c | 29 ++++++++++++++++++-----------
 1 file changed, 18 insertions(+), 11 deletions(-)

commit 386b094e3f6351d4c81eaffa3e7f385291ae5fad
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=386b094e3f6351d4c81eaffa3e7f385291ae5fad;hp=80a87df618af3072dbf8a0a74828a4f14d16f937
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 12 19:57:10 2022 +0100

    Fix GTK1 build.
    
    Commit 5390aef3fc7deca broke it, because GTK1 has neither
    gtk_label_set_selectable nor gtk_widget_set_can_focus. Happily, those
    are both more or less optional (only a minor UI awkwardness arises
    from not having them), so I'll just condition them out.

 unix/dialog.c | 4 ++++
 1 file changed, 4 insertions(+)