Better alignment on Plan Tree window

[Roboron]

I was translating the Plan Tree help file when I noticed a lack of alignment on such window. "Unplayable!" I thought. "I need to spend two hours searching through the GUI code to fix the alignment before continuing!". I did. This patch:

1) Combines the two tables on cont_filter into one, so elements are properly aligned.
2) Add also vertical margin by default to gui_scrolled_list, because as you can see the top first element was getting merged with border line due to lack of margin.

Observation: The second combobox text says "sort by", but in reality it doesn't "sort", but show the objects by a different name. Should we change it to "Show by"?
Observation 2: It also piss me a little that the combobox is not big enough (by default) to cover all the text, so the text appears cropped >.< But that is outside my realm for now.

[prissi]

Well, the second combobox sorts the entries and shows them as well.

And ss you probably could tell from the code, it is deliberately made that way, otherwise German climate names will not fit the combobox. So it was made that way

[Roboron]

Well, the second combobox sorts the entries and shows them as well.

Right, but we already have a sort button next to it. A bit confusing to have two buttons that are supposed to sort, isn't it?

And ss you probably could tell from the code, it is deliberately made that way, otherwise German climate names will not fit the combobox. So it was made that way

I'm afraid I did not understand this.

[prissi]

Not aligning the two rows was intentional, since the sort order box reduces the available space. "Klimazone" and "sortiert nach" are also very long, so the Comboboxes would even get more narrower in German. So the choice was made to not align the rows. (And not aligning them takes extra effort, so I was hinted that the code could have given a hint that the non-alignment was intentional. Otherwise the extra alignment container would not have been added.)

[Roboron]

What? They were *purposely* unaligned so the first combobox was bigger and fit all the text...? I... respectfully disagree with your design decisions. IMHO, the comboboxes should define a minimum width so the *largest* word is able to fit them without having to resize the window or resort to design trickeries like this.

From gui/components/gui_combobox.cc function get_min_size()

Code Select Expand

return scr_size(max(bl.w + br.w + D_H_SPACE, sl.w), max(max(bl.h, ti.h), br.h));

This select the maximum between left + right buttons minimum width and the scroll list minimum width. The scroll list will usually define the minimum width of the combobox then, but this is not enough because it only counts the width of the text. Instead, we should sum up the width of the buttons and the scroll list.

Code Select Expand

return scr_size(bl.w + br.w + sl.w - D_H_SPACE, max(max(bl.h, ti.h), br.h));

Subtracting D_H_SPACE because the scroll list minimum width is actually the text width + D_H_SPACE * 2.

So in the end I had to dive into the combobox issue... I hope this issue is not also intended.

[prissi]

Apparently we enter here personal taste regime. Same for the suggested change of gui_scrolled_list.cc. I would find it strange that there is an extrat margin on top/bottom the first/last entry compared to the rest.

If changed, I would at least overlap the climate selector with the sort order box. Otherwise I would find this layout too empty. Furthermore, if changed, exactly the same alignment is used for city buildings, tourist attractions and factories and would need to change as well.

Comboboxes intentionally have been as wide as the text when opened, at least since their dynamic introduction. This overlaps with the width of the arrows. One could of course argue that horizontal scrolling should be avoided, especially since nowadays screens tend to be rather wide than high.

Conclusion:
Maybe change, but then to all similar dialoges. And Climate box shoudl rather overlap sort order box, which can be achieved by an additional ,2);

[Leartin]

What? They were *purposely* unaligned so the first combobox was bigger and fit all the text...? I... respectfully disagree with your design decisions.

Note that it was like that from way back when. The decision was between "nice alignment" and "avoid cutting text", where your first fix just changed what was prioritized. Fixing comboboxes voids the decision since you can actually have both. (while in reality, due to changes down the line, you had neither).

I would find it strange that there is an extrat margin on top/bottom the first/last entry compared to the rest.

It's certainly not strange if the (visual) space between the top of the box and the first entry is the same as the space between entries. That's not extra, but the expected amount - eg. while writing an answer here, the first line is visually seperated from the top about as much as each line is seperated from each other. If you resize the box and scroll down, it can touch though - usually giving a nice indication when you are not on the top, with no need to watch out for a scrollbar somewhere else.

[prissi]

SO I count you as an additional vote for an extra space at the top of the list?

[Roboron]

Same for the suggested change of gui_scrolled_list.cc. I would find it strange that there is an extrat margin on top/bottom the first/last entry compared to the rest.

I don't actually care if the margin is greater, equal, or less than the margin between the entries. You can set it to D_V_SPACE/2 instead, or a fixed amount. As long as it is non-zero (so it doesn't collide with the border), I will be happy.

If changed, I would at least overlap the climate selector with the sort order box. Otherwise I would find this layout too empty.

I can concede you this, no problem. Added in this patch.

Furthermore, if changed, exactly the same alignment is used for city buildings, tourist attractions and factories and would need to change as well.

Yes, of course, I was aware. I don't see any problem with that, it improves them as well.

One could of course argue that horizontal scrolling should be avoided, especially since nowadays screens tend to be rather wide than high.

Exactly, with screens with double the wide than the height, there's little reason to be cropping text in modern UIs: there's plenty of horizontal space. The same is not true for vertical space, which can still be a problem (specially on mobile devices - I pointed it out in the past.

while in reality, due to changes down the line, you had neither

What changes?

[Leartin]

What changes?

Specifically that sort button, which takes space from the second row, hence the word 'Translation' not fitting anymore. IIRC that wasn't the case in the past, at least not in English nor German.
(Since I said it was a decision between layout and complete words, I just wanted to point out that I'm aware the 'complete words' part wasn't quite working anymore.)

[prissi]

The inner table was actually no longer needed, so I removed it as well. In in r10312

[Roboron]

Thank you, prissi. Much appreciated