[Commits] [wesnoth/wesnoth] a8bcd2: gui1: Fix bogus dialog option buttons layout (bug ...

[GitHub]

  Branch: refs/heads/1.12
  Home:   https://github.com/wesnoth/wesnoth
  Commit: a8bcd2a528e415da303c6dc60ac931d638a4bc41
      https://github.com/wesnoth/wesnoth/commit/a8bcd2a528e415da303c6dc60ac931d638a4bc41
  Author: Ignacio R. Morelle <shadowm at wesnoth.org>
  Date:   2014-11-10 (Mon, 10 Nov 2014)

  Changed paths:
    M changelog
    M src/construct_dialog.cpp

  Log Message:
  -----------
  gui1: Fix bogus dialog option buttons layout (bug #22791, #22379)

Formerly, the option buttons at the bottom of the dialog were laid out
by redoing some math instead of tracking the dialog's menu position,
which is always valid (even when there is no menu!). I'm not entirely
sure why, but the math reprised here became bogus with the introduction
of top buttons in commit 045bda037d78056866bdd918b51708d44d2bf515 (for
the Add-ons Manager dialog), in particular for dialogs *not* using them
(such as the in-game Statistics dialog), even though the menu is still
laid out correctly.

So instead of reinventing the wheel, we really should just take the
menu's position and height as a baseline for the bottom option buttons.
At worst the height is 0, but the position is still within the dialog's
boundaries (but see below for an unsolved corner case).

This commit reverts commit f60ef98e275fd3d16733f7d5dfd7314920841fd5
(a.k.a. 69521000dc5c45f9745131ee13e76493e14fefaa in 1.12) that's part of
PR #263, because it turns out that the solution proposed there is only a
convenient workaround that solves a layout issue for a single dialog
(Statistics, see bug #22379) and introduces a new bug for another
(Add-ons Manager, see bug #22791).

Regardless of the cause for #22791, the approach put forward by this
commit is more consistent with best practice (laying out widgets from
top to bottom each row's geometry depending on the previous row's), so I
have decided to not look too much into it.

It should be noted that the layout of bottom option buttons breaks
entirely for dialogs missing a menu, both before and after the
introduction of top buttons. Currently there is no GUI1 dialog that
attempts to insert option buttons while lacking menu entries, so I'm not
too concerned about this bug (which affects 1.10 too!). Besides, some
day GUI1 is supposed to go the way of the dodo and stop bothering us
with its marvelous inflexibility and arcane logic.