simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  ea1038a2 GTK: switch embedded icons to raw RGBA rather than xpm.
  3c598400 Fix handling of ECONNREFUSED in GTK 1 builds (!)

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:           2026-04-16 10:09:13

commit ea1038a25b54dbddc29ba46d27d330ce633a0b7b
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ea1038a25b54dbddc29ba46d27d330ce633a0b7b;hp=85703a848b7ae8d931c4371c16d6861f8f1087bd
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Apr 15 16:23:02 2026 +0100

    GTK: switch embedded icons to raw RGBA rather than xpm.
    
    A test-build on current Debian sid revealed that in the latest version
    of GdkPixbuf, gdk_pixbuf_new_from_xpm_data() is marked as deprecated,
    causing build failures at -Werror.
    
    It turns out that ever since the start of GTK 2, GdkPixbuf has had a
    reasonably nice API call gdk_pixbuf_new_from_data() which takes a
    buffer of raw 32-bit RGBA pixels plus width/height/stride parameters,
    and moreover, uses the data in place rather than copying it – it takes
    ownership, but you provide a function to free it. Or if it's in the
    static data segment, you just don't _even_ provide a free function.
    
    Not only that, but it turns out the XPM parsing was done by a spare
    shared library that's not embedded in the GdkPixbuf main code, and a
    warning in the current docs say that that library can't be 100% relied
    on to be present everywhere!
    
    So using raw RGBA data seems better all round in any case, and since it
    isn't newly introduced, I don't need to make it conditional on a very
    new version of anything. We can just use that function for all GTK 2.x
    and 3.x builds, and use the XPM approach only on GTK 1.

 icons/Makefile          |   19 +-
 icons/cicon.pl          |   84 +-
 unix/CMakeLists.txt     |    8 +-
 unix/dialog.c           |    2 +-
 unix/platform.h         |   11 +-
 unix/pterm-config-rgb.c | 3619 +++++++++++++++++++++++++++++++++++++++++++++++
 unix/pterm-rgb.c        | 3619 +++++++++++++++++++++++++++++++++++++++++++++++
 unix/putty-config-rgb.c | 3619 +++++++++++++++++++++++++++++++++++++++++++++++
 unix/putty-rgb.c        | 3619 +++++++++++++++++++++++++++++++++++++++++++++++
 unix/window.c           |   96 +-
 10 files changed, 14644 insertions(+), 52 deletions(-)

commit 3c598400e495645fec921781a1065303039a7d17
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=3c598400e495645fec921781a1065303039a7d17;hp=ea1038a25b54dbddc29ba46d27d330ce633a0b7b
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Apr 15 17:16:00 2026 +0100

    Fix handling of ECONNREFUSED in GTK 1 builds (!)
    
    While testing the GTK 1 version of the code I touched in the previous
    commit, I tried to connect to an SSH server which has both IPv6 and v4
    addresses but is refusing connections to port 22 on the v6 address.
    GTK2 and GTK3 PuTTY cheerfully fall back to v4; GTK1 PuTTY bombed out
    immediately with a 'Connection refused' message box.
    
    Turned out this was because I had performed an asynchronous connect(2)
    operation; called uxsel_set() to ask for only writability
    notifications on the socket (that being how you find out that your
    async connect attempt has finished); uxsel_set() dutifully called
    gdk_input_add() with only the GDK_INPUT_WRITE flag; and GTK1 called me
    back with GDK_INPUT_READ as well as GDK_INPUT_WRITE set! So network.c
    tried to process the readability notification first, leading to the
    wrong branch of the network error handling code.
    
    Easily fixed by remembering what I/O flags we actually _asked_ for,
    and ignoring any others that GTK chooses to set in the callback.

 unix/gtk-common.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)