From 16d5bb726972df6b5329aa1654f649c0dce31ef0 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Tue, 6 Sep 2022 11:13:50 +0100 Subject: [PATCH] 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(-) diff --git a/unix/columns.c b/unix/columns.c index 917b39e6..3dbed9c3 100644 --- a/unix/columns.c +++ b/unix/columns.c @@ -918,6 +918,12 @@ static void columns_alloc_vert(Columns *cols, gint ourheight, children = children->next) child->visited = false; + /* + * Main layout loop. In this loop, vertically aligned controls are + * only half dealt with: we assign each one enough _height_ to + * match the others in its group, but we don't adjust its y + * coordinates yet. + */ for (children = cols->children; children && (child = children->data); children = children->next) { @@ -969,7 +975,7 @@ static void columns_alloc_vert(Columns *cols, gint ourheight, if (topy < colypos[child->colstart+i]) topy = colypos[child->colstart+i]; } - child->y = topy + fakeheight/2 - realheight/2; + child->y = topy; child->h = realheight; child->visited = true; boty = topy + fakeheight + cols->spacing; @@ -979,6 +985,28 @@ static void columns_alloc_vert(Columns *cols, gint ourheight, } } + /* + * Now make a separate pass that deals with vertical alignment by + * moving controls downwards based on the difference between their + * own height and the largest height of anything in their group. + */ + for (children = cols->children; + children && (child = children->data); + children = children->next) { + if (!child->widget) + continue; + if (!gtk_widget_get_visible(child->widget)) + continue; + + fakeheight = realheight = child->h; + for (ColumnsChild *ch = child->valign_next; ch != child; + ch = ch->valign_next) { + if (fakeheight < ch->h) + fakeheight = ch->h; + } + child->y += fakeheight/2 - realheight/2; + } + g_free(colypos); }