simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  33b8ce36 Windows: move the right control for align_next_to.
  93e6da65 buildinfo.c: add another Visual Studio version.
  16d5bb72 GTK: fix y computation in align_next_to.

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-09-06 11:44:18

commit 33b8ce3659e703d5387efd7697676af223c225e9
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=33b8ce3659e703d5387efd7697676af223c225e9;hp=9e7d4c53d80b6ebb9598610ab706faf2218c8a7b
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 6 10:42:19 2022 +0100

    Windows: move the right control for align_next_to.
    
    We had carefully calculated, for each control in an aligned group, how
    much _that control_ should move downwards by. But then, because I
    carelessly referred to the wrong variable name, we actually moved the
    wrong one - not the control we'd just calculated the offset for, but
    always the _last_ one in the group, which was the one the top-level
    alignment code was processing at the point we began this loop.
    
    As a result, the dropdown list in the front-page protocol selector was
    hilariously misaligned. Now it's back where it should be.

 windows/controls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 93e6da65acfd6f5e646eb07572671955b9992791
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=93e6da65acfd6f5e646eb07572671955b9992791;hp=33b8ce3659e703d5387efd7697676af223c225e9
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 6 10:59:03 2022 +0100

    buildinfo.c: add another Visual Studio version.
    
    It's not listed on the docs web page yet, but my Windows machine just
    installed it, so I was able to observe myself what value of _MSC_VER
    it defines.

 utils/buildinfo.c | 2 ++
 1 file changed, 2 insertions(+)

commit 16d5bb726972df6b5329aa1654f649c0dce31ef0
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=16d5bb726972df6b5329aa1654f649c0dce31ef0;hp=93e6da65acfd6f5e646eb07572671955b9992791
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Sep 6 11:13:50 2022 +0100

    GTK: fix y computation in align_next_to.
    
    The protocol selector widgets were misaligned in GTK as well as on
    Windows, but for a completely different reason. (I guess both bugs
    must have been introduced at the same time when I reworked the system
    to tolerate more than two aligned widgets in commit b5ab90143a2df7f.)
    
    To vertically align N widgets, you have to first figure out what range
    of y-coordinates they jointly occupy, and then centre each one within
    that range. We were trying to do both jobs in the same pass, which
    meant trying to place the first widget before finding out where the
    last one will be. To do this, we were separately computing the
    y-range's start and width, the former by taking max of the
    y-coordinates _seen so far_, and the latter by taking max of _all_ the
    widgets' heights.
    
    This has two problems. One is that if you later find out that the
    y-coordinate of the top of the range needs to be lower than you'd
    previously realised, it's too late to go back and reposition the
    widgets you've already placed. But that's a theoretical issue that
    would only come up with more complicated column layouts than we've
    actually used. (And probably more complicated than would even be
    _sensible_ to use.)
    
    The other, more immediate, problem: the y-coordinates we were using
    for already-placed widgets in the set were the ones _after_ we
    adjusted each one for vertical centring. So if the first widget is
    short and the second taller (say, heights 20 and 30 pixels), then the
    first widget will be offset downwards by 5 pixels, but the second
    widget will use that offset y-coordinate as the _top_ of the range to
    fit itself into, and hence, will also be 5 pixels downward from where
    it should have been.
    
    I think only the second of those problems is immediately concerning,
    but it's easier to fix both at once. I've removed the y-adjustment for
    vertical centring from the main layout loop, and put it in a separate
    pass run after the main layout finishes.

 unix/columns.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)