A little rant about why I 'hardcoded' the value 2.9em:
If you are using constants to specify some positions, please give the meaningful names so that other people can work with them. E.g. calling something "menu_height" and then using it to adjust the X position AND the Y position of a BUTTON probably means it's not the "menu_height"...
I believe that the current "dynamic layout" will terribly break if someone would e.g. decide that the menu should be one line higher (because hey, then everything else would also move).
The real solution is to rewrite the layout of the menu to be dynamic and use constants (because currently it isn't and doesn't, it just tries to.).
Previously, text windows would just change their own size and leave cropping and scrolling to their parent. This made the code easier, but was apparently unintuitive for scripters.
Now text windows do not change their size but show a scrollbar themselves (unless GUI_FitChildren or GUI_NoCrop of course).
This implied some other changes, because now parents without a scroll bar need to clip, too. (Or the clipping needs to be moved to the child window. But then it would have to be made sure that menu decoration can still go out of the bounds.)
And this also needed some script fixes where scripters assumed the text windows would not scroll (and thus made them smaller than 1em).
related to https://git.openclonk.org/openclonk.git/commit/46ad28ea652fad34814a866f3b9c305aa7cc6faa
..by putting the text into another subwindow. Might be good to "fix" (it's intended but possibly not wise) that in the engine, but not right now before the release, because it could introduce new bugs.
Nicolas Hake