simon-git: puzzles (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  4cf2241 Fix auto-selection of presets in GTK.
  f03e8d3 Fix changing puzzle size in a maximised GTK3 window.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-09-30 22:20:25

commit 4cf2241f4f74620709ae12ce76e1b601353515b3
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=4cf2241f4f74620709ae12ce76e1b601353515b3;hp=84d3fd2bd8d3bd5db8cf61a134a4601307b9b7ea
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 30 21:18:52 2017 +0100

    Fix auto-selection of presets in GTK.
    
    In commit a7dc17c42 I apparently introduced two bugs in
    changed_preset(). Firstly, the Custom menu option was being written
    into the 'found' variable in nearly all cases, because it has a NULL
    user-data pointer which caused it to take the wrong branch of an if
    statement due to an erroneous complex condition. Secondly, having
    written _something_ into 'found', I had set it to inactive rather than
    active due to forgetting to change a FALSE into a TRUE.
    
    Now when I start up Net with my usual nonstandard default parameters
    (I like the 13x11 wrapping, so I set NET_DEFAULT=13x11w in my
    environment), the right menu entry comes up ticked.

 gtk.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

commit f03e8d30a038f740ea0bfe21474de5df69093893
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=f03e8d30a038f740ea0bfe21474de5df69093893;hp=4cf2241f4f74620709ae12ce76e1b601353515b3
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Sep 30 22:02:39 2017 +0100

    Fix changing puzzle size in a maximised GTK3 window.
    
    While working on the Net scalability today I noticed that changing
    preset from (say) 13x11 to 5x5 in GTK3 Net while the window is
    maximised does not have the desired effect (that being that, since the
    maximised window does not change size, the new puzzle size is instead
    scaled to fit neatly in the existing window).
    
    A git bisect suggests that this was a side effect of commit 8dfe5cec3;
    it looks as if there was a useful side effect of setting fe->area as
    the 'geometry widget' for fe->window, namely, that any attempt to
    resize the window thereafter (even if it had no effect on the window
    size) would trigger a configure event on the geometry widget, so we'd
    get a notification of our new size even if it was the same as our old
    size.
    
    But that 'geometry widget' feature is deprecated, so I have to work
    around it another way. Fortunately, I've found a fallback event that
    still does occur, namely "size_allocate" on fe->window. So I'm
    trapping that as well and using it as an indication that a configure
    event won't be forthcoming.

 gtk.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 63 insertions(+), 6 deletions(-)