simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  a3503fd gtkask: rework the mechanism for keyboard grabs.

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-13 23:06:09

commit a3503fd234570d72bc2c8b434514d1946c2ade74
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=a3503fd234570d72bc2c8b434514d1946c2ade74;hp=6afa955a2ebf017755af134264a9423f54b9351c
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun May 13 22:56:52 2018 +0100

    gtkask: rework the mechanism for keyboard grabs.
    
    I've found Unix Pageant's GTK password prompt to be a bit flaky on
    Ubuntu 18.04. Part of the reason for that seems to be (I _think_) that
    GTK has changed its internal order of setting things up, so that you
    can no longer call gtk_widget_show_now() and expect that when it
    returns everything is ready to do a gdk_seat_grab. Another part is
    that - completely mysteriously as far as I can see - a _failed_
    gdk_seat_grab(GDK_SEAT_CAPABILITY_KEYBOARD) has the side effect of
    calling gdk_window_hide on the window you gave it!
    
    So I've done a considerable restructuring that means we no longer
    attempt to do the keyboard grab synchronously in gtk_askpass_setup.
    Instead, we make keyboard grab attempts during the run of gtk_main,
    scheduling each one on a timer if the previous attempt fails.
    
    This means I need a visual indication of 'not ready for you to type
    anything yet', which I've arranged by filling in the three drawing
    areas to mid-grey. At the point when the keyboard grab completes and
    the window becomes receptive to input, they turn into the usual one
    black and two white.

 unix/gtkask.c | 190 +++++++++++++++++++++++++++++++++++++---------------------
 1 file changed, 122 insertions(+), 68 deletions(-)