simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  412dce1 Stop using the GTK "configure-event" signal.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-05-10 20:31:09

commit 412dce1e8add7dfc9d3c49505c422381aec3cc84
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=412dce1e8add7dfc9d3c49505c422381aec3cc84;hp=7fee4e9b43ea7d72e373b08cfd4afce8e031d0ef
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 10 20:22:02 2018 +0100

    Stop using the GTK "configure-event" signal.
    
    I've been using that signal since the very first commit of this source
    file, as a combined way to be notified when the size of the drawing
    area changes (typically due to user window resizing actions) and also
    when the drawing area is first created and available to be drawn on.
    
    Unfortunately, testing on Ubuntu 18.04, I ran into an oddity, in which
    the call to gtk_widget_show(inst->window) in new_session_window() has
    the side effect of delivering a spurious configure_event on the
    drawing area with size 1x46 pixels. This causes the terminal to resize
    itself to 1 column wide, and the mistake isn't rectified until a
    followup configure-event arrives after new_session_window returns to
    the GTK main loop. But that means terminal output can occur between
    those two configure events (the connection-sharing "Reusing a shared
    connection to host.name" is a good example), and when it does, it gets
    embarrassingly wrapped at one character per line down the left column.
    
    I briefly tried to bodge around this by trying to heuristically guess
    which configure events were real and which were spurious, but I have
    no faith in that strategy continuing to work. I think a better
    approach is to abandon configure-event completely, and move to a
    system in which the two purposes I was using it for are handled by two
    _different_ GTK signals, namely "size-allocate" (for knowing when we
    get resized) and "realize" (for knowing when the drawing area
    physically exists for us to start setting up Cairo or GDK machinery).
    
    The result seems to have fixed the silly one-column wrapping bug, and
    retained the ability to handle window resizes, on every GTK version I
    have conveniently available to test on, including GTK 3 both before
    and after these spurious configures started to happen.

 unix/gtkwin.c | 63 +++++++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 48 insertions(+), 15 deletions(-)