simon-git: putty (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Sun Feb 7 20:30:00 GMT 2021


TL;DR:
  45b03419 Remove TermWin's is_utf8 method.
  42ad454f Move all window-title management into Terminal.
  61571376 Remove TermWin's is_minimised method.
  da3197f3 Bring some order to colour palette indexing.
  cd32ef87 Indentation fixes in terminal.c.
  ca9cd983 Centralise palette setup into terminal.c.
  696550a5 Flip direction of window pos/size queries.
  07aff63e Centralise check of CONF_no_mouse_rep into Terminal.
  99dfc664 Decouple frontend's raw mouse mode from pointer shape.
  d74308e9 Fold ancillary window changes into main redraw.
  334688db Apply UPDATE_DELAY in arrears, not in advance.
  07d334c6 Windows: make the need_backend_resize mechanism consistent.
  8af1d90d Test program for ancillary window updates.

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:           2021-02-07 20:30:00

commit 45b03419fdfe37ed526e33606ab76a879261bcb0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=45b03419fdfe37ed526e33606ab76a879261bcb0;hp=b63a66cd2c96a0e44af96a03adb3081a9d93ecb3
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:20 2021 +0000

    Remove TermWin's is_utf8 method.
    
    All implementations of it work by checking the line_codepage field in
    the ucsdata structure that the terminal itself already has a pointer
    to. Therefore, it's a totally unnecessary query function: the terminal
    can check the same thing directly by inspecting that structure!
    
    (In fact, it already _does_ do that, for the purpose of actually
    deciding how to decode terminal output data. It only uses this query
    function at all for the auxiliary purpose of inventing useful tty
    modes to pass to the backend.)

 fuzzterm.c       | 2 --
 putty.h          | 3 ---
 terminal.c       | 2 +-
 unix/gtkwin.c    | 9 +--------
 windows/window.c | 7 -------
 5 files changed, 2 insertions(+), 21 deletions(-)

commit 42ad454f4f79dbb10530f1c67b4b541e362155b8
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=42ad454f4f79dbb10530f1c67b4b541e362155b8;hp=45b03419fdfe37ed526e33606ab76a879261bcb0
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:20 2021 +0000

    Move all window-title management into Terminal.
    
    Previously, window title management happened in a bipartisan sort of
    way: front ends would choose their initial window title once they knew
    what host name they were connecting to, but then Terminal would
    override that later if the server set the window title by escape
    sequences.
    
    Now it's all done the same way round: the Terminal object is always
    where titles are invented, and they only propagate in one direction,
    from the Terminal to the TermWin.
    
    This allows us to avoid duplicating in multiple front ends the logic
    for what the initial window title should be. The frontend just has to
    make one initial call to term_setup_window_titles, to tell the
    terminal what hostname should go in the default title (if the Conf
    doesn't override even that). Thereafter, all it has to do is respond
    to the TermWin title-setting methods.
    
    Similarly, the logic that handles window-title changes as a result of
    the Change Settings dialog is also centralised into terminal.c. This
    involved introducing an extra term_pre_reconfig() call that each
    frontend can call to modify the Conf that will be used for the GUI
    configurer; that's where the code now lives that copies the current
    window title into there. (This also means that GTK PuTTY now behaves
    consistently with Windows PuTTY on that point; GTK's previous
    behaviour was less well thought out.)
    
    It also means there's no longer any need for Terminal to talk to the
    front end when a remote query wants to _find out_ the window title:
    the Terminal knows the answer already. So TermWin's get_title method
    can go.

 fuzzterm.c       |  2 --
 putty.h          |  5 ++---
 terminal.c       | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
 terminal.h       |  2 ++
 unix/gtkwin.c    | 40 +++----------------------------------
 unix/unix.h      |  3 ---
 unix/uxpterm.c   |  5 -----
 unix/uxputty.c   |  5 -----
 windows/window.c | 39 ++----------------------------------
 9 files changed, 65 insertions(+), 96 deletions(-)

commit 61571376cc19f160c31b4cc4315b4318606821c5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=61571376cc19f160c31b4cc4315b4318606821c5;hp=42ad454f4f79dbb10530f1c67b4b541e362155b8
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:20 2021 +0000

    Remove TermWin's is_minimised method.
    
    Again, I've replaced it with a push-based notification going in the
    other direction, so that when the terminal output stream includes a
    query for 'is the window minimised?', the Terminal doesn't have to
    consult the TermWin, because it already knows the answer.
    
    The GTK API I'm using here (getting a GdkEventWindowState via
    GtkWidget's window-state-event) is not present in GTK 1. The API I was
    previously using (gdk_window_is_viewable) _is_, but it turns out that
    that API doesn't reliably give the right answer: it only checks
    visibility of GDK window ancestors, not X window ancestors. So in fact
    GTK 1 PuTTY/pterm was only ever _pretending_ to reliably support the
    'am I minimised' terminal query. Now it won't pretend any more.

 fuzzterm.c       |  2 --
 putty.h          |  2 +-
 terminal.c       |  9 +++++++--
 terminal.h       |  1 +
 unix/gtkwin.c    | 26 ++++++++++++++++----------
 windows/window.c | 11 +----------
 6 files changed, 26 insertions(+), 25 deletions(-)

commit da3197f3952086d9a4e402315a5e8f4a8a1c7cf5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=da3197f3952086d9a4e402315a5e8f4a8a1c7cf5;hp=61571376cc19f160c31b4cc4315b4318606821c5
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:20 2021 +0000

    Bring some order to colour palette indexing.
    
    There are three separate indexing schemes in use by various bits of
    the PuTTY front ends, and _none_ of them was clearly documented, let
    alone all in the same place. Worse, functions that looked obviously
    related, like win_palette_set and win_palette_get, used different
    encodings.
    
    Now all the encodings are defined together in putty.h, with
    explanation of why there are three in the first place and clear
    documentation of where each one is used; terminal.c provides mapping
    tables that convert between them; the terminology is consistent
    throughout; and win_palette_set has been converted to use the sensible
    encoding.

 config.c         |  16 ++---
 fuzzterm.c       |   4 +-
 putty.h          | 189 +++++++++++++++++++++++++++++++++++++++++++++----------
 terminal.c       |  25 +++++++-
 unix/gtkwin.c    |  82 +++++++++---------------
 windows/window.c |  92 +++++++++++----------------
 6 files changed, 256 insertions(+), 152 deletions(-)

commit cd32ef873365a0a478824e1bdea93c39fbf07655
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cd32ef873365a0a478824e1bdea93c39fbf07655;hp=da3197f3952086d9a4e402315a5e8f4a8a1c7cf5
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:20 2021 +0000

    Indentation fixes in terminal.c.
    
    While working on the palette code I noticed several sections where a
    2-space indent policy was used. Let's keep things consistent.
    
    This patch is whitespace-only, with the single exception that I've
    removed a pair of braces where a for statement contains only a switch
    (and, cheatingly, put the for and switch on the same indent level so
    that the interior of it doesn't go _too_ far off to the right).

 terminal.c | 485 ++++++++++++++++++++++++++++++-------------------------------
 1 file changed, 242 insertions(+), 243 deletions(-)

commit ca9cd983e17e0beb589b07f33d36e2fae3143e38
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ca9cd983e17e0beb589b07f33d36e2fae3143e38;hp=cd32ef873365a0a478824e1bdea93c39fbf07655
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Centralise palette setup into terminal.c.
    
    Now terminal.c makes nearly all the decisions about what the colour
    palette should actually contain: it does the job of reading the
    GUI-configurable colours out of Conf, and also the job of making up
    the rest of the xterm-256 palette. The only exception is that TermWin
    can provide a method to override some of the default colours, which on
    Windows is used to implement the 'Use system colours' config option.
    
    This saves code overall, partly because the front ends don't have to
    be able to send palette data back to the Terminal any more (the
    Terminal keeps the master copy and can answer palette-query escape
    sequences from its own knowledge), and also because now there's only
    one copy of the xterm-256 palette setup code (previously gtkwin.c and
    window.c each had their own version of it).
    
    In this rewrite, I've also introduced a multi-layered storage system
    for the palette data in Terminal. One layer contains the palette
    information derived from Conf; the next contains platform overrides
    (currently just Windows's 'Use system colours'); the last one contains
    overrides set by escape sequences in the middle of the session. The
    topmost two layers can each _conditionally_ override the ones below.
    As a result, if a server-side application manually resets (say) the
    default fg and bg colours in mid-session to something that works well
    in a particular application, those changes won't be wiped out by a
    change in the Windows system colours or the Conf, which they would
    have been before. Instead, changes in Conf or the system colours alter
    the lower layers of the structure, but then when palette_rebuild is
    called, the upper layer continues to override them, until a palette
    reset (ESC]R) or terminal reset (e.g. ESC c) removes those upper-layer
    changes. This seems like a more consistent strategy, in that the same
    set of configuration settings will produce the same end result
    regardless of what order they were applied in.
    
    The palette-related methods in TermWin have had a total rework.
    palette_get and palette_reset are both gone; palette_set can now set a
    contiguous range of colours in one go; and the new
    palette_get_overrides replaces window.c's old systopalette().

 fuzzterm.c       |  10 +-
 putty.h          |  37 +++++---
 terminal.c       | 147 ++++++++++++++++++++++++++---
 terminal.h       |  15 +++
 unix/gtkwin.c    | 145 ++++++----------------------
 windows/window.c | 283 ++++++++++++++++++++-----------------------------------
 6 files changed, 306 insertions(+), 331 deletions(-)

commit 696550a5f286687deb3f50d5966d67eb9cd11fb7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=696550a5f286687deb3f50d5966d67eb9cd11fb7;hp=ca9cd983e17e0beb589b07f33d36e2fae3143e38
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Flip direction of window pos/size queries.
    
    Similarly to other recent changes, the frontend now proactively keeps
    Terminal up to date with the current position and size of the terminal
    window, so that escape-sequence queries can be answered immediately
    from the Terminal's own internal data structures without needing a
    call back to the frontend.
    
    Mostly this has let me remove explicit window-system API calls that
    retrieve the window position and size, in favour of having the front
    ends listen for WM_MOVE / WM_SIZE / ConfigureNotify events and track
    the position and size that way. One exception is that the window pixel
    size is still requested by Seat via a callback, to put in the
    wire-encoded termios settings. That won't be happening very much, so
    I'm leaving it this way round for the moment.

 fuzzterm.c       |  4 ----
 putty.h          | 11 ++--------
 terminal.c       | 26 +++++++++++++++++------
 terminal.h       |  2 ++
 unix/gtkwin.c    | 63 +++++++++++++++++++++-----------------------------------
 windows/window.c | 54 ++++++++++++++++++++----------------------------
 6 files changed, 70 insertions(+), 90 deletions(-)

commit 07aff63e221c0aa3e3b6091ff86669f31d2edb3f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=07aff63e221c0aa3e3b6091ff86669f31d2edb3f;hp=696550a5f286687deb3f50d5966d67eb9cd11fb7
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Centralise check of CONF_no_mouse_rep into Terminal.
    
    This removes code duplication between the front ends: now the terminal
    itself knows when the Conf is asking it not to turn on mouse
    reporting, and the front ends can assume that if the terminal asks
    them to then they should just do it.
    
    This also makes the behaviour on mid-session reconfiguration more
    sensible, in both code organisation and consistent behaviour.
    Previously, term_reconfig would detect that CONF_no_mouse_rep had been
    *set* in mid-session, and turn off mouse reporting mode in response.
    But it would do it by clearing term->xterm_mouse, which isn't how the
    front end enabled and disabled that feature, so things could get into
    different states from different sequences of events that should have
    ended up in the same place.
    
    Also, the terminal wouldn't re-enable mouse reporting if
    CONF_no_mouse_rep was *cleared* and the currently running terminal app
    had been asking for mouse reports all along. Also, it was silly to
    have half the CONF_no_mouse_rep handling in term_reconfig and the
    other half in the front ends.
    
    Now it should all be sensible, and also all centralised.
    term->xterm_mouse consistently tracks whether the terminal application
    is _requesting_ mouse reports; term->xterm_mouse_forbidden tracks
    whether the client user is vetoing them; every change to either one of
    those settings triggers a call to term_update_raw_mouse_mode which
    sets up the front end appropriately for the current combination.

 terminal.c       | 17 +++++++++++------
 terminal.h       |  1 +
 unix/gtkwin.c    |  1 -
 windows/window.c |  1 -
 4 files changed, 12 insertions(+), 8 deletions(-)

commit 99dfc66457d19f0769a0b5cfe9dd7f924e22ee71
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=99dfc66457d19f0769a0b5cfe9dd7f924e22ee71;hp=07aff63e221c0aa3e3b6091ff86669f31d2edb3f
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Decouple frontend's raw mouse mode from pointer shape.
    
    This paves the way for a followup commit that will make them happen at
    slightly different times.

 putty.h          |  8 ++++++++
 terminal.c       |  2 ++
 unix/gtkwin.c    | 13 +++++++++----
 windows/window.c | 14 ++++++++++----
 4 files changed, 29 insertions(+), 8 deletions(-)

commit d74308e90e3813af664f91ef8c9d1a0644aa9544
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d74308e90e3813af664f91ef8c9d1a0644aa9544;hp=99dfc66457d19f0769a0b5cfe9dd7f924e22ee71
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Fold ancillary window changes into main redraw.
    
    This fixes a long-standing inconsistency in updates to the terminal
    window: redrawing of actual text was deferred for 1/50 second, but all
    the other kinds of change the terminal can make to the window
    (position, size, z-order, title, mouse pointer shape, scrollbar...)
    were enacted immediately. In particular, this could mean that two
    updates requested by the terminal output stream happened in reverse
    order.
    
    Now they're all done as part of term_update, which should mean that
    things requested in the same chunk of terminal input happen at the
    same time, or at the very least, not in reverse order compared to the
    order the requests came in.
    
    Also, the same timer-based UPDATE_DELAY mechanism that applies to the
    text updates now applies to all the other window modifications, which
    should prevent any of those from being the limiting factor to how fast
    this terminal implementation can process input data (which is exactly
    why I set up that system for the main text update).
    
    This makes everything happen with a bit more latency, but I'm about to
    reverse that in a follow-up commit.

 terminal.c | 228 ++++++++++++++++++++++++++++++++++++++++++++-----------------
 terminal.h |  24 +++++++
 2 files changed, 190 insertions(+), 62 deletions(-)

commit 334688db815d9d69cf092417f5ebbdcba573d664
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=334688db815d9d69cf092417f5ebbdcba573d664;hp=d74308e90e3813af664f91ef8c9d1a0644aa9544
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Apply UPDATE_DELAY in arrears, not in advance.
    
    The original aim of the rate limit was to avoid having too many
    updates per second. I implemented this by a deferment mechanism: when
    any change occurs that makes the terminal want an update, it instead
    sets a timer to go off after UPDATE_DELAY (1/50 second), and does the
    update at the end of that interval.
    
    Now it's done the other way round: if there has not been an update
    within the last UPDATE_DELAY, then we can simply do an update _right
    now_, in immediate response to whatever triggered it. And _then_ we
    set a timer to track a cooldown period, within which any further
    requests for updates will be deferred until the end of the cooldown.
    
    This mechanism should still rate-limit updates, but now the latency in
    normal interactive use should be lowered, because terminal updates in
    response to keystrokes (which typically arrive separated by more than
    UPDATE_DELAY) can now each be enacted as soon as possible after the
    triggering keystroke.
    
    This also reverses (in the common case) the slowdown of non-textual
    window modifications introduced by the previous commit, in which lots
    of them were brought under the umbrella of term_update and therefore
    became subject to UPDATE_DELAY. Now they'll only be delayed in
    conditions of high traffic, and not in interactive use.

 terminal.c | 32 +++++++++++++++++++++++++-------
 terminal.h | 14 ++++++++++----
 2 files changed, 35 insertions(+), 11 deletions(-)

commit 07d334c61dc09d4e8ba364bf6e96f348837a4e4d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=07d334c61dc09d4e8ba364bf6e96f348837a4e4d;hp=334688db815d9d69cf092417f5ebbdcba573d664
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Windows: make the need_backend_resize mechanism consistent.
    
    There were three separate clauses in the WM_SIZE message handler which
    potentially called term_size() to resize the actual Terminal object.
    Two of them (for maximisation and normal non-maximised resizing drags)
    first checked if an interactive resize was in progress, and if so,
    instead set the need_backend_resize, to defer the term_size call to
    the end of the interactive operation. But the third, for
    _un_-maximising a window, didn't have that check.
    
    As a result, if you start with a maximised window, drag its title bar
    downward from the top of the screen (which unmaximises it), and
    without letting go, drag it back up again (which maximises it), the
    effect would be that you'd get one call to term_size in the middle of
    the drag, and a second at the end. This isn't what I intended, and it
    can also cause a redraw failure in full-screen applications on the
    server (such as a terminal-based text editor - I reproduced this with
    emacs), in which after the second term_size the terminal doesn't
    manage to redraw itself.
    
    Now I've pulled out the common logic that was in two of those three
    pieces of code (and should have been in all three) into a subroutine
    wm_size_resize_term, and arranged to call that in all three cases.
    This fixes the inconsistency, and also fixes the emacs redraw problem
    in the edge case I describe above.

 windows/window.c | 90 +++++++++++++++++++++++---------------------------------
 1 file changed, 37 insertions(+), 53 deletions(-)

commit 8af1d90dca30037cae326ffe2179b62d7b459f8d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=8af1d90dca30037cae326ffe2179b62d7b459f8d;hp=07d334c61dc09d4e8ba364bf6e96f348837a4e4d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 7 19:59:21 2021 +0000

    Test program for ancillary window updates.
    
    I've just done a major rewrite of code structure and update policy for
    most of the TermWin window-modification methods, and I wrote this test
    program in the process to check that old and new versions of the
    terminal still respond to all these escape sequences in the same way.
    It's quite likely to come in useful again, so I'll commit it.

 test/windowchange.py | 230 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 230 insertions(+)



More information about the tartarus-commits mailing list