Hi,
i wanted to show a nice welcome message at the C182 and stumbled upon a problem with the MessageBox implementation. It always has a fixed size.
It would be cool if the messageBox could be sized optionally, so I added a small patch introducing an optional parameter.
PR hereby:
CanvasMessageBox_sizeableIf its merged I will ammend the wiki page: https://wiki.flightgear.org/Canvas_MessageBox
# Examples:
canvas.MessageBox.information("Orignal", "bla bla bla", nil, canvas.MessageBox.Ok);
canvas.MessageBox.question("Bigger", "BarContent", nil, canvas.MessageBox.Cancel, [300, 300]);
Demo is here: https://github.com/HHS81/c182s/pull/586
What I still struggle with is, how i can prevent those big margins at the top and bottom of the text.
If I make the height value smaller, top margin will remain, and text overflows into the buttons (and behind the border of the dialog, if too small).
Any ideas for that?
Probably the newlines are messing with the Label's styling / center code.
I digged into FGData, but could not find the place where this is defined.
Last edit: Benedikt Hallinger 2024-04-08
Is it currently a fixed size? I prefer we did it by making it auto-size cvertically basically on the text length : this is also more friendly for translations in the future.
So, rather than passing an explicit size, I'd suggest we use the height-for-width feature of Canvas Text, as we do in the Canvas widgets code, to inxcrease the MessageBox vertical height automatically.
I figured it out. The label can't deal very well with newlines and height calculation, so the text is placed "centered" and thus too low for the resulting height.
An easy fix is to make MessageBox aware of "\n" delimited text. I added and pushed to my own repo (see above) a commit now that splits the text and adds each line as separate label; that makes the calculation of the box working out of the box.
Screenshot attached:
@jmturner I think you can review this.
The problem I faced was, that the height-for-width feature does not work properly here, because of the newlines. But splitting that up now works out of the box: the label itself adjusts already correctly.
Last edit: Benedikt Hallinger 2024-04-09
One thing is, that the label does not seem to respond with the proper height if text gets wrapped.
Or, like said, newlied.
I could not find, where that calculation is taking place.
Last edit: Benedikt Hallinger 2024-04-09
Did some digging, there are some hard-coded max sizes in canvas.MessageBox we should remove:
What I'd suggest is to make the maxWidth configurable (and bigger), and default the maxHeight to -1 or nil meaning no max height.
And then seperateley we need to fix the word-wrap of the Label so it worsk correctyl with newlines.
The work-around for the newlines is pretty bad, can you give me a test case with just the regular text and I'll fix the centering? When we come to support translations in the new UI, we can't possible expect people to manually insert newlines.
Sure, here it is:
https://github.com/HHS81/c182s/blob/a2a84e2f7c0ddbf53e4f250ae4c41ad489cd0dfb/Nasal/c182s.nas#L1175-1194
Last edit: Benedikt Hallinger 2024-04-11
… maybe I‘m also just riding the wrong horse for my usecase and are misusing the messagebox?
Is maybe just creating my own canvas window the more correct approach?
(Just thinking loud)
And regarding the newlines:
I want explicitely have newlines for structuring the text. I really need paragraphs :)
Sure, but we want new lines for paragraphs, NOT for every line-breaks. Like, in a normal text editor / viewer.
Basically; at some point line wraps WILL work, so if you do explicit newlines now, you GUI will be broken. The future-proof thing is to rely on the built-in line wrapping.
Last edit: Benedikt Hallinger 2024-05-24
(sorry, wrong ticket. This is still pending)
Yeah I know, I'm slowly working through the backlog, thanks for your patience.
What I also played first, but did not succeed, was a scheme to extend the "class" and just overwrite the values. That did not pan out, since the base class calls always the base class values, and not the one in the inheriting child.
But maybe some kind of optional callback or so could be done.
I'm not that into object oriented nasal, however.
Last edit: Benedikt Hallinger 2024-06-03
This will (hopefully) be fixed by making canvas windows up- / downsize to their layout's size automatically - see https://gitlab.com/flightgear/fgdata/-/issues/2