I guess the UI elements expect their position to already be corrected by cgo.X/Y. Or they never cared because they were in front of the upper board.
I am not sure, maybe the correct solution would be to actually position all elements lower (instead of adjusting for it when passing mouse input or drawing)? Currently the position is relative to the upper board's edge.
Anyway, this works for now.
This is solved via another entry in the production menu (below the products), which is updated by an effect, that is being told the menu ID/target by the interaction menu through a callback.
This setup allows for very intrusive changes to the interaction menu with only few lines of code!
Otherwise, if a window was GUI_FitChildren and the text would NOT trigger a scrollbar, the window height was set to 0 (because the text height was only taken into account when rawTextHeight - 1 > rcBounds.Hgt).
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
Not sure why this broke, maybe glGetIntegerv does not return the current
polygon mode anymore. Either way, we don't need to remember the previous
setting but can just always reset it to GL_FILL afterwards.
Nicolas Hake